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: 72
Popularity: 0.011001
First Submitted: 2010-01-06 04:17 (UTC)
Last Updated: 2015-07-09 12:27 (UTC)

Latest Comments

falconindy commented on 2014-08-12 17:39 (UTC)

Is this hook ever going to be updated to make use of modernities like udev-based assembly? Large portions of the "run_hook" function and mount handler are redundant/superfluous in 2014. It would also be nice if this package were renamed as well to make it more obvious that this is off the beaten path. It's unnecessary for most btrfs users who just want a bootable system.

visit commented on 2014-02-28 21:15 (UTC)

sysfu, I never played with snapper, but in your previous comment I saw ".snapshots/2/snapshot/root". This looks like snapper is storing the root subvolume some folders deeper in the .snapshots directory. So, this will not work with mkinitcpio-btrfs, as we expect the snapshot directly in /__snapshot.

sysfu commented on 2014-02-27 23:34 (UTC)

I've created a related github issue for the snapper project here https://github.com/openSUSE/snapper/issues/54 It seems that the /.snapshots directory must be an actual btrfs subvolume and not a symlink in order for snapper to work properly.

sysfu commented on 2014-02-27 23:33 (UTC)

using the btrfs subvolume delete command does indeed remove the /.snapshots dir, however now that snapper has created a few timeline snapshots in that directory, they cannot be moved using the mv command. Attempts to do so created hundreds of errors like the one below. mv: cannot remove ‘.snapshots/2/snapshot/root/.gnome2/accels’: Read-only file system Furthermore, I've already tried essentially the same thing, and it only seems to cause snappers automatic hourly snapshot creation to fail with the errors which I already posted about it /var/log/snapper.log.

visit commented on 2014-02-27 19:55 (UTC)

sysfu, try # btrfs su de /.snapshots instead

sysfu commented on 2014-02-27 18:57 (UTC)

@visit, suggested procedure fails on the rm command [root@host /]# rm -r .snapshots/ rm: cannot remove ‘.snapshots/’: Operation not permitted

visit commented on 2014-02-27 11:52 (UTC)

sysfu, you need to create the symlink in /. # cd / # mv .snaphots/* /var/lib/btrfs/__snapshot/ # rm -r .snapshots # ln -s /var/lib/btrfs/__snapshot .snapshots And change the param back to: BTRFS_DIR_SNAPSHOT="/__snapshot"

sysfu commented on 2014-02-27 10:34 (UTC)

@visit: I tried again by deleting the __active/.snapshots btrfs subvolume and all contents. cd'd into /var/lib/btrfs__active then ran this command # ln -s /var/lib/btrfs/__snapshot .snapshots this created a symbolic link as shown here: [/var/lib/btrfs/__active] # ls -lad .s* lrwxrwxrwx 1 root root 25 Feb 27 02:22 .snapshots -> /var/lib/btrfs/__snapshot/ Rebooted but seeing these errors appear in /var/log/snapper.log: 2014-02-27 02:24:25 ERR libsnapper(1786) FileUtils.cc(SDir):84 - open failed path://.snapshots (Too many levels of symbolic links) 2014-02-27 02:24:25 ERR libsnapper(1786) Snapshot.cc(initialize):348 - reading failed I think __active/.snapshots must be a btrfs subvolume, and not a symbolic link.

visit commented on 2014-02-27 06:34 (UTC)

sysfu, you symlinked in the wrong direction. Try to create a symlink .snapshots -> /var/lib/btrfs/__snapshot in /__active and change your config back. Snapper should create snapshots in /var/lib/btrfs/__snapshot then.

sysfu commented on 2014-02-27 05:53 (UTC)

@visit/xtfxme I have the btrfs root mounted at /var/lib/btrfs via an entry in /etc/fstab. First I tried removing the __snapshot dir and replacing it with a symlink to __active/.snapshots/ like so # ls -l /var/lib/btrfs/ drwxr-xr-x 1 root root 152 Jan 17 06:29 __active/ drwxr-xr-x 1 root root 152 Jan 17 06:29 __rollback/ lrwxrwxrwx 1 root root 19 Feb 26 20:34 __snapshot -> __active/.snapshots/ Then I rebooted the system and tried a rollback at boot. mkinitcpio-btrfs failed to find any snapshots to rollback to. Then I tried modifying the line in /etc/defaults/btrfs_advanced like so: BTRFS_DIR_SNAPSHOT="/__active/.snapshots" rebuild initrd with "mkinitcpio -p linux" command and rebooted. This time I was able to successfully roll back to one of the automatically created snapshots made by the snapper utility. While this works it seems a bit kludgy to me. I would prefer to have the snapper utility store the scheduled snapshots in /__snapshot instead of /__active/.snapshots. I examined the documentation and code for the snapper utility at http://snapper.io and https://github.com/openSUSE/snapper respectively, and could not find any facility for changing the default location of the snapshots. I'll open a github issue to see if the author would be willing to add this capability.

xtfxme commented on 2014-02-20 18:51 (UTC)

@sysfu, the snapper wiki seems to suggest the snapshot dir is in the __active root... you could probably make it work by mounting the real btrfs root somewhere and using a symlink

visit commented on 2014-02-20 18:06 (UTC)

sysfu, yes it should be as easy as that, if .snapshot/ is in the "real" btrfs root. Give it a try and report back. Thx.

sysfu commented on 2014-02-20 07:54 (UTC)

Has anyone attempted to integrate the use of the btrfs Snapper utility with mkinitcpio-btrfs? https://wiki.archlinux.org/index.php/Snapper I recently installed and configured Snapper on my system to make regularly scheduled snapshots. I would like to be able to rollback to these at boot using mkinitcpio-btrfs. Snapper keeps the snapshots in the directory /.snapshots by default. Would it be as simple as editing the /etc/defaults/btrfs_advanced file and changing the line BTRFS_DIR_SNAPSHOT="/__snapshot" to read BTRFS_DIR_SNAPSHOT="/.snapshots" ?

sysfu commented on 2013-11-08 07:09 (UTC)

@visit; installed v0.4.1-1 and uncommented the BTRFS_ROLLBACK_KERNEL=false line as instructed, then recreated initrd. Console is nice and clean during boot process now. Thanks for your work on this.

visit commented on 2013-11-06 11:08 (UTC)

@srf21c, the package is updated. You can now uncomment BTRFS_ROLLBACK_KERNEL=false in /etc/default/btrfs_advanced to disable kernel rollback. Don't forget to recreate your initrd with "mkinitcpio -p linux". Please try it and report any issues. Thanks! P.S.: On the other hand you can try to use BTRFS_KVER_CHECK=true instead. This will reduce the passphrase requests, but still requires the sync of your boot directory between USB-stick and root subvol.

visit commented on 2013-11-04 22:37 (UTC)

@kodiak, I didn't know about that too. I had the same understanding until I found that in my repro case. Regardless if mkinitcpio-btrfs handles it correct, the purpose of creating subvolumes for curtain FHS directories remains the same - you can handle quotas with it. But for me it makes no sens to neither have recursive snapshots nor dynamic mount of subvolumes from parent snapshots. Maybe its worth to describe this in the btrfs mailinglist and ask for further opinions.

kodiak commented on 2013-11-04 19:43 (UTC)

@visit well, I thought not doing snapshots on subvolumes is on purpose, since I do not need any snapshots there?! Maybe some info on the wiki would help newcomers.

visit commented on 2013-11-04 00:13 (UTC)

@kodiak: Found the issue. There are two of them. 1. You have subvolumes within your root subvolume (home, var, usr), but you did not snapshot them together with the root. Example: # mount -o subvolid=0 /dev/sda2 /mnt # ls -l /mnt/__rollback/usr total 0 Btrfs is not clever enough to mount your existing "sub-subvolumes" to the snapshot created, so you would need to snapshot them too. Like that: # btrfs su sn __active __snapshot/test # rm -r __snapshot/test/{home,var,usr} # btrfs su sn __active/home __snapshot/test/home # btrfs su sn __active/var __snapshot/test/var # btrfs su sn __active/usr __snapshot/test/usr 2. But still this will not work, since the hook is making an additional snapshot of your choosen boot subvolume to __rollback. Currently the hook doesn't recognize "sub-subvolumes" eighter and will NOT snapshot home, var, usr same as you did. So I opened a github bug for #2. https://github.com/xtfxme/mkinitcpio-btrfs/issues/6

kodiak commented on 2013-11-03 19:50 (UTC)

@visit: I appreciate your effort on this! that´s the notebook: http://pastebin.com/HQ4VfNcS

visit commented on 2013-11-02 17:18 (UTC)

@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.

sysfu commented on 2013-11-02 15:44 (UTC)

@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.

visit commented on 2013-11-02 14:34 (UTC)

@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.

visit commented on 2013-11-02 13:55 (UTC)

@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.

visit commented on 2013-11-02 13:47 (UTC)

@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.

sysfu commented on 2013-11-02 04:18 (UTC)

@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.

blip commented on 2013-11-01 13:19 (UTC)

@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?

xtfxme commented on 2013-10-31 16:55 (UTC)

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?

visit commented on 2013-10-29 20:10 (UTC)

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

visit commented on 2013-10-29 20:08 (UTC)

@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.

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.

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.

kodiak commented on 2013-10-16 09:27 (UTC)

solved :)

kodiak commented on 2013-10-16 08:05 (UTC)

I have a grub2/btrfs related issue and cannot boot, might be connected to mkinitcpio-btrfs. Can somebody please have a look? https://bbs.archlinux.org/viewtopic.php?pid=1338015#p1338015

xtfxme commented on 2013-10-07 16:33 (UTC)

big thanks to Michael Göhler [visit1985] for all the updates! also upped pkgrel=1 per @Jristz comment.

hdevalence commented on 2013-10-06 21:36 (UTC)

My understanding is: btrfsctl is deprecated, and all of its functionality is included in the btrfs command. Since the hook adds the btrfs binary, it's not necessary to add the btrfsctl binary. Therefore, the issue can be fixed by removing the line add_binary btrfsctl from /usr/lib/initcpio/install/btrfs_advanced It would be good to update the package.

darkstar999 commented on 2013-10-06 15:36 (UTC)

Hey is there any where a Patch. This version of mkinitcpio-btrfs is not compatible with btrfs-progs-0.20rc1.3-1. There is an ERROR btrfsctl not found. Can any body say me how i can fix it ? And also btrfsctl ** ** WARNING: this program is considered deprecated ** Please consider to switch to the btrfs utility **

xtfxme commented on 2013-09-05 17:58 (UTC)

@Jristz, yes i know there are a couple issues... i will make said changes after merging other updates here: https://github.com/xtfxme/mkinitcpio-btrfs/pulls

commented on 2013-09-04 19:55 (UTC)

pkgrel never to be 0, PKGBUILDs whitout a package function are unsupported in pacman 4.1, and can't build in pacman 4.2

Johnny_Net commented on 2013-02-15 06:40 (UTC)

Thank you for taking the time to explain this to me.

xtfxme commented on 2013-02-04 17:04 (UTC)

@Johnny_Net, if you DO use the hook, you won't need anything in fstab/grub.cfg (ignored anyway)... however, it doesn't really hurt anything AFAIK, it's just misleading because we are not always booted into __active (sometimes we are in __rollback, etc) if you DON'T use the hook, you'll need to set subvol= in both configs (or in grub.cfg at the minimum) else the default subvol is mounted, which by default is subvolid=0 -- the "btrfs-root", for lack of a better name -- unless you've changed it. that said, the hook needs an minor update to be compatible with grub2, but as my $DAYJOB is tax-related API work, i've been overwhelmed for quite awhile now and have yet make the required changes (see last few comments). NOTE: this hook is specifically for rollback support... the kernel can easily boot a single drive by itself (and with the right opts, *any* btrfs array).

Johnny_Net commented on 2013-02-02 10:07 (UTC)

I followed the guide in the wiki for setting up Arch on a btrfs-root. So my / is on the subvolume __active and that is also how it is set up in grub.cfg and fstab. Now gathering from the comments, I understand that this is not recommended? So should I strip the subvolume-option from fstab and/or grub.cfg? Also, am I right that this hook is only required for easy rollback support? So if I didn't need the rollback support, could I just stick with the ordinary btrfs hook? If that is the case... Does the ordinary btrfs hook require the subvolume flag to be present in grub.cfg and fstab or should they be removed still? Mind, I still want / to be on the subvolume __active. Thanks a bunch.

xtfxme commented on 2012-12-05 16:06 (UTC)

ah that makes sense, its probably pulling from the active mounts. i'll take a look tonight, thanks

buergi commented on 2012-12-05 10:09 (UTC)

Ah and I'd definitely recommend to either strip subvol= from the rootflags or prevent btrfs_advanced from appending another subvol option and thus disabling it's rollback feature with a warning message. As I wrote below specifying multiple of them causes the mount to fail and drops you to emergency console which is not what non-nerds want :)

buergi commented on 2012-12-05 10:04 (UTC)

It is all to get it working for me. I didn't change any of the default options, maybe some problems occur with other settings. Hm thanks for the advice, I did indeed add subvol=__active to /etc/fstab however it works even with this option for me. However grub-mkconfig adds the option independently from this: grub-mkconfig is a shell script, check it out, it uses among others /etc/grub.d/10_linux to generate the grub configuration. The latter executs 'grub-mkrelpath /' to get the subvolume and adds it to the kernel cmdline. (c.f. /etc/grub.d/10_linux and /usr/share/grub/grub-mkconfig_lib)

xtfxme commented on 2012-12-05 08:47 (UTC)

@buergi, nice, thanks :) i knew people were having some issue with GRUB2 but i havent been able to remedy (my $DAYJOB devel work is related to tax processing, needless to say, it's... busy); is this all you needed to add to get GRUB2 working? ...and how is the subvol option being added? NOTE: you should *not* be defining a subvol in your fstab (if that's where it gets it from) because it's impossible to change the rootfs subvol after initial mount (can only be done in initramfs), and it won't be accurate anyway (eg. when booting __rollback). i will fix these up ASAP, little late tonight, but tomorrow... esp. if you can confirm those things for me. thanks!

buergi commented on 2012-12-05 08:30 (UTC)

There are two little bugs in the hook which cause it not to work at all for me. The problems occur when using grub2's grub-mkconfig. As long as GRUB_DISABLE_LINUX_UUID is not set to 'true' in /etc/default/grub grub-mkconfig uses root=UUID=... and not /dev/sdXY. Therefore, one has to pass the lookup option to blkid. Furthermore, grub2 adds 'subvol=__active' to rootflags and btrfs_hook does so again. mount.btrfs however refuses to work with multiple subvol options so you are dropped to emergency console. The following patch adds the lookup option and strips all subvol=... options from rootflags. 109a110,111 > # strip all other subvol options from rootflags > rootflags="$(echo $rootflags | sed 's/subvol=[^,]*,\?//g;s/,$//g')" 227c229 < [ "$(blkid -s TYPE -o value ${root})" = btrfs ] || return 0 --- > [ "$(blkid -s TYPE -o value -lt ${root})" = btrfs ] || return 0 Hopefully this problems will be fixed soon, except from this problems this is a great and very useful hook. Thanks a lot xtfxme.

kodiak commented on 2012-10-10 07:11 (UTC)

I am not seeing any rollback option during boot. Can have somebody plz have a look https://bbs.archlinux.org/viewtopic.php?pid=1173396#p1173396

xtfxme commented on 2012-09-18 04:43 (UTC)

@Vitok ... hmm, i'm not %100 sure what's wrong there, but it's likely related to the stuff @WorMzy was talking about (few comments back). i intend on reworking this hook very soon to take advantage of all the developments since its inception; i will ensure that multidevice stuff works properly.

commented on 2012-09-03 18:08 (UTC)

My too can't boot a multi-device (raid0) using grub2. But I can't boot at all with this hook, not when root=UUID..., /dev/disk/by-uuid/..., or /dev/sda2. With original btrfs hook I can booting without rootflags=device=/dev/sd[ab]2 Without any btrfs related hook can boot with rootflags=device=/dev/sd[ab]2 With btrfs_advanced hook can't boot at all, always the same ends http://pastie.org/private/xq9dz6djc2tmgcmkmsw8a

xtfxme commented on 2012-07-15 17:55 (UTC)

@jim945, this hook -- from day one circa late 2009 -- was never needed to boot btrfs.

jim945 commented on 2012-07-15 10:44 (UTC)

This hook is no longer required for boot from / to btrfs

xtfxme commented on 2012-07-04 02:02 (UTC)

@WorMzy, aha! :-) your diagnosis/resolutions are spot on, and IMO, resolving the root so late is a bug. i've raised a report against mkinitcpio [1]. thanks for your work/time -- much appreciated. [1] https://bugs.archlinux.org/task/30526

WorMzy commented on 2012-06-26 23:04 (UTC)

Whoops, that should've been "run_latehook", but no matter, I didn't read the other part between the running of HOOKS and the running of LATEHOOKS, namely the part where it tries to mount root. It looks like we've got ourselves a catch 22. On the one hand, you can run the script as a normal hook, which means you pre-empt the resolving of $root. Or you can run the script as a latehook, and completely miss the mounting of root. I dunno if you want to a) report this as a bug.* b) hack a fix (like the one I suggested**). c) rewrite the hook to take this into consideration. Or d) just tell people to use full paths (i.e., no "UUID=", "LABEL=", etc.) in their grub2 configs.*** *I don't see why resolving $root can't be done before hooks are run, unless that would break other hooks.. **still untested, and I need to sleep now. Will try it first thing in the morning if I have time. ***stick it on the wiki and echo it when they install the package. Hope I've helped shed some light on this for you

WorMzy commented on 2012-06-26 22:34 (UTC)

I did, but I think that combination of echoes and conditionals was confusing at best, and I honestly don't know what the results indicated. However, I reverted back to UUID=**** in grub's config, and put a single, simple echo at the top of run_hook: btrfs_fatal "root=${root} fstype=$(blkid -s TYPE -o value ${root})" Booting failed. This is the output: btrfs(FATAL): root=UUID=29034ff6-d2bf-469e-8c0e-82b701ee87d9 fstype= It appears that, while mkinitcpio /does/ resolve the device, it does so /after/ the "EARLYHOOKS" and "HOOKS" have run. I'll try changing run_hook to runlate_hook, and report back.

xtfxme commented on 2012-06-25 14:27 (UTC)

hrrrm, possibly. i usually write out /dev/disk/by-uuid/UUID ... IIRC mkinitcpio (in the past anyway) automatically found the root and re-exported it, so that value was good, but maybe this changed with the recent 0.9 release ... though it doesn't look like it: http://projects.archlinux.org/mkinitcpio.git/tree/init#n44 ... didn't you put some `echo`s in there to see (i thought i read that ...). meh, either way, i'll build a RAID1 + grub2 system via loopback + KVM and take a look.

WorMzy commented on 2012-06-25 11:48 (UTC)

I think the original problem is caused by grub2 using "root=UUID=****" syntax by default. Because of that, "blkid -s TYPE -o value ${root}" always equals "", causing the hook to silently exit. Dunno if the initrd shell (ash?) supports this, but you could put a conditional at the top of the hook like this: [ $root[1,5] = UUID= ] && root="/dev/disk/by-uuid/$root[6,$]" I'll try it out when I get chance.

xtfxme commented on 2012-06-25 06:31 (UTC)

@WorMzy, heh ... hooray! no worries; that's great news because i had zero idea what was causing issue ... tho i am admittedly still curious. alas, i suppose we may never know ...

WorMzy commented on 2012-06-24 14:22 (UTC)

Never mind. I can now boot with the vanilla btrfs_advanced hook, so the problem must have been with my grub config. Sorry for the noise.

xtfxme commented on 2012-06-24 09:40 (UTC)

@WorMzy, it's not clear to me if you system is booting properly and you just can't see the rollback menu, or you cannot boot at all -- does the system boot when using the "btrfs" hook (official) and adding `subvol=__active` to your rootflags? you are you adding `device=/dev/sda1,device=/dev/sdb1` to your rootflags, yes? or ... ? that explicitly tells the btrfs module which devices to scan, but a `btrfs device scan` (as done by the hook) should already take care of that ... hrm, can you try using the (single/primary) UUID instead of the sdX names (should really be doing this for any FS)? you can get the primary UUID with: blkid -p -s UUID -o value /dev/sda1 ... try that without device=XXX (in rootflags), and only if it doesn't work, try *with* device=XXX. should you have good results i'll update the hook to explicitly append the device=/dev/.../UUID, and if all else fails, i suppose i'll enumerate the devices and append them instead.

WorMzy commented on 2012-06-21 20:25 (UTC)

No change in behaviour if: - I install core/btrfs-progs. - I move the btrfs_advanced hook to the start (well, after base) of the HOOKS array. - I remove all modules from the MODULES array (just in case). - I use an older kernel (3.3.8-1). Regenerating the initramfs at every step.

WorMzy commented on 2012-06-21 20:07 (UTC)

Cheers for the reply, and no worries about the delay. The hook is definitely enabled in mkinitcpio.conf, and isn't disabled in the kernel commandline. btrfs-progs-git* is installed, and lsinitcpio lists "./hooks/btrfs_advanced, ./usr/bin/btrfsck, ./usr/bin/btrfsctl, ./usr/bin/btrfs, and ./usr/lib/modules/3.4.3-1-ARCH/kernel/btrfs.ko. I had to add "device=/dev/sda1,device=/dev/sdb1" to the kernel commandline to get the RAID1 btrfs install to boot properly. Otherwise the initrd couldn't mount / due to an "incorrect filesystem/missing codepage"-type error. My /boot is on /, (as a directory, rather than a subvolume, so that syslinux and grub can still see it), but I never had a problem while I was using syslimux on non-RAID. *I will try with regular core/btrfs-progs, maybe the git package is incompatible for some reason

xtfxme commented on 2012-06-19 15:40 (UTC)

@WorMzy, sorry for delay ... forgot to flag email as `needs attention`. are you sure the hook is listed in your mkinitcpio.conf, and not being skipped by disablehooks=[...] on your kernel cmdline? i don't think there is an issue with RAID-for-root (not /boot of course, for now). also, make sure you have the necessary tools installed (btrfs-progs) prior to running mkinitcpio. to be clear: you are still booting properly, yes? and this behavior started immediately after switching to grub2, correct? what is the output of `lsinitcpio /boot/initramfs-linux.img | grep btrfs`?

WorMzy commented on 2012-06-17 00:44 (UTC)

When booting a single device btrfs system via syslinux, I got a "PRESS ANY KEY TO ACCESS BTRFS FEATURES" type message. However, I am now booting a multi-device system (raid1) via grub2, and don't see this prompt any more. Is this a problem with my grub2 config, or does the hook not support snapshot features on multi-device btrfs filesystems? If not, is this something that is planned/possible? Cheers

xtfxme commented on 2012-06-03 17:19 (UTC)

@skydrome, try with the latest package ... maybe that was due to the changes in mkinitcpio (working fine here ;-)

xtfxme commented on 2012-06-03 17:12 (UTC)

@falconindy, thanks ... i pretty much used your link verbatim, seems to work alright :-) package now depends on mkinitcpio>=0.9.0

skydrome commented on 2012-06-02 22:39 (UTC)

for some reason the btrfs_advanced hook is getting run twice now

falconindy commented on 2012-05-26 23:48 (UTC)

Shouldn't be difficult -- you can basically include the same exact hook as from core/btrfs-progs: http://paste.xinu.at/OTWRI/ Yes, that adds all the correct modules -- there's a hardcoded quirk to pull in crc32c{,_intel} when adding libcrc32c.

xtfxme commented on 2012-05-24 16:30 (UTC)

@falconindy, ah yes i saw some chatter RE: the mkinitcpio release, but i've been a bit too swamped lately and skimmed over the conversation ... thanks for the note; i'll take a look at the required changes and update tonight (or tomorrow).

falconindy commented on 2012-05-24 13:45 (UTC)

Hi, please update your install hook for the changes in mkinitcpio 0.9.0. If you need examples, you can reference any of the install hooks included with mkinitcpio. There's also documentation included in the manpage now describing the recommended API. Feel free to email me if you have any questions. Thanks!

yetAnotherZero commented on 2012-05-08 15:47 (UTC)

Perfect. Thanks for the clarification.

xtfxme commented on 2012-05-08 07:01 (UTC)

@anotherZero, no breakage, and should not need to worry about that. i try to make it very clear in the post_install what is happening/coming ... ideally, i should updated it every time i suppose ... some of my more radical ideas, should they ever even materialize, will very likely be in a new package; this one is meant to provide a mostly barebones solution for accessing snapshots during early boot.

yetAnotherZero commented on 2012-05-07 16:20 (UTC)

@xtfxme we aren't looking at any breakage going forward are we? Any changes to the subvol detection etc, will be backwards compatible so I will always have a bootable system without changing my grub.cfg etc? Just wanted to verify before upgrading, and wanted to make sure so I know if I need to read up before any future upgrades. Thanks.

commented on 2012-05-05 18:12 (UTC)

On my boxes I use this hook but besides that I wrote two scripts that make my life a bit easier. One lists snapshots, I use that in one filesystem with NFS roots for multiple systems. The other script creates a snapshot of __active in __snapshot/<date> and also creates snapshots of subvolumes in __active. Both scripts make use of zsh because zsh makes shell scripting fun again. They're not intended as a turn-key solution that works for everyone but probably easy to customise. Sharing is fun so find them here: https://github.com/slacks42/slackscripts/tree/master/btrfs-stuff

xtfxme commented on 2012-05-05 03:13 (UTC)

@eworm, updated; thanks for the ping. also added btrfsck to the list of added binaries (did not try to ensure it's called) @nrujac, did you try the hook? what happened? i feel like it should work regardless -- the hook simply mounts the default subvolume (.) and snapshots that. it may however fail because it will try to mount the subvols by name (/__active) and if thats really in a subvolume (subvol/__active) then it would fail ... however, support for /mounting/by/path was only added very recently ... prior to that, you could only /mount_by_names if in the top-level volume. if you want to try it anyways, simply mount subvolid=0 and snapshot your current system to /__active, reboot, and go from there. your old system will remain intact until you decide to remove it or return to it :-) you could also play around with setting kernel variables to change how the hook works; all variables in the hook are initialized like this: : ${BTRFS_DIR_ACTIVE:="/__active"} ... which means "set BTRFS_DIR_ACTIVE to /__active, unless it's already set to something". initcpio will export any variables found on the command line ... so you could do something like this in grub2/syslinux: /vmlinuz initrd=/image.img BTRFS_DIR_ACTIVE=/mysubvol/__active ... and that should work. i'll explore some other options too.

xtfxme commented on 2012-05-02 14:19 (UTC)

@nrujac, what "old hook" are you referring? i can look into detecting the currently mounted subvol. @eworm, sure i'll take care of that tonight or tomorrow (in the middle of a move).

eworm commented on 2012-05-02 09:30 (UTC)

Can you install files to /usr/lib/initcpio/, please? mkinitcpio directories moved to /usr/.

nrujac commented on 2012-05-02 01:15 (UTC)

This package assumes that the root partition is not its own subvolume and instead is at the top of the filesystem. Here's my setup: /filesystem-root ... root ... home ... boot The old btrfs hook handled this correctly, but that one no longer exists. I was also hoping to try out the rollback features, but I guess it's a no go.

xtfxme commented on 2012-04-13 04:13 (UTC)

unfortunately not :-(, unless it were modified some. you may be interested in this tool: http://lizards.opensuse.org/2011/04/01/introducing-snapper/ ... it can probably be made to run on Arch, and there has been activity surrounding it on the list recently. i'm sort of waiting to see what tools come out before updating this -- i'd like to replace the heavy-lifting with some upstream tool.

commented on 2012-04-11 20:38 (UTC)

noob question: I understand how to use this to back up / (I think at least...). I have /home as a separate btrfs partition, can I use this to back that up too?

commented on 2012-03-07 09:37 (UTC)

Oh, you described the snapshot process below. # mount -o subvolid=0 <btrfs_device> /mnt # mkdir /mnt/__snapshot # btrfs sub snap /mnt/__active /mnt/__snapshot/my_savepoint-$(date +%F-%s)

commented on 2012-03-07 09:28 (UTC)

Any update on this? Also, can you tell me how to make a snapshot from a running root? can that even be done in this setup?

xtfxme commented on 2012-02-20 22:37 (UTC)

no, you don't have to change anything in fstab -- since this happens in initramfs the fstab won't be read anyway, and the subvol can't be changed on remount (AFAIK, for obvious reasons). if the fstab were included into the initramfs, i suppose it could identify the active subvol, but it doesn't work that way right now. in fact, rollback mode spawns/boots temp subvol on the fly; it's probably not a bad idea to keep everything in sync though (personally i use native systemd files and do not have fstab). there is some work being (already?) done in mkinitcpio to support fsck on the root device before mount, in conjunction with cleanup on shutdown. right now the hook is fairly basic and only implements a rudimentary rollback interface, without much (any?) configuration. btrfs does have an fsck utility, but it can't do much beyond spewing errors. i've been meaning to return to this hook for some time ... alas, life is beating this guy down. i'll try to allot some time soon for a review/update.

commented on 2012-02-20 13:20 (UTC)

Very nice hook, thanks. I have two questions: First is - should I change anything in fstab? Secondly - can you enable fsck support in any way (when the last character of the fstab entry is not 0)?

xtfxme commented on 2012-02-08 03:13 (UTC)

yup yup! updated, thanks

eworm commented on 2012-02-07 11:52 (UTC)

>>> Run mkinitcpio to update your initramfs image # mkinitcpio -p kernel26 'kernel26' has been renamed to 'linux' some time ago.

xtfxme commented on 2012-02-07 07:25 (UTC)

ah yes, right you are -- bumped -- thanks!

lowph commented on 2012-02-06 20:59 (UTC)

The core package btrfs-progs-unstable is renamed to btrfs-progs.

xtfxme commented on 2011-07-12 04:02 (UTC)

bump for install() -> build() in mkinitcpio 0.7+

xtfxme commented on 2011-06-20 20:22 (UTC)

bump for dep changes only ... hopefully ill get a chance to revisit this soon. i have a fair amount of work done already -- just needs to be pulled in.

xtfxme commented on 2011-06-15 19:59 (UTC)

ah yup :-) ill try to fix this up tonight, but possibly tomorrow as ill be out of town most of night -- this hook needs some love ... itching to hack on it ...

smfsh commented on 2011-06-15 16:42 (UTC)

btrfs-progs has become orphaned in favor of the official btrfs-progs-unstable package in the repo. Would there be any fault in changing the dependency here?

commented on 2011-01-28 09:12 (UTC)

lol a time capsule like ? :D

xtfxme commented on 2011-01-28 09:06 (UTC)

:-) i think everyone will be _pleased_ with the new system ... though it's radically different than this hook. in fact, this hook will be frozen and a new one created with a slightly different name, but ... no details yet! muah bwa ha ha! <eeeevil grin> (think git ... for your whole system ... hmmm ...) i thought it would be done almost 2mo ago but unfortunately my life likes to blow up now and again, and a 20mo baby/toddler needs much time. i also had an epiphany and started over recently; long/unrelated story short -- this is the very next thing on my project list, and im very determined to make it happen. soooo within the next couple weeks i'm *pretty* sure she'll arrive. don't quote me on that :-), but i feel confident. C Anthony

fuxter commented on 2011-01-25 10:07 (UTC)

[quote]_kernel_ rollbacks, multi drive roots[/quote] mmm... delicious. can't wait =)

commented on 2010-12-04 16:46 (UTC)

Wow, you are doing really a great job ! love btrfs more and more !

xtfxme commented on 2010-12-03 21:36 (UTC)

no, it will not be lost; even your snapshot is safe. it looks like this: ) choose <snapshot> from /__snapshot/ ) snapshot <snapshot> to /__rollback ) boot /__rollback currently, you have to manually mount the root subvol (subvolid=0) then: # mount -o subvolid=0 <btrfs_dev> /mnt # cd /mnt # mv __active __active.old # mv __rollback __active on the next boot your machine would now be in the new root. however, i am finishing a _major_ update this weekend that will be able to provide _kernel_ rollbacks, multi drive roots, and automatically enumerate snapshots for syslinux. so sit tight, and stay tuned :-) C Anthony

commented on 2010-12-02 11:39 (UTC)

what happens when i select a snapshot (!=__active) on boot ? can i switch back to __active or will it be lost ? (overwrited by new snapshot choosed?) thanks !

commented on 2010-10-28 20:10 (UTC)

great, all done thanks ! GREAT work and GREAT FS :) Hope later this year, fsck.btrfs come :)

xtfxme commented on 2010-10-27 16:24 (UTC)

yeah. make sure you are really booting into __active... ie. when your system is running normally, you should NOT see /__active unfortunately the only way to remove the erroneous directories is with rm -rf... this is something i have brought up to the btrfs guys many times to no avail. if you have /boot on a different partition, you can remove everything except __active and __snapshot; if your using a btrfs /boot (via extlinux) you must leave /boot intact, but can remove everything else. C Anthony

commented on 2010-10-27 09:22 (UTC)

if i mount the subvolid=0, can i delete all 'old' root files that exists before i applied yout hook ? (since now i have __active, i doesn't need anymore old files right ?) so mount -o subvolid=0 /dev/sda6 /mnt run rm on every directory except __active & __snapshot is that ok ? thanks !

xtfxme commented on 2010-10-27 05:16 (UTC)

# mount -o subvolid=0 <btrfs_device> /mnt # mkdir /mnt/__snapshot # btrfs sub snap /mnt/__active /mnt/__snapshot/my_savepoint-$(date +%F-%s) that should get you going :-) whe you reboot, enter the rollback menu, and you will see: 1) my_savepoint-2010-10-27-1288156742 or something similar. C Anthony

commented on 2010-10-26 16:20 (UTC)

how is supposed to work this hook ? i have see it have created a snapshot __active and i think it use that as / , but how to create other snapshot that can be chosen during boot ? I need a more specific details on how it work and do on my system, since i'm also a btrfs newbe ;-) thanks !

xtfxme commented on 2010-07-14 23:29 (UTC)

updated the .install file renamed hook to "btrfs_advanced" as suggested due to the inclusion of a basic btrfs hook in mkinitcpio

brain0 commented on 2010-07-11 09:52 (UTC)

You should rename your hook to btrfs_advanced or something like that, because mkinitcpio now includes a very simple hook called btrfs, which would then conflict.

xtfxme commented on 2010-06-14 20:44 (UTC)

minor update: addresses possible "lock" (requiring input although no input modules loaded) lots of updates to .install file

xtfxme commented on 2010-06-10 05:56 (UTC)

BIG UPDATE :-) install, and reboot. read the information given. more explanation to come, it's very late, again... - non-volatile rollback is now supported! hooray! - removed rollback_snapshot (a newer app is pending based off vps-lxc-git bash template)

xtfxme commented on 2010-04-29 06:58 (UTC)

- further cleaned up the code (prep for auto repair support) - added default as a boot option (boot the default subvolume in rollback mode) - changed sort order of snapshot list (0 always default, 1 always most recent) - use default mount handler for actual mount - revert dep back to btrfs-progs (git version needed for anything fancy ATM) - added .install file for new users IMPORTANT: BTRFS-PROGS-GIT NEEDED FOR ROLLBACK however, btrfs-progs will still work for basic booting

xtfxme commented on 2010-04-28 07:37 (UTC)

UPDATE -complete rewrite with newer btrfs tools. REQUIRES GIT PROGS UNTIL FURTHER NOTICE -added rollback support -added snapshot utility for use with rollback support more info to come... its very late here :(