A Start Job is running for dev-disk/x2uuid and similar errors

[jedi]

I hate the touchpad on this MSI laptop.  It is my least hated option on this laptop.  I will NEVER buy another MSI product in the future.  It is not solely related to this issue that I make that statement. (the 90 sec)
So I have an NVMe PCIe drive.  Seen by fdisk, parted, gparted, fstab, blkid, lsblk, you get the idea, as nvme0n1.  OK, so in /etc/fstab:

Code Select Expand


### first '6' lines are the original fstab for the VSIDO install
### we'll call this section 1.
#proc /proc proc defaults 0 0
#UUID=bda2cbcd-9696-419b-baf4-2e875fc1279a / ext4 defaults,noatime 0 1
#UUID=730da2a3-5aef-4654-908e-865d3ed8f8aa /home ext4 defaults,noatime 0 2
#UUID=efe98bd0-1254-40b4-8378-61811c50da34 swap linux-swap defaults 0 0
#UUID=9E77-1B41 /boot/efi vfat defaults 0 1

### we'll call this section 2.
proc /proc proc defaults 0 1
/dev/nvme0n1p1 /boot/efi vfat defaults 0 1
/dev/nvme0n1p3 / ext4 defaults,noatime 0 1
/dev/nvme0n1p4 /home ext4 defaults,noatime 0 2
/dev/sda1 /media/DATA ntfs-3g defaults,noatime 0 2
/dev/nvme0n1p10 /media/root_manjaro ext4 defaults,noatime 0 1
/dev/nvme0n1p11 /media/home_manjaro ext4 defaults,noatime 0 2


Either way I have the 90 second wait.  However, for clarity, here is the general order of events;

Power on, Grub, then the "A start job for dev-x2uuidblahblahblah" happens for 90 seconds.  For whatever weird reason, in /etc/fstab when the top lines are uncommented, (called "section 1" above) and the /dev/nvme* are commented, (called "section 2" above) no wireless.  The card is seen, (Killer Wireless Qualcom card, ath10k) just no wifi.  Haven't tested ethernet.    (this issue resolved itself with the fix described below of adding 'nofail' to /etc/fstab.  I no longer believe UUID's are an issue or were an issue.  This has happened to as many regular ssd's and hdd's all over the net.)  I say this having just booted my laptop into VSIDO with no errors, and all drives present, and accounted for utilizing the UUID's!

Now, as seen above, just as it is, it goes to a emergency mode 'pause' for you to acknowledge that "no, it is not an emergency, or an issue", so press Ctrl-d and it boots to all of VSIDO's glory and finery!  Or type your password to fix any imaginary problems you may be having... 

I'm sorry it took so long for me to post about this.  I am also grateful to all of you who've taken care of it, so I can come along at last and correct mine!  Seriously, to everyone here on the forum, VastOne has been toiling away at this ever since I mentioned it on IRC almost 2 weeks ago.  Our one and only dev of VSIDO truly is a "one and only"!!!!  Also thanks to PackRat as well.  Wow, also zephyr and anyone else that posts here in support of this non-issue! hehe

I also agree that probably it shouldn't be marked solved...

VastOne, there might also could be a better or more proper name for the thread?

[VastOne]

There are two issues (related) on some VSIDO and Debian installs. The first is the systemd disk-device timeout of 1 minute and 30 seconds. The second issue is a stop in a 'maintenance mode' to ask for admin password or to continue on with a ctrl-d. Once you hit ctrl-d the boot continues on fine (in most cases)

These are the steps to reduce and/or fix curb the issue.   

First issue of 1 minute 30 second timeout - To shorten this timeout do the following:

Edit /etc/systemd/system.conf

Find the following:

Code Select Expand

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s

Change the lines to

Code Select Expand

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

For the second issue, I know of no fix although I can tell you it is ABSOLUTELY related to fstab

I took out all settings in fstab except for the / (root) device and rebooted perfectly ... no first issue and no second issue

I began putting mount devices back into fstab one by one and on every single one the same error manifested itself again.

I have the exact same machine and hardware on this build server and it DOES not have either one of these issues. The only difference is that / (root) is on sdc1 and on it's own on the SSD. All my other mounts on this machine are in theory 'behind' this in the boot process.. on the machine that is at issue, the / (root) is sda9 on a single massive partitioned drive. I am thinking that whatever the issue in fstab to systemd to the kernel is related to this positioning. I will continue to test to try to resolve it further. At the very least to have some traction and information to send it as a bug report to debian, kernel and systemd teams

I also know that Jed has further issues with this in that if he does not have things worded a certain way in fstab and runs into these errors, his NIC setup fails.. he can speak more to that issue

[zephyr]

Greetings Vger: Went ahead with a fresh install to metal, also ran into the 90 sec problem which I edited /etc/systemd/system.conf to 10 secs. The fstab file I trimmed off the swap. Booted and ctrl-d brought me up to login. Other than that it is a very good install.

flies high, goes fast...looks good! : )

Cheers

Z

[VastOne]

Thank you zephyr... I appreciate the help

What physical drive are you installed on and what else is loaded from fstab?  Mind posting your fstab?

How are you! Good to see you mate..

Cheers

[zephyr]

Doing well and good Vger! 

Physical drive is currently /dev/sdf.

Hopes this helps, not having any other issue than what we already know.

Cheers

Z

[PackRat]

For the second issue, I know of no fix although I can tell you it is ABSOLUTELY related to fstab

You think it might be a systemd (as it relates to fstab) issue?

systemd.mount

systemd-fstab-generator

debian systemd and fstab

mounting device with systemd - CentOS

Months ago I was looking through some Arch Wiki/forum stuff about systemd - mostly networking - and came across some users that were using systemd to mount devices (new feature at the time); runing their systems without an fstab file.

[VastOne]

Thanks PackRat.. I will look into those.. there is TONS of information about the issue from google but most of it all about syntax in fstab being the culprit

This is NOT the case with what I have tested ... I have gone from a complete bare fstab to letting Disk Manager handle the adding and I can verify it (syntax) is absolutely correct

But again.. if I only boot with root in fstab and nothing else the first issue both issues goes away completely

They are related

[VastOne]

In the reddit one you posted PackRat it talked about the nofail option as being the solution

So I did this to mine (example:)

Code Select Expand

UUID=00f6ef9a-9922-4688-be8f-92b1bb6ca94d /media/sda5 ext4 defaults,nofail  0 2

and had a completely clean boot for the first time on the V-Ger machine in almost a year

Note:  I also made the change on the numbers at the end too.. it used to be 0 0 but is now 0 2 as systemd seems to have issues with 0 0

Note 2: I also ran this because apparently any etc changes need this for systemd to work correctly

Code Select Expand

sudo systemctl daemon-reload

Now I can watch the fucking World Series

[VastOne]

Doing well and good Vger! 

Physical drive is currently /dev/sdf.

Hopes this helps, not having any other issue than what we already know.

Cheers

Z

Thank you for making the effort to help in solving this Zephyr, it is greatly appreciated

If you make your /home drive this

Code Select Expand

UUID=585ff807-f3e1-498c-9cc9-b7b11f730cfa   /home   ext4   defaults,nofail   0   2


and then run

Code Select Expand

sudo systemctl daemon-reload


I think you would be golden and would see no errors on the reboot...

Cheers mate

[zephyr]

Yes indeed!  Spot on and works as advertised! : )

The theming looks great, the installer was also quick and fully detailed. Very nice job!

Thanks

Z 

[lwfitz]

This has been an ongoing issue for me for at least six months. I posted about it and was never able to get any movement with it. So out of frustration I just removed System D and pinned the system d apps so they wouldnt install with updates.

[Snap]

Glad you solved this, guys.

I just want to point that this sounds more like a (welcomed) workaround than a true solution. IIRC, the nofail option silently (thankfully) ignores errors and keeps the thing going. I use that option for external drives included in fstab that may or maybe not present. With the nofail option there are no complaints if the drive is missing and the rest of the drives mount normally. Otherwise it stalls (with whatever init).

[VastOne]

^ That is correct Snap and the reason why this will not be marked as solved

The frustration of this has not diminished either

[jedi]

As with all things on the VSIDO forums, just post it and they will come and fix it!  I should have listened to VastOne a while back on this one!

With the above two mentioned "fixes", I am now booting with 0 wait time.  Like instantaneously!  Really   

[VastOne]

Glad to help Jed, as always

It is your thread so you can name it whatever you want ... Just do not add solved to it and yes I agree it should be changed

I would think something including disk-dev 90 seconds systemd and ctrl-d to continue would be helpful