Package Details: mkinitcpio-btrfs 0.4.3-1

Git Clone URL: https://aur.archlinux.org/mkinitcpio-btrfs.git (read-only, click to copy)
Package Base: mkinitcpio-btrfs
Description: mkinitcpio hook containing advanced features for btrfs-based root devices
Upstream URL: https://github.com/xtfxme/mkinitcpio-btrfs
Licenses: BSD
Submitter: xtfxme
Maintainer: xtfxme
Last Packager: dywedir
Votes: 73
Popularity: 0.38
First Submitted: 2010-01-06 04:17 (UTC)
Last Updated: 2015-07-09 12:27 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 14 Next › Last »

kodiak commented on 2013-10-29 12:08 (UTC)

Thanks for updating the wiki-page. Still I am not able to able to get this working. My notebook (originally installed with initscripts, now systemd) claims /sbin/init not found when booting from a snapshot (actually it symlinks to busybox), and the htpc still keeps on rebooting when starting the __active/kernel once the hook is installed, no error message shown.

sysfu commented on 2013-10-25 22:52 (UTC)

@visit. OK, the results are in. Copying /boot files to corresponding /boot dir on root partition eliminated all of the error messages after the "Press any key to prepare for BTRFS rollback..." message such as; "cp: can't stat '/new_root/__active/boot/vmlinuz-linux' : No such file or directory <snip> It does load the kernel twice however which was odd, so I get double prompted for the passphrase to unlock the encrypted volume. Not a viable workaround. The blkid errors are still there. Removing the subvol=__active option in fstab had no discernible effect.

visit commented on 2013-10-25 22:41 (UTC)

@srf21c, yes, please try that. But keep in mind, that final kernel loaded by btrfs_advanced it the one from your root partition, not from /boot.

sysfu commented on 2013-10-25 22:38 (UTC)

@visit. I'll mirror the contents of /boot on the flash drive to the hard drive, then reboot and see if it gives me the same error. Regarding the subvol=__active in fstab, I believe that is left over from the initial setup before mkinitcpio-btrfs was installed and configured. I'll remove it and see what happens.

visit commented on 2013-10-25 22:36 (UTC)

@xtfxme, sure. The message is not an error, since we support all types since 0.4. Its just an STDERR output of the first condition. Fixed it in my latest pull request: d07a3335b668783e6feb20c1c189077ed249ea28. I would not remove it.

visit commented on 2013-10-25 22:27 (UTC)

@srf21c Hmm... your grub.cfg looks fine (through I've never seen a dm-crypt setup). The issue with that setup is, that btrfs_advanced expects the kernel on your root device. Through you can change the kernel path via a hidden variable in /etc/default/btrfs_advanced, this does not help, as you don't have /boot mounted when the hook is running. I need to think about that for a while... :) A temporary solution would be to store the kernel in the /boot directory and over-mount it later with your real /boot partition. In your fstab the subvol=__active is no longer needed, but does no harm as it is not used in early boot stage. It's just affecting grub-mkconfig and later fs remount.

xtfxme commented on 2013-10-25 22:19 (UTC)

@visit, the check of FS type is flawed anyway and is really just a remnant of the original impl; see (some) of the comment by falconindy here: https://bugs.archlinux.org/task/30526 ...in addition to the relevant older comments here leading up to that.

sysfu commented on 2013-10-25 21:48 (UTC)

@visit Using the grub2 bootloader, unlocking a plain dm-crypt volume (no LUKS) and mounting a partitionless BTRFS volume that spans the entire encrypted /dev/mapper/btrfs-root device. /boot/grub/grub.cfg https://privatepaste.com/5f779d6eec /etc/fstab https://privatepaste.com/19a2fb3834

visit commented on 2013-10-25 21:29 (UTC)

Thanks @guotsuan. This is what I was looking for :) Will fix that with the next release, as it does not do any harm.

visit commented on 2013-10-25 21:25 (UTC)

@srf21c: I've rethought your last post and still can't imagine where the blkid error is coming from. Which bootloader are you using? Can you share its config for further analysis? I also don't understand your initial error about missing '/new_root'. This directory is part of the filesystem packed in your initrd. It is the mount point used to mount the real root partition after executing the init hooks. Maybe it the same issue kodiak had, because '/__active' is no longer needed in the kernel path.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 14 Next › Last »