Systemd automatically adds the swap partition of a connected hard drive to fstab. If the hard drive is removed for subsequent boots, then systemd silently pauses for a long time when booting. Steps to reproduce: 1) Connect a second hard drive with a swap partition to system 2) Boot 3) Do some work 4) shut down 5) Remove hard drive 6) Boot 7) Wait for a long time 8) Pull hair out trying to figure out what made the boot take so long 9) Remove new swap lines from fstab 10) Reboot 11) System is back to normal Notes: 1) For some reason the second hard drive showed up as sda and the original as sdb 2) The system booted fine because fstab called out the UUID's 3) The notes for my correct swap partition in fstab now show it on sdb and not sda 4) After looking around the net I see that there is a known issue with systemd, missing swap and no errors being reported Thank you, Jeff
Assignee: bugsquad => mageiaSource RPM: (none) => systemd
systemd does not automatically add any swaps to /etc/fstab. It will never edit your fstab for you. So something else is adding the device to fstab. systemd considers things you add to fstab to be required components of boot. If you don't want it to fail and drop you to an emergency shell when the fstab entry does not exist, then you need to add the "nofail" mount option. So I'm not sure what is automatically adjusting fstab but I'd suggest that it should default to adding the nofail option to any swaps it adds. I'm not sure what component adds swaps to fstab, but I'm guessing some kind of harddrake stuff.
Source RPM: systemd => drakxtools
Summary: Systemd automatically adds swap to fstab and then pauses for a long time when it is missing => External drives with swaps are automatically added to fstab which may slow boot when drive is unplugged.
I repeated the experiment with a similar drive** and I could not reproduce the problem. I even went to "Manage disk partitions" in the MCC just to see if maybe I had done that before and forgot, but it didn't cause the problem either. As far as I could determine nothing ever altered fstab and the computer had no problems upon subsequent boots. The sda/sdb ordering where still switched but I'm going to blame that on the motherboard. I'd close this but I can't find an option for cannot duplicate. --Jeff **I was backing up the files on a laptop before it went in for repairs. Apparently the hard drive failed some of their tests so they scrapped it and installed a new one, but didn't copy the contents to the new drive. I don't know what size the partitions were or the order, so I can't do an exact test. The hard drive wasn't the reason the laptop went in, so I wasn't expecting them to scrap it.
"WORKSFORME" is the closest resolution for to "Cannot duplicate". FWIW, the swapping of sda and sdb is pretty much expected. Many different things can happen in the kernel to affect the ordering of such things (e.g. loading the USB kernel module before the kernel module for your SATA controller or vice versa. This is why, for many years now, we've always defaulted to partition UUIDs in our fstab entries and kernel command lines.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME