FS#31306 - /home fails to mount with lvm, systemd and linux-3.4.9

Attached to Project: Arch Linux
Opened by Damien Robert (Gondolin) - Monday, 27 August 2012, 15:24 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 29 August 2012, 10:12 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I have my / and /home partitions in an lvm. Since kernel 3.4.9, systemd times out when trying to mount /home, but / is mounted just fine. This happen with systemd-188 and systemd-187. If I mount the partition by hand using mount rather than systemd, the /home partition is mounted fine. An fsck give no error and I see nothing strange in the logs apart from the systemd timeout. Going back to linux kernel-3.4.8 everything works fine again, be it with systemd-188 or systemd-187. This happen with two different laptops.

Additional info:
* package version(s): linux-3.4.9 + lvm and systemd
* Logs:
Aug 27 17:15:43 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2˻d4f39\x2db2fc\x2d6f6521d380fb.device/start timed out.
Aug 27 17:15:43 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2˻d4f39\x2db2fc\x2d6f6521d380fb.swap/start failed with result 'dependency'.
Aug 27 17:15:43 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2˻d4f39\x2db2fc\x2d6f6521d380fb.device/start failed with result 'timeout'.

/etc/fstab:
UUID=85f0acdd-b80f-4f39-b2fc-6f6521d380fb swap swap defaults 0 0
UUID=a2221eb4-ff88-4ef4-af93-f1eca17a735e /home ext4 defaults,nobarrier,noauto,x-systemd.automount 0 1
UUID=e7775584-22a9-49a4-adf1-6afc8683a37a / ext4 defaults,nobarrier 0 1
(removing x-systemd.automount change nothing)

Steps to reproduce:
Upgrade to the latest arch kernel using an lvm partition for /home and booting with systemd
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 29 August 2012, 10:12 GMT
Reason for closing:  Not a bug
Comment by Damien Robert (Gondolin) - Monday, 27 August 2012, 15:26 GMT
The logs concerned only the swap (which is also inside the lvm and timeout), here are the ones concerning /home:
Aug 27 17:17:55 Gondolin systemd[1]: Job dev-disk-by\x2duuid-a2221eb4\x2dff88\x2d4ef4\x2daf93\x2df1eca17a735e.device/start timed out.
Aug 27 17:17:55 Gondolin systemd[1]: Job home.mount/start failed with result 'dependency'.
Aug 27 17:17:55 Gondolin systemd[1]: Job systemd-fsck@dev-disk-by\x2duuid-a2221eb4\x2dff88\x2d4ef4\x2daf93\x2df1eca17a735e.service/start failed with result 'dependency'.
Aug 27 17:17:55 Gondolin systemd[1]: Job dev-disk-by\x2duuid-a2221eb4\x2dff88\x2d4ef4\x2daf93\x2df1eca17a735e.device/start failed with result 'timeout'.
Aug 27 17:18:04 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2d4f39\x2db2fc\x2d6f6521d380fb.device/start timed out.
Aug 27 17:18:04 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2d4f39\x2db2fc\x2d6f6521d380fb.swap/start failed with result 'dependency'.
Aug 27 17:18:04 Gondolin systemd[1]: Job dev-disk-by\x2duuid-85f0acdd\x2db80f\x2d4f39\x2db2fc\x2d6f6521d380fb.device/start failed with result 'timeout'.
Comment by Dave Reisner (falconindy) - Monday, 27 August 2012, 23:04 GMT
I can't reproduce this. Do those /dev/disk/by-uuid symlinks exists when the dependency times out? This seems like some upgrade failure more than a kernel/systemd problem.
Comment by Damien Robert (Gondolin) - Tuesday, 28 August 2012, 12:07 GMT
The strange thing is that it happen to two differents laptop, and I don't see how it could be an upgrade failure because when I install back linux-3.4.8 using pacman -U it works again. I have everything in lvm, including /boot and the swap, so I have to add the lvm2 hook to mkinitcpio. Maybe the errors is related to the way the initrd is produced between 3.4.8 and 3.4.9.
Comment by Dave Reisner (falconindy) - Tuesday, 28 August 2012, 12:12 GMT
Sooo... do the by-uuid symlinks exist after the dependency timeout?

Do you have any interest in troubleshooting this on your own or am I going to be left here to guess? I have no reason to believe there a problem here until you can _reproduce_ it. Merely downgrading to 3.4.8 is not a strong sign of 3.4.9 being at fault.
Comment by Damien Robert (Gondolin) - Tuesday, 28 August 2012, 13:34 GMT
Yes of course they exist, otherwise mount would fail too!
I agree that there is no reason for 3.4.9 to be at fault, otherwise I would not be the only one having this bug, but I do have this problem on two different laptops, so I can reproduce it! Now when I upgrade to 3.5.3 using testing, the problem migrates in the initrd step: the lvm2 hook finds no volume group. Since my / is in lvm, I get dropped to an emergency shell. Now the strange thing is that lvm vgchange --sysinit -a y do finds all my volumes group, and when I continue the initrd booting process by existing the emergency shell, the rest of the boot is fine and systemd mounts /home and swap without problem this time. (This is on one of the two laptops, I don't have access to the other to try it on it too right now)
Comment by Dave Reisner (falconindy) - Tuesday, 28 August 2012, 13:43 GMT
> Yes of course they exist, otherwise mount would fail too!
No, that is completely false. mount will use libblkid to scan the available block devices and find the matching tag. systemd relies on the udev symlinks to appear before it considers the device available and will mount it. Did you actually check this? Or are you just yes'ing me?

I'm still waiting for you to provide useful debugging info. The 3.5.x bug is known, and completely unrelated. Given that it's slotted to move to [core] in the next few days, I'm inclined to just mark this bug as invalid.
Comment by Damien Robert (Gondolin) - Wednesday, 29 August 2012, 10:09 GMT
Oh I did not know that about mount. I had only checked that mount /home worked, not that the uuid symlinks existed, sorry for being an idiot! (and the reason that I did not check for the symlinks directly when you asked the question is that I had already moved to 3.5.3 where the bug does not happen). So I now have the 3.5.3 kernel on both affected laptops since it moved to core, and the bug is not there anymore (there is a lvm problem at the initrd, but as you say it is unrelated). To get at the bottom of the uuid symlinks question I reinstalled kernel 3.4.9 on one of the laptop, and the bug did not come back. So I don't know what happened and you should close this bug, sorry for wasting your time :-(

Loading...