You are not logged in.
Hi,
the recent update broke my system. I did everything as described in the anouncement.
- udev hook is used
- the lvm.conf was properly updated
- lvm wait is not used
before rebooting I also did:
If you run pacman -Syu and update device-mapper, linux and lvm2 at the same time, you will get an error message that /sbin/dmsetup is missing. Run mkinitcpio -p linux again after the update to avoid any problems.
I have a LVM inside a luksCrypt container. After rebooting, I am asked for my password and then goes to recovery with the message:
The root device /dev/mapper/[my volume]-root could not be found.
I neither changed my hooks in mkinitcpio nor did I modify their order.
I used a rescue system to both recreate (multiple times) the grub config and linux image following the wiki (https://wiki.archlinux.org/index.php/Pa … onger_boot) without success.
Any ideas?
Thanks!
Last edited by cs (2013-02-13 15:52:20)
Offline
I have found a temprary fix:
in the recovery shell:
lvm vgchange -ay [groupvolume]
fixes it! Any ideas how to fix this permanently?
Last edited by cs (2013-02-13 16:31:48)
Offline
- the lvm.conf was properly updated
What did you update, exactly? Virtually everyone uses the default configuration and shouldn't need to change anything.
Offline
- the lvm.conf was properly updated
What did you update, exactly? Virtually everyone uses the default configuration and shouldn't need to change anything.
Yes, I meant that no .pacnew file was created because pacman updated it (because I did not modify it previously).
Offline
That's good. What do your HOOKS line and kernel command line look like?
Offline
they are
base udev modconf block encrypt lvm2 filesystems keyboard fsck
and
/vmlinuz-linux root=/dev/mapper/vgroup-root ro cryptdevice=/dev/sda2:vgroup i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 quiet init=/usr/lib/systemd/systemd
Last edited by cs (2013-02-13 17:27:23)
Offline
Now I am confused - I have been using the exact same setup for months without the slightest trouble.
Offline
Now I am confused - I have been using the exact same setup for months without the slightest trouble.
me too! :-S I changed nothing!
Offline
See also: https://bbs.archlinux.org/viewtopic.php?id=158012 and https://bbs.archlinux.org/viewtopic.php?id=158019
Both posters read the news, made the requisite changes, rebuilt their initrd and pfft...
Offline
I am unable to get this setup to NOT work, on both my RAID and my non-RAID + LUKS setup. Right now, I can't see why this could possibly fail.
Offline
my MODULES array is empty... maybe there's a problem?
Offline
my MODULES array is empty... maybe there's a problem?
No.
Offline
To take the obscurity to the extreme, I just installed a test VM with LVM on top of LVM: http://i.imgur.com/orTAktt.png Other than adding 'lvm2' to the HOOKS and setting root=/dev/vg2/root in the bootloader, no other tweaking is required to make this boot.
Back to topic: when you get dropped in the ramfs emergency shell, can you execute udevadm info --query=all /dev/mapper/vgroup? It should list some properties, among those ID_FS_TYPE=LVM2_member.
Offline
Hello, I have an problem similar to this one. But my boot setup is slightly different, because I use my own mkinitcpio hook to encrypt my disk from smartcard.
I have two GPT-partitions on the harddisk (boot and a lvm "physical volume"), the smartcard hook only encrypts the pv and normally without the last changes to udev and lvm in the boot procedure, everything is working and my system boots perfect.
But now I got dropped in the initrd rescue shell, after entering my passphrase to access the plugged in smartcard which encrypts my disk. The strange part is, if I enter "exit" to continue the boot process, everything is working as expected.
The order of my hooks in mkinitcpio.conf are the following: HOOKS="base udev autodetect block keymap smartcard encrypt lvm2 resume filesystems keyboard fsck"
(The "encrypt" hook is only needed to add corresponding binaries to the initrd)
Maybe there is a change in when the system is scanned from lvm for new pv's? Or a timeout value is too low.
The main problem is, that I can't switch the "smartcard" hook easily to 'early_run' because it depends on other later hooks (to detect the smartcard reader).
Sorry for my english, I hope this is understandable.
Moved to this thread.
Last edited by tranqil (2013-02-14 08:34:25)
Offline
Back to topic: when you get dropped in the ramfs emergency shell, can you execute udevadm info --query=all /dev/mapper/vgroup? It should list some properties, among those ID_FS_TYPE=LVM2_member.
Yes, all properties are shown and seem to be correct.
Offline
See the main thread; there is a proposed fix there...
https://bbs.archlinux.org/viewtopic.php?id=158012
Offline
Thank you jasonwryan for the hint, I don't found this thread first
Offline