Arch Linux User Repository

@srf21c, encrypted volumes are no edge case I think. And I didn't want to brake things with the last update. So I try to be responsive as much as my spare time allows ;) The only reason we load the kernel again is, to roll it back together with the root filesystem. If you have your kernel on a USB stick, this is not needed, as the kernel on it does not change on rollback. So for you it is as simple as disabling this feature of mkinitcpio-btrfs (after the next update). There is also the possibility to disable passphrase verification if you don't mind. You can remove --verify-passphrase from /usr/lib/initcpio/hooks/encrypt line 113.

@visit: Each kernel load requires two entries of the passphrase, the initial entry, then another entry where the user is required to verify the passphrase they just entered. Not sure why your setup does not include the 2nd verification prompt. Regarding the proposed changes, would it also solve the problem if the /boot partition on the USB stick was mounted or remounted during the boot process, just long enough to do any checks or rollbacks? Then /boot could be unmounted again as the boot process completes. That way we avoid the headaches of constantly having to syncing /boot dir between the USB stick and root encrypted volume every kernel update. Looking forward to the next update, I appreciate you being responsive to my special case needs.

@srf21c, "having the enter the passphrase a total of four times". I've setup a vm similar to your setup now. I have to enter the passphrase two times. Once for initial unlock and once the kernel is reloaded. Why is it four times at your side? With the next update we'll provide a param in /etc/default/btrfs_advanced to disable kernel rollback completely, which will stop your pain. In addition we'll provide a param to only reload the kernel if the version number or compile date has changed. This will only reload the kernel if you boot into __rollback or recently booted into it. But it depends on having the kernel (or a copy of it) on your root partition. With that you should get prompted for your passphrase only once on normal boots.

@xtfxme, nice idea, but it will with btrfs set-default, since the initrd present in __rollback will be used after a rollback and can contain a version without the stub. Also we would need a reliable way to install to subvolid=0 which can not be guarantied on initial setup. Another idea which came to my mind is, to upgrade the initrd while snapshotting to __rollback. But I'm not sure if we're able to execute chrooted commands at this boot stage.

@blip, your way is not working out. It simply returns btrfs regardless which device you add as param. For example: blkid -s TYPE -o value -lt TYPE=btrfs /dev/null The correct way is, to just suppress the error message. For the old device params the first condition works well: blkid -s TYPE -o value /dev/sda1 And for UUID the second condition was added: blkid -s TYPE -o value -lt UUID=fd88d586-bb4c-4fc7-81a6-f675e2829581 On of both will work anyway.

@blip Nice work, editing line 284 of /usr/lib/initcpio/hooks/btrfs_advanced and rebuilding initram with mkinipcpio -p linux eliminated the blkid error. Regarding the 2x kernel load, that only happens when I copy the /boot dir from the removable USB stick to the encrypted volume root. Having a copy of /boot contents on the root eliminates the cp: can't stat errors however the madness of having the enter the passphrase a total of four times on each boot (two for each kernel load) does not it a viable workaround for me.

@visit and @guotsuan I've the same message about blkid and could solve that by changing line 284 from: blkid -s TYPE -o value -lt ${root} to blkid -s TYPE -o value -lt TYPE=btrfs ${root} reading the manpage of blkid gave me the hint, that -t indeed needs a NAME=value, and since neither LABEL nor UUID are known I decided for TYPE=btrfs (which is what the script is looking for, I assume). @srf21c: I'm using dm-crypt on the root-device, too, and can confirm those error messages (can't stat ...), however my system seems to work fine anyway. I'm completely new to Arch (installed it 2 weeks ago) and also I'm new to btrfs so I don't know if I'm missing something. Why the kernel has to be loaded a second time?

hmm... booting older copies of the mkinitcpio-btrfs script is an interesting problem... i wonder if it should try and copy itself to the btrfs-root, ie. subvolid=0, and then place a stub in /usr/lib/initcpio/hooks?

@srf21c I'm still working on a solution for both of your issues (double passphrase and external /boot partition).

@kodiak How old are these snapshots you try to boot on your notebook? If they have the hook <0.4.0 they may not boot because of the major changes in 0.4.0. You can try to snapshot them again, chroot into the copy, update the hook to v0.4.0 and try to regenerate the initrd. After that you should be able to boot the copy. And please provide more details on your htpc setups. btrfs subvolume list btrfs subvolume get-default /etc/fstab /boot/grub/grub.cfg This will help finding the root cause.