FS#51818 - [linux-lts][linux-zen][linux-grsec][linux] move to mkinitcpio hook lvm2 breakage
Attached to Project:
Arch Linux
Opened by Alexandre Figura (arugifa) - Monday, 14 November 2016, 12:54 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 09 December 2016, 23:41 GMT
Opened by Alexandre Figura (arugifa) - Monday, 14 November 2016, 12:54 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 09 December 2016, 23:41 GMT
|
|
Details
Description:
I just upgraded my system with ``pacman -Syu``. But when I rebooted my machine, my system was broken: lvm was unable to find my root file system. It appears that lvm2 requires readline 6, but readline 7 was installed during the upgrade. I observed this dependency while analysing pacman logs (see attachment), when pacman generated a new kernel image. This can be reproduced with ``mkinitcpio -p linux``. Hopefully, I had still readline 6 in my pacman cache. So I booted on a live key, chrooted in my system, and installed readline 6 (``pacman -U /var/cache/pacman/pkg/readline-6.3.008-4-x86_64.pkg.tar.xz``). But new versions of bash and gawk which have been installed during the upgrade depend on readline 7. So I downgraded bash and gawk. Unfortunately, when I rebooted, lvm was able to find my root file system, but my newly updated gnome-shell (3.22.2-1) refused to start as it depends on readline 7. Finally, I copy/pasted the shared library file of readline 6 and installed again readline 7: lrwxrwxrwx 1 root root 16 Nov 6 18:42 libreadline.so -> libreadline.so.7 lrwxrwxrwx 1 root root 27 Nov 14 13:02 libreadline.so.6 -> /usr/lib/libreadline.so.6.3 -r-xr-xr-x 1 root root 344904 Nov 14 13:03 libreadline.so.6.3 lrwxrwxrwx 1 root root 18 Nov 6 18:42 libreadline.so.7 -> libreadline.so.7.0 -r-xr-xr-x 1 root root 363064 Nov 6 18:42 libreadline.so.7.0 lvm is now able to find again my root file system when booting my machine. And I can continue to use the cutting edge packages which depend on readline 7. readline dependency for lvm2 should be maybe pinned or have an upper bound. Additional info: * package version(s): lvm2-2.02.167-2, readline-7.0-1 N.B.: a teammate had the same problem. Moreover, as this completely blocks systems using lvm2, I set the severity to critical :) 
pacman.log
(3 KiB)
|
This task depends upon
Had you posted the entire transaction from pacman.log, we'd be able to confirm this.
For reference, here is my pacman.log.
Can't we solve this with hooks in the future? IMHO the initramfs image should be generated at the end of the transaction, not as soon as kernel is installed.
But anybody has to do the work. This has to work with a combination of different kernels, initramfs images, initcpio hooks and their dependencies, ...
edit: specifically, see the timeline:
[2016-11-14 10:44] [ALPM] upgraded readline (6.3.008-4 -> 7.0-1) # this breaks the lvm2 dependency
[2016-11-14 10:44] [ALPM] upgraded linux (4.8.6-1 -> 4.8.7-1) # initramfs gets rebuilt with bad lvm2 binaries
[2016-11-14 10:45] [ALPM] upgraded lvm2 (2.02.166-1 -> 2.02.167-2)
No need to downgrade packages.
"mkinitcpio -p linux" from a chroot fixes it but I still can't boot the grsec kernel.
Edit: Please ignore my ignorance, I should have run "mkinitcpio -P" as suggested before.
No, it doesn't sound like you are if the prescribed fix doesn't help you.
> "mkinitcpio -p linux" from a chroot fixes it but I still can't boot the grsec kernel.
Of course it doesn't. 'mkinitcpio -p linux' only fixes the kernel provided by the "linux" package. Is there value in posting this on the front page? Maybe... I doubt anyone will read it, just as people don't seem to read my first post on this bug which recommends 'mkinitcpio -P', rebuilding *all* images for *all* kernels.
I think there is definitely value in posting this on the front page. I would have read it (just like I read the first post on this bug which recommends 'mkinitcpio -P', rebuilding *all* images for *all* kernels) and saved some stress and about an hour of my day.
This does...
* remove the initramfs regeneration from install script.
* add a pacman hook that runs mkinitcpio when /boot/vmlinuz-linux or an initcpio hook or install script changes.
That makes it rebuild the initramfs on linux update (obviously), and on package update for packages that ship initcpio files. This includes systemd, lvm2, mkinitcpio, ... Get a list of packages with:
pacman -Qoq /boot/vmlinuz-linux $(find /usr/lib/initcpio/ -type f) | sort | uniq
Finally this fixes consistency issue as the hook is run after the transaction. Things just get better, so we should go for it.
Two things to note:
* Every linux package (linux, linux-zen, linux-lts, linux-grsec, ... AUR packages like linux-git, ...) has to ship its own hook.
* This does not rebuild the initramfs on minor dependency updates. Is that required? A bugfix release for readline does not matter - soname bumps are caught by the package that depends on it, lvm2 in this case. IMHO we are fine with this.
We can work on this later, but let's make things work the easy way for now.
Tobias, your thoughts?
I took the shotgun approach to assignees, assigned anyone who was affiliated with any of the packages involved. This is a big enough problem I wanted to pull in as many people as I could.
Doug, your approach is just fine. ;) I did not blame anybody for whatever.
Are unique filenames for the hooks important? For example, what happens if an AUR package ships xx-linux.hook and another package also ships xx-linux.hook?
80-linux.hook
99-linux-bfq-haswell.hook
I had a same problem with linux-lts(4.4.31-1 -> 4.4.34-1), lvm2(2.02.166-1 -> 2.02.167-2) and readline(6.3.008-4 -> 7.0-1) ... and I confirm for resolve problem with `mkinitcpio -p linux-lts`
Sorry for my bad english language.
See you
linux and linux-zen implemented this 3 weeks ago, and linux-grsec a week ago. Just waiting on linux-lts.