90 second boot time.

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

You can see for your UUID with:


and compare it with your /etc/fstab

Does your custom fstab entry for the external drive include the mount option nofail? If not, try adding it.

The 90 second default start timeout value usually is controlled by /etc/systemd/system.conf, along with other timeouts.

Thanks all for your help. I ran the following:

├─nvme0n1p1 F8AAFAAEAAFA6910 ntfs
├─nvme0n1p3 9C52590C5258EC90 ntfs
├─nvme0n1p4 0A423E54423E452B ntfs
├─nvme0n1p5 80D04125D0412330 ntfs
├─nvme0n1p6 ae40dd50-5f57-4f18-8ba0-140916236092 swap
├─nvme0n1p7 8bf9b888-e879-4f09-865e-9928d95758c4 ext4
├─nvme0n1p8 f5d878d5-a675-43a2-9d42-808ac0cbadbe ext4 /
├─nvme0n1p9 7c2e72ec-d34f-4c3d-bfd9-100599b1bdc8 ext4 /mnt/storage
└─nvme0n1p11 AAC7-883F vfat /boot/efi

My fstab: The /mnt/storage is a partition on a single 2-Tb SSD.

tony@AM:~> more /etc/fstab
UUID=f5d878d5-a675-43a2-9d42-808ac0cbadbe / ext4 defaults 0 1
UUID=AAC7-883F /boot/efi vfat utf8 0 2
UUID=ef280361-d5b1-4d71-b11a-713c14f8cd86 swap swap defaults 0 0
UUID=7c2e72ec-d34f-4c3d-bfd9-100599b1bdc8 /mnt/storage ext4 acl,user_xattr 0 0

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?

The UUID for swap differs…

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.

Different problem, needs new thread. Did you do a zypper dup while the USB stick was inserted or mounted?

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.

systemd will wait 90 seconds until it will break…

So every systemd command is involved…

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.