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 10 .. 14 Next › Last »

guotsuan commented on 2013-10-25 20:55 (UTC)

I got the errors -t needs NAME=value pair", which is followed by a printout of the blkid usage options too. But the system booted normally. I think the reason could be due to the util-linux is updated to the newest version. If in the boot parameters, I use the old obsoleted way "root=/dev/sda2" , for example. Then in the /usr/lib/initcpio/hooks/btrfs_advanced line 284: if [ "$(blkid -s TYPE -o value ${root})" != "btrfs" -a "$(blkid -s TYPE -o value -lt ${root} )" != "btrfs" ]; The "blkid -s TYPE -o value -lt ${root}" will report the error aforementioned. I'm wondering could this line be changed to if [ "$(blkid -s TYPE -o value ${root})" != "btrfs" -a "$(blkid -s TYPE -o value -lt ${root} )" != "btrfs" 2> /dev/null ] which eliminated the error and the reminding of the usage. I think it is safe to do so, because the "$(blkid -s TYPE -o value ${root}" is responded for checking the format of root system specified by the old traditional way as "root=/dev/sda2".

visit commented on 2013-10-25 00:06 (UTC)

I've updated the wiki page. If you have some spare time, I would appreciate a review from some experienced users. Thanks!

visit commented on 2013-10-21 23:24 (UTC)

@kodiak: Ok, this article is a little outdated (seen the deleted mark at the top of the page). I'm work on an update for it now.

kodiak commented on 2013-10-21 18:11 (UTC)

@visit: I went this way https://wiki.archlinux.org/index.php/Installing_on_Btrfs_root

visit commented on 2013-10-20 12:40 (UTC)

@kodiak: did you follow a special documentation? Because you wrote that your grub.cfg contains __active in the path, but if you just install the hook after a plain arch install, there should not bee a subvolume __active. Maybe there is a documentation issue in the wiki? For now you can check the Upstream URL and follow the setup HowTo from there.

visit commented on 2013-10-20 12:34 (UTC)

@srf21c: Having boot on a different partition in not supported in 0.4. This is related to the kexec feature to rollback the kernel also. But you can put it on a different subvolume without problems. Btrfs will mount subvolume /boot automatically. The /tmp/linux errors are from kexec, because it could not cp the new kernel to /tmp before.

sysfu commented on 2013-10-18 17:30 (UTC)

Getting a couple of nuisance error message on the console before X and GDM load. First one is a blkid error "-t needs NAME=value pair", which is followed by a printout of the blkid usage options. Second set of errors is after the "Press any key to prepare for BTRFS rollback..." message. "cp: can't stat '/new_root/__active/boot/vmlinuz-linux' : No such file or directory cp: can't stat '/new_root/__active/boot/initramfs-linux.img': No such file or directory Cannot open '/tmp/linux': (null) Cannot open '/tmp/linux': No such file or directory umount: can't umount /new_root: Invalid argument I imagine the first two cp errors have to do with the fact that the /boot resides on a removable USB drive and the /boot dir is not automatically mounted at boot. not sure how to address the /tmp/linux errors, or the umount error. I was initially getting cp error about a missing /new_root directory, so I mounted the root subvolume and created a '/new_root' subvolume along side the existing __active and __snapshot subvols.

kodiak commented on 2013-10-17 10:27 (UTC)

@xtfxme: I confirm, I did a fresh install and had no single problem (booted several times), until I installed this hook. Next boot brought the grube rescue, fixing path in prefix and after in grub menue (I had to cut the /__active) finally booted the image, but after a second it rebooted the system. De-installing the package, removing the hook from mkinitcpio.conf, reinstalling the package grub and grub-installing booted again. That is what happened on SAPPHIRE EDGE VS4. On thinkpad Z61m system boots with hook, but only after grub-installing once booted. Z61m is BIOS, VS4 runs in BIOS-Mode.

xtfxme commented on 2013-10-16 15:01 (UTC)

@kodiak, this could be related to the set-default stuff Michael added in 0.4, or the saving of the kernel... to trace the steps: all you did was install from scratch, then install this hook, and at this point it's failing?

kodiak commented on 2013-10-16 14:31 (UTC)

Me again, now I am sure that my problem depends on this hook. While I got my old notebook working, I did a fresh install on my htpc. All good until I installed this hook -> grub rescue, and even passing the right paths the system would insist on rebooting. To get it working again, I needed actual to reinstall the grub package, no just installing the bootloader again.

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