You are not logged in.
Didn't find the way to install ArchLinux on Btrfs in the wiki and tried to write an adequate one - https://wiki.archlinux.org/index.php/In … Btrfs_root
Offline
a brief note -- earlier in the thread (i think it was this one...), there was some discussion about upcoming compression options where i had recommended waiting for LZMA2 i think. as someone noted, zlib is much faster than lzma2. this was a memory error on my part; i meant to say LZO compression, which is now in it's final forms for inclusion:
kernel: http://marc.info/?l=linux-btrfs&m=129004667418475&w=2
btrfs-progs: http://marc.info/?l=linux-btrfs&m=129005210822443&w=2
if someone feels bold, the patches have good feedback -- FS will be unreadable/unmountable on kernels without LZO support.
Didn't find the way to install ArchLinux on Btrfs in the wiki and tried to write an adequate one - https://wiki.archlinux.org/index.php/In … Btrfs_root
that's been needed for some time -- clean and concise, nice work.
i haven't tested your procedure, but here are a couple possible additions/suggestions:
) archboot is very good at doing all of this for you; might be worth a mention (i used it for this laptop :-)
) this hook [mkinitcpio-btrfs] needs a subvol called "__active", not "archlinux"
) maybe instead of creating a subvol, use a snapshot (same effect):
# btrfs subvolume snapshot /mnt/target/ /mnt/target/__active
then users won't have to do the chown step.
) users are instructed to download this hook, but the hook's name is "btrfs_advanced", not "btrfs" (btrfs is the built in default hook)
) use the word "initramfs", not "initrd"
) one thing to note, hooks are not needed unless user:
- needs to boot (as /) or mount a multi-disk array, eg. RAID (btrfs or btrfs_advanced)
- wants rollback support (btrfs_advanced only)
the kernel itself can handle mounting a single disk, and passing:
rootflags=subvol=__active
will mount the __active subvol.
) adding "subvol=__active" to fstab options is not necessary; this MUST be handled at the initramfs/kernel level, and cannot be changed by a remount anyway... additionally, (when using this hook) you're not always inside that subvol anyway. "default,noatime" would be good.
) mention that "subvolid" mount option can be substituted anywhere "subvol" is used -- get the id by "btrfs subvolume list /mnt/target"
that's all i got! looks very good at to the point. if i get time i will do some of these updates but i'm rather swamped; i don't know wiki formatting either and am too much of a perfectionist to just wing it :-)
C Anthony
what am i but an extension of you?
Offline
that's all i got! looks very good at to the point. if i get time i will do some of these updates but i'm rather swamped; i don't know wiki formatting either and am too much of a perfectionist to just wing it
i went ahead and made the changes outlined above. i should probably create a wiki page dedicated to this hook.
C Anthony
what am i but an extension of you?
Offline
Hi,
I know this is an very old post, but I couldn't find anything new in this matter. Are there any updates regarding this hook?
I've started using it now, but I don't understand some things:
1) when are snapshots made (or do I have to make them manually, for e.g. using a cron job)?
2) is it possible to make snapshots when updating system using some pacman wrapper, e.g. yaourt (which I use) or just using pacman alone?
@extofme: is there any chance you'll write that wiki page regarding script usage?
It's pretty hard to get every up-to-date detail from posts above. It would be nice to have some place with only the relevant information.
Also could you explain the use of __rollback folder? Am I booting to it when something goes wrong (after choosing appropriate snapshot), and then I should copy its contents to __active and boot again?
Does the script notify me if something goes wrong with the filesystem or do I have to know it myself? (using btrfs-scrub or something?)
hope to get some answers,
cheers,
kajman
Offline
I know this is an very old post, but I couldn't find anything new in this matter. Are there any updates regarding this hook?
not really i'm afraid :-(
1) when are snapshots made (or do I have to make them manually, for e.g. using a cron job)?
they are currently not made automatically. its fairly trivial to create one though, the process is detailed at the AUR page.
2) is it possible to make snapshots when updating system using some pacman wrapper, e.g. yaourt (which I use) or just using pacman alone?
well, since you must do it manually ATM, that's 100% up to you. could be as basic (eg, a function/script wrapping pacman/yaourt, snapshotting on certain args) or as fancy (eg, inotify or similar monitoring the pacman dbs, and triggering snapshots) as you like.
@extofme: is there any chance you'll write that wiki page regarding script usage?
It's pretty hard to get every up-to-date detail from posts above. It would be nice to have some place with only the relevant information.
well there is a chance for anything, or so sayeth the quantum view of reality!
really though, that's a reasonable request; alas, up until just recently (1mo) i was unable to spare any time whatsoever, but things are very good now so i will do my best to crank something out ... no promises on a time frame.
Also could you explain the use of __rollback folder? Am I booting to it when something goes wrong (after choosing appropriate snapshot), and then I should copy its contents to __active and boot again?
i would start with some of the older comments in the AUR thread -- they explain all of this -- but in short, yes, you are booting __rollback when you "rollback" (!). __rollback is transient and will be destroyed *every time* you request a rollback. to "promote" rollback -> active, simply mount the btrfs root (subvolid=0), mv /__active /__active.orig, and snapshot __rollback to __active ... do not copy/destroy anything! just snapshot __rollback to __active and reboot.
Does the script notify me if something goes wrong with the filesystem or do I have to know it myself? (using btrfs-scrub or something?)
nope :-( the script is very basic TBH. i had some ideas to do this among other features, essentially creating a git-like structure with branches and all sorts of impressiveness, but alas, i got bored and never completed after ~3-4 partial implementations.
there hasn't been a whole lot of feedback on the hook, and i'm not sure what kind of features would be useful, so if you have some requests by all means let me know. i would also happily merge a small tool to manage snapshots. i don't actually use btrfs as much now as i did (unrelated to btrfs itself, it's a great FS, but i needed to back off the edge some) but i will soon and at that point will probably, and finally, update this beast.
in there year or two since any significant changes to this hook there have been many great additions to btrfs ... i have followed the list for several years and when the time is right i'll sink some time into updates. in the meantime, any dialog/suggestions/thoughts/propositions wrt features et al is very much welcome.
what am i but an extension of you?
Offline
Hi,
I'm a happy user of this hook and today I have upgraded to GRUB2 and successfully moved /boot into the __active subvolume. How do you suppose the hook should work with snapshotted kernels? I thought of the following sequence:
Auto-snapshot on boot (then we can safely replace __active below)
On rollback snapshot selected backup to __active and reboot if kernel has changed
On reboot the user should just ignore the hook prompt so the selected backup remains in __active
Offline
Hi,
I'm a happy user of this hook and today I have upgraded to GRUB2 and successfully moved /boot into the __active subvolume. How do you suppose the hook should work with snapshotted kernels? I thought of the following sequence:
Auto-snapshot on boot (then we can safely replace __active below)
On rollback snapshot selected backup to __active and reboot if kernel has changed
On reboot the user should just ignore the hook prompt so the selected backup remains in __active
i've planned an "autosnap" feature since the beginning, but it was intended to be an optional thing. as for the kernel reboots to tenetive plan was to move the snapshot selection logic out of the initramfs and into a grub2 script, which is the preferred way, but the other option is to kexec the new kernel right over the top of the old on while still in initramfs.
another option -- stemming from my attempts to circumvent the lack of bootloader support -- is to create a "bootramfs", a mini initramfs, with just enough to load btrfs, choose a snapshot, and kexec.
need to explore this soon.
what am i but an extension of you?
Offline
Ooh, I've never heard about kexec before. I might give it a try after the next kernel release.
Last edited by Kha (2012-08-16 15:21:32)
Offline