VSIDO Community

VSIDO Support => General Support => Topic started by: jedi on October 24, 2016, 02:29:48 PM

Title: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 24, 2016, 02:29:48 PM
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]
### 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!  8) 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?
Title: Re: NVMe Placeholder
Post by: VastOne on October 25, 2016, 01:18:48 AM
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]
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s

Change the lines to

Code: [Select]
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
Title: Re: NVMe Placeholder
Post by: zephyr on October 25, 2016, 07:00:04 AM
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
Title: Re: NVMe Placeholder
Post by: VastOne on October 25, 2016, 11:22:06 AM
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
Title: Re: NVMe Placeholder
Post by: zephyr on October 25, 2016, 12:24:01 PM
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
Title: Re: NVMe Placeholder
Post by: PackRat on October 25, 2016, 01:36:25 PM
Quote
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 (https://www.freedesktop.org/software/systemd/man/systemd.mount.html)

systemd-fstab-generator (https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html#)

debian systemd and fstab (https://www.reddit.com/r/debian/comments/2qn0vl/systemd_and_fstab/)

mounting device with systemd - CentOS (http://serverfault.com/questions/632075/convert-an-fstab-entry-to-a-systemd-mount-unit-on-coreos)

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.
Title: Re: NVMe Placeholder
Post by: VastOne on October 25, 2016, 09:44:07 PM
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
Title: Re: NVMe Placeholder
Post by: VastOne on October 25, 2016, 10:57:38 PM
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]
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]
sudo systemctl daemon-reload

Now I can watch the fucking World Series
Title: Re: NVMe Placeholder
Post by: VastOne on October 25, 2016, 11:20:46 PM
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]
UUID=585ff807-f3e1-498c-9cc9-b7b11f730cfa   /home   ext4   defaults,nofail   0   2

and then run

Code: [Select]
sudo systemctl daemon-reload

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

Cheers mate
Title: Re: NVMe Placeholder
Post by: zephyr on October 26, 2016, 01:35:53 AM
Yes indeed!  Spot on and works as advertised! : )

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

Thanks

Title: Re: NVMe Placeholder
Post by: lwfitz on October 26, 2016, 02:29:10 AM
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.
Title: Re: NVMe Placeholder
Post by: Snap on October 26, 2016, 09:38:31 AM
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).
Title: Re: NVMe Placeholder
Post by: VastOne on October 26, 2016, 11:46:53 AM
^ That is correct Snap and the reason why this will not be marked as solved

The frustration of this has not diminished either
Title: Re: NVMe Placeholder
Post by: jedi on October 26, 2016, 07:09:48 PM
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   ;D
Title: Re: NVMe Placeholder
Post by: VastOne on October 26, 2016, 10:25:50 PM
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
Title: Re: NVMe Placeholder
Post by: VastOne on October 26, 2016, 10:59:35 PM
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.

When and where?  I missed this
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 27, 2016, 11:41:40 PM
OK, just rebooted my HP laptop.  It had been 'up' for about 2 weeks.  This is the one I recently posted a scrot of at 101 days of uptime.  On reboot, no joy.  This is just a regular plain jane laptop with a liteonit SSD drive. (SATA2?)
I did a nano /etc/fstab from the emergency mode and added 'nofail' to the fstab.  Booted after that, though it seemed to take a little longer than normal...
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 28, 2016, 05:54:46 AM
"nofail" should be avoided as it'll keep trying to mount device even in its absense. Instead make your 'fstab' option to look like this,
Code: [Select]
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2
Try the above and the wait should be over, hopefully :)

Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: Snap on October 28, 2016, 06:38:31 AM
Great tip, hackerdefo.

Do you know if there's a timeout option for systems running with sysvinit?
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 28, 2016, 11:19:54 AM
Great tip, hackerdefo.

Do you know if there's a timeout option for systems running with sysvinit?
Hi there Snap,
You can add,
Code: [Select]
nobootwaitto the fstab entry to avoid the wait.
Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: PackRat on October 28, 2016, 02:21:09 PM
Just posting this comparrison out of curiousity (since mine is piqued by this issue); can't really comment on it.

This is from jedi's original post -

Quote
### 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

and this is the [near] default fstab from a clean install of Debian Testing I did yesterday:

Code: [Select]
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=dcf6fce4-beb2-4bdf-aa37-5961cec9638b /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda2 during installation
UUID=cab27a4f-73f1-45e2-95ae-0e18985aa857 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
#
UUID=4b6da59d-e2d8-4328-8212-dd10d480b301    /media/vgroup    ext4    defaults    0    1
#

The last line for the /media/vgroup I added mannaully after creating a logical volume group out of the remaining drive space (3 HDD on this old computer).

Interesting that there are some differences from what I'm use to seeing ( fstab was always similar to jedi's in the past) particulary on the swap file line; kind of wish I had made a /home with this install. Not sure if anything is relevant to jedi or lwfits' issues.
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 28, 2016, 04:20:52 PM
"nofail" should be avoided as it'll keep trying to mount device even in its absense. Instead make your 'fstab' option to look like this,
Code: [Select]
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2Try the above and the wait should be over, hopefully :)
Cheers!!!

hakerdefo, thanks for all your great input!!!  You say ""nofail" should be avoided as it'll keep trying to mount device even in its absense", and I'm wondering what exactly that means?  If the only thing in fstab happens to be the internal drives on the machine, and the drives all load correctly, is this not OK?  I guess I don't understand what you mean when you say they'll continue to 'try to mount'.

Also, do those 'options' you listed take into account the presence of SSD drives?  Pretty easy to destroy one if you make a mistake...

With all the reading some of us are doing on this, it looks like this is the most informative place on the net for this issue!!!  Your insight has proven invaluable!  Keep us informed of any new ideas you may have regarding this...

Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 28, 2016, 05:19:18 PM
PackRat, I suppose I should have mentioned, it isn't "completely/exactly" the original VSIDO installed fstab file.  I removed the commented out lines like "# / was on /dev/sda1 during installation"...
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 28, 2016, 05:23:50 PM
I've also just changed to PARTUUID as it appears that is the preferred method of naming when it comes to GUID and GPT disks. (i.e. not msdos formatted during partitioning, rather GPT)

Using the PARTUUID= resulted in an endless bootloop on login.  In other words, it would allow me to type in the password, wait for an agonizingly long time, then when it looked like it was going to boot in, it just sent me back to the lightdm login screen...

Mine is working fine, with no delays, no errors, and no changes other than the two fixes described above.  I also implemented hakerdefo's fstab options as well and all seems beautiful to me

EDIT: FUCK GUID and EFI    The term GUID is generally used by developers working with Microsoft technologies, while UUID is used everywhere else.
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: PackRat on October 28, 2016, 07:16:54 PM
Quote
hakerdefo, thanks for all your great input!!!  You say ""nofail" should be avoided as it'll keep trying to mount device even in its absense", and I'm wondering what exactly that means?

I think that was pretty much aimed at this post by snap -

Quote
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).

since he has used the nofail option on external drives (NFS or samba shares also come to mind); if the drive is detached or powered down, the system will keep trying to mount it. Since yours in an internal drive with the / partition that won't be the case. But, as snap pointed out, the nofail option is more a [non elligant?] work around, not an actual solution.
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 28, 2016, 08:19:32 PM
"nofail" option will keep trying to mount a device even if it's not available till the time-out is reached (default is 90 seconds). And the boot process will continue after the time-out period. In the absence of "nofail" option the boot process won't continue even after the time-out is reached. But thanks to "systemd" we can avoid the "nofail" option and use a better formula like this,
Code: [Select]
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2This entry will prevent "mount" from trying to auto-mount the device and leave that to the "systemd" daemon which is a bit more smart and a bit more flexible at this particular task. And a '2' second time-out period will ensure that the boot process won't stall in the absence of the device.
Regarding the SSD drives you can safely use the above formula. And I would suggest you to add following options to your SSD entry in the fstab for some performance benefits,
Code: [Select]
noatime,discard
Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: jedi on October 28, 2016, 09:09:01 PM
Thanks PackRat and hakerdefo.  I missed Snap's post.  Sorry 'bout that.

@hakerdefo, The 'discard' option enables Trim on drives that often have no need of it.  A better option, instead of 'discard', would be to just add a monthly cron job to make sure Trim is ran at least once a month.  On newer SSD drives, the 'discard' option can be quite hazardous to your drive.  Another quick note, if you leave an adequate empty, unpartitioned space on an SSD drive there is no need of Trim at all.

I did add your advised entries to my fstab with great success! (not the discard)  Utilizing the PARTUUID in /etc/fstab DID NOT work.  This is beyond the scope of this thread so I'm not pursuing it. (associating GUID with UUID has no bearing here and was my mistake)  ???
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 29, 2016, 05:45:31 AM
Hi jedi,
I stand corrected! "discard" option's benefits vary from model to model. I don't have any SSD [way way way over my budget ;)] so I have no personal experience but ext4 developer advises to use the following script to do the job instead of the "discard" option. You can run the script via a cron job to automate this task. Here is the script,

wiper.sh (https://raw.githubusercontent.com/Seagate/SMR_FS-EXT4/master/hdparm/wiper/wiper.sh)

Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: Snap on October 29, 2016, 08:30:34 AM
Wow, this thread has becoming really informative on the subject. Thanks guys for all the contributions.

Quote
Using the PARTUUID= resulted in an endless bootloop on login.  In other words, it would allow me to type in the password, wait for an agonizingly long time, then when it looked like it was going to boot in, it just sent me back to the lightdm login screen...

Really? I would never have thought of fstab or UUIDs in a boot loop like this. I would drive crazy for weeks trying fix something related with the X server! ...which is not the case as you pointed out. Obviously fstab ain't what it used to be.

Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: Snap on October 29, 2016, 09:26:43 AM
@ hackerdefo: tried the nobootwait option and didn't worked quite well. if the drive is present it doesn't automount any more. If the drive is off the booting sequence gets interrupted with errors. Back to nofail untill I find anything better.
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 29, 2016, 10:02:41 AM
@ hackerdefo: tried the nobootwait option and didn't worked quite well. if the drive is present it doesn't automount any more. If the drive is off the booting sequence gets interrupted with errors. Back to nofail untill I find anything better.
Hi Snap,
I forgot to mention in my previous post that this "nobootwait" option won't work in VSIDO or anyother Debian based distro by default as the Debian package-maintainers (util-linux team) for the package "mount" are not interested in implementing this. Ubuntu and a few other distros include the patch that enables the "nobootwait" option.
Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: PackRat on October 29, 2016, 11:21:17 AM
Quote
Ubuntu and a few other distros

So all the Ubuntu derivatives will have this patch?
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: hakerdefo on October 29, 2016, 12:14:21 PM
Quote
Ubuntu and a few other distros

So all the Ubuntu derivatives will have this patch?
Honestly I don't know! Simplest way to determine if the "mount" installed on your sysem has "nobootwait" option is to run,
Code: [Select]
man fstabAnd look for the following line,
Quote
...``nobootwait'' which can be applied to...
I think Ubuntu 12.04, 14.04, 15.10 have this but 16.04 doesn't.
Cheers!!!
Title: Re: A Start Job is running for dev-disk/x2uuid and similar errors
Post by: Snap on October 30, 2016, 06:15:19 AM
Understood. Thanks for the info, hackerdefo.