I have been living with a 90 second boot time for a while and I thought I probably should fix it. During bootup, there is a message that says “A start job is run for /dev/disk/by-uuid/UUID 1min 30s”. Doing some research, it seems to be due to systemd not recognizing a partition that I manually added to fstab. The partition is a storage that I have kept over the years and I have been manually added it to any distros that I’m using. I search for a way of lowing that timer or a correct method that is sanction by openSUSE on how to add UUID’s but I could not find any documents. The lengthy boot problem is not a showstopper for me but rather a nuisance and any help on this would be appreciated. Thanks
I am using a Dell XPS 15 7590 laptop that has windows 10 and another distro “mageia” installed along with openSUSE.
Your description sounds like that the “storage” partition is an external drive or an other computer which are not online when you start the computer where this waittime occurs (if this is not the case, please describe your setup more precisely!)
You need to apply following stuff to your fstab: https://wiki.archlinux.org/title/fstab#Remote_file_system
I also tried the nofail options which did not change my 90 second boot time. I also changed the default start stop time in /etc/systemd/system.conf which also had no effect. I wonder why these options exists if there is no effect? Again, thanks for your input.
journalctl | grep -i uuid should report the same /dev/disk/by-uuid/ UUID that is causing the timeout. Hopefully it will be evident whether it matches any existing fstab entry or corresponds to some device name you can identify.
Does replacing the resume= entry with noresume on the linu line by striking the E key at the Grub menu before proceeding eliminate the delay?
I have a similar problem that may need a new thread.
I tried to take a look at Chrome OS Flex. I created a usb boot stick to check it out. It is a little clunky but that is a different issue. After I booted to it a few times from my desktop, I noticed it added an entry to my grub menu “Chrome on sdc1”
This pc multiboots from 2 different drives: an hd and an ssd. My main operating is TW on the ssd. But after the last update, and after booting Chrome OS from the usb stick, my pc is locking up. I have to power down to get control again. To avoid the lockup for something I had to do on a deadline, I booted TW on the hd. But, it won’t boot. I get the 90 second delay described by the OP but, in my case, it is trying to access sdc. It does this over and over until I give up and (in maintenance mode) I enter “systemctl reboot” to get to the grub menu and boot TW on the ssd. I haven’t yet tried to boot TW on the hd with the usb stick is in place. But, as I type this, I realize should see if plugging in the stick “solves” the problem.
Still, I want the proper grub menu and proper booting. So, I need to reverse what Chrome OS Flex did without my permission.
I don’t recall. I accept that this could be a new thread but I wondered if curing that 90 second delay would get me back to a normal boot. Also, booting with the usb stick inserted did NOT fix the problem.
THAT IT’S!! Thank you for catching that. I corrected my fstab and now my boot time is down to 5 seconds.
I occasionally distro hop, trying out new linux flavors while keeping the Win10 and openSUSE partitions unchanged and I have been designated the same swap partition when I install new distros. I’m wondering if that caused the UUID to change and messing up my boot time on Leap.
Debian based distros (Debian, *buntu, Mint at least) do not provide any option to not format an existing swap partition, except by selecting during distro installation to not use it.