Arch Linux

Last time I checkted, the units in the upstream package contained lots of redhat-isms and referred to units that do not exist in upstream systemd. That's why I wrote my own units, which are way simpler than what lvm upstream provides.

Upstream is interested in your opinion. They strive to use unified configuration files across all distributions.

The example I gave in #19 does not indicate a replacement of RedHat specific bits, but I could be wrong. Did not check that much.

Comment #21 indicates that a lot of testing goes into these sensitive settings. I want to help unifying these configuration files with the little knowledge I have.

I just went over the comments from the redhat bug report and I think I know what I should do. I am unsure when I'll have the time, but I'll keep you updated.

Splendid! Let me know when you need victims ... erm testers :) .

This regression appears to have caused my separate logical volume for /usr to fail to mount. Downgrading to lvm2 2.02.105 made it work again.

Please test lvm2 2.02.106-2 in testing. It now uses the systemd unit provided from upstream. I doubt that it fixes your problems, but at least you can now provide proper information to the upstream bug report.

Thank you for your time and especially your effort (judging from the commit log).

It does not fix my issue, I'll report back to the upstream developers. Let them have their spin with it.

Again, thank you.

I can also confirm this bug - it rendered my Arch box unbootable even in systemd rescue mode. I have /home on lvm+md, everything else on a basic partition. The boot process almost consistently hung (with 1 in ~20 boots succeeding - race condition?) on trying to fsck (or mount, with fsck disabled) the /home partition. Downgrading to 2.02.105-2 fixed the issue.

I question the severity of the bug report - looking at the forums it's not just me that has been left with an unbootable system since this update. Does this not qualify for critical status?

@Dark & @ashren: did you try the new testing package as suggested in this bug?

Maybe I should open a new RH bug...

You should definitely reopen the existing bug report that got closed, as this is clearly not a packaging problem. I am not of much help, since I cannot reproduce this problem.

You could post the output of systemctl status lvm2-pvscan@a:b.service (use tab completion on the status command to find out the correct a:b). For me, this returns the following (which is correct):

$ systemctl status lvm2-pvscan@8:4.service
● lvm2-pvscan@8:4.service - LVM2 PV scan on device 8:4
Loaded: loaded (/usr/lib/systemd/system/lvm2-pvscan@.service; static)
Active: active (exited) since Mi 2014-04-30 10:18:01 CEST; 2h 18min ago
Docs: man:pvscan(8)
Process: 278 ExecStart=/usr/bin/lvm pvscan --cache --activate ay %i (code=exited, status=0/SUCCESS)
Main PID: 278 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/system-lvm2\x2dpvscan.slice/lvm2-pvscan@8:4.service

Apr 30 10:18:01 lije lvm[278]: 2 logical volume(s) in volume group "lije" now active
Apr 30 10:18:01 lije systemd[1]: Started LVM2 PV scan on device 8:4.

$ systemctl status lvm2-pvscan@9:0.service
● lvm2-pvscan@9:0.service - LVM2 PV scan on device 9:0
Loaded: loaded (/usr/lib/systemd/system/lvm2-pvscan@.service; static)
Active: active (exited) since Mi 2014-04-30 10:18:02 CEST; 2h 18min ago
Docs: man:pvscan(8)
Process: 389 ExecStart=/usr/bin/lvm pvscan --cache --activate ay %i (code=exited, status=0/SUCCESS)
Main PID: 389 (code=exited, status=0/SUCCESS)

Apr 30 10:18:01 lije lvm[389]: 3 logical volume(s) in volume group "architect" now active
Apr 30 10:18:02 lije systemd[1]: Started LVM2 PV scan on device 9:0.

As you can see here, it lists the number of LVs that got activated. There could also be an error message here, which would be interesting.

Another question: Do you activate lvm2 in initramfs, too? If so, are you using base+udev+lvm2 or systemd+sd-lvm2 hooks?

I have base+udev+lvm2. Can I safely replace those? According to the wiki, the systemd does not work.

https://wiki.archlinux.org/index.php/mkinitcpio#Common_hooks

My current layout:

HOOKS="base udev autodetect modconf lvm2 block filesystems build_system keyboard fsck shutdown"

Should that be:

HOOKS="systemd udev autodetect modconf sd-lvm2 block filesystems build_system keyboard fsck shutdown"

???

About the missing install_tmpfiles_configuration line, that was meant as an observation. I hope you did not consider that as offensive. I really appreciate your help on this.

You can omit shutdown entirely (it has no effect with systemd, and is no longer needed with base). I have no idea what build_system is, so I can't comment on that (if it uses a run script, it won't work with systemd).

This line, for example, is correct: HOOKS="systemd autodetect modconf sd-lvm2 block filesystems keyboard fsck".

However, I am much more interested in the status output from lvm2-pvscan@.service.

The build_system is a script mounts part of my partitions (/usr , /etc , /opt) on seperate btrfs lv's located on the same LVM.

As per the RH bug: Only the swap is mounted 'automatically' from an fstab. I mount the other partions by copying /etc/fstab from my lv containing /etc and then loop over each partition with a mountpoint located under /root.

So, I am suffering the same bug. I have posted build_system and fstab to help you understand my lousy explanation:

build_system http://http://pastebin.com/raw.php?i=sLfx1H4b
fstab http://pastebin.com/raw.php?i=CZUP3PMA

This implies I have to write a systemD service that does the same as my build_system script and move that into the initramfs. That should do it I think.

Yeah, that should work. sd-lvm2 does not have add_runscript (like lvm2) because I take it systemD does not execute those. However, sd-lvm2 does copy over the *.service files. ... right? :)

You should have mentioned this earlier. I looked at the systemctl output from the rh bug report again, and I noticed that _none_ of your LVM devices are registered to systemd.

Can you paste the output of: udevadm info /dev/main/swap

Here it is: http://pastebin.com/raw.php?i=HfWFeyAh

I cannot see anything wrong or missing here, can you check systemctl again for the missing devices?

This is with your testing package: http://pastebin.com/raw.php?i=PQmY2rBG

sdb .. sde are part of a broken card reader.

I migrated to a systemd initrd which works around the problem.

It does not appear to have native support for resuming after suspend to disk. So I made something myself which does that.

This is interesting. This means that the legacy initramfs has some problems that the systemd one hasn't. I have no clue right now what that would be - however, in my tests, the legacy initramfs also initialized properly.

Yes, my thoughts exactly.

However, on the other side. I tried to setup my filesystems using my old build_system script instead of fstab entries with x-initrd.mount. This seemed to work, but then systemd-udevd hangs after switching root. It somehow fails to do a sd_notify.

Currently, it's just fstab with the x-initrd.mount option for the systems that I used to mount myself.

I also looked at dracut to reliably implement resume from disk. Would you like me to provide my findings on how to do this for the hooks in mkinitcpio? (in a seperate task ofc)

Has there been any workaround for this issue? Entering emergency shell drives me crazy (mostly becasue of 1:30min timeout), almost every boot I have to `vgchange -ay` to boot my system properly. Thanks in advance.

Yes, a systemd based initrd appears to work around the issue.

Indeed, I switched from:
HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard lvm2 usr fsck shutdown"
to:
HOOKS="systemd autodetect modconf sd-lvm2 block filesystems keyboard usr fsck"

and the issue is gone. Thank you.

Status?