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:
### 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?
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:
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
Change the lines to
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
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
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
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
QuoteFor 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.
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
In the reddit one you posted PackRat it talked about the nofail option as being the solution
So I did this to mine (example:)
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
sudo systemctl daemon-reload
Now I can watch the fucking World Series
Quote from: 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
Thank you for making the effort to help in solving this Zephyr, it is greatly appreciated
If you make your /home drive this
UUID=585ff807-f3e1-498c-9cc9-b7b11f730cfa /home ext4 defaults,nofail 0 2
and then run
sudo systemctl daemon-reload
I think you would be golden and would see no errors on the reboot...
Cheers mate
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
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.
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).
^ That is correct Snap and the reason why this will not be marked as solved
The frustration of this has not diminished either
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
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
Quote from: 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.
When and where? I missed this
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...
"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,
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2
Try the above and the wait should be over, hopefully :)
Cheers!!!
Great tip, hackerdefo.
Do you know if there's a timeout option for systems running with sysvinit?
Quote from: 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?
Hi there Snap,
You can add,
nobootwait
to the fstab entry to avoid the wait.
Cheers!!!
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:
# /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.
Quote from: 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,
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2
Try 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...
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"...
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.
Quotehakerdefo, 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 -
QuoteI 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.
"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,
noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2
This 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,
noatime,discard
Cheers!!!
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) ???
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!!!
Wow, this thread has becoming really informative on the subject. Thanks guys for all the contributions.
QuoteUsing 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.
@ 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.
Quote from: 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.
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!!!
QuoteUbuntu and a few other distros
So all the Ubuntu derivatives will have this patch?
Quote from: PackRat on October 29, 2016, 11:21:17 AM
QuoteUbuntu 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,
man fstab
And 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!!!
Understood. Thanks for the info, hackerdefo.