-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I created a snapshot of my root subvol, then used btrfs-subvolume set-default to make the snapshot the default subvol and rebooted. This seems to have correctly gotten the system to boot from the snapshot instead of the original subvol, but now /home ( @home subvol ) refuses to mount claiming that /dev/sda1 is not a valid block device. What gives? Also, is there no way to move or hard link subvolumes to somewhere other than their original location? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6kbjoACgkQJ4UciIs+XuJ9cgCgplNTWEmJjW+9fC87y9nO9yao xcQAoLzsOCVgxsm4a28wKudvyX+7OCpB =rL1g -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday, 23 October, 2011 15:42:50 you wrote:> there no way to move or hard link subvolumes to somewhere other > than their original location?You can use the ''mv'' command. [__active is the subvolume which I use as root] ghigo@venice:/tmp$ btrfs sub crea a Create subvolume ''./a'' ghigo@venice:/tmp$ btrfs sub crea c Create subvolume ''./c'' ghigo@venice:/tmp$ btrfs sub crea a/b Create subvolume ''a/b'' ghigo@venice:/tmp$ sudo btrfs sub list /var/btrfs/ ID 258 top level 5 path __active ID 259 top level 5 path __active/tmp/a ID 260 top level 5 path __active/tmp/c ID 261 top level 5 path __active/tmp/a/b ghigo@venice:/tmp$ mv a/b c ghigo@venice:/tmp$ sudo btrfs sub list /var/btrfs/ ID 258 top level 5 path __active ID 259 top level 5 path __active/tmp/a ID 260 top level 5 path __active/tmp/c ID 261 top level 5 path __active/tmp/c/b -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Phillip Susi <psusi <at> cfl.rr.com> writes:> I created a snapshot of my root subvol, then used btrfs-subvolume > set-default to make the snapshot the default subvol and rebooted. This > seems to have correctly gotten the system to boot from the snapshot > instead of the original subvol, but now /home ( @home subvol ) refuses > to mount claiming that /dev/sda1 is not a valid block device. What gives?Hello Phillip, It is hard to judge without seeing your fstab and bootloader config. Maybe your / was directly in subvolid=0 without creating a separate subvolume for it (like __active in Goffredo''s reply)? In my very humble opinion, if you have your @home subvolume under subvolid=0 and then change the default subvolume, it just cannot access your @home any more. Personally I do not store anything in subvolid=0 directly and never bothered with ''set-default'' option - just used a new subvolume/snapshot name - create a named snapshot - edit bootloader config to include the new rootflags=subvol=<your_new_snapshot_name> - reboot Here is a very good article that explains the working of subvolumes. I used it as reference a lot. http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29 ~dima -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 24, 2011 at 12:45 PM, dima <dolenin@parallels.com> wrote:> Phillip Susi <psusi <at> cfl.rr.com> writes: > >> I created a snapshot of my root subvol, then used btrfs-subvolume >> set-default to make the snapshot the default subvol and rebooted. This >> seems to have correctly gotten the system to boot from the snapshot >> instead of the original subvol, but now /home ( @home subvol ) refuses >> to mount claiming that /dev/sda1 is not a valid block device. What gives?Try mounting using sobvolid. Use "btrfs su li /" (or wherever it''s mounted) to list the ids.> Personally I do not store anything in subvolid=0 directly and never bothered > with ''set-default'' option - just used a new subvolume/snapshot name+1 A problem with that, though, if you decide to put /boot on btrfs as well. Grub uses the default subvolume to determine paths (for kernel, initrd, etc). A workaround is to manually create and manage your grub.cfg (or create and use a manual-managed include file, like custom-top.cfg, that gets parsed before the automatically created entries). I really like zfs grub2 support, where it will correctly use the dataset name for file locations. Unfortunately grub''s btrfs support doesn''t have it (yet).> - create a named snapshot > - edit bootloader config to include the new > rootflags=subvol=<your_new_snapshot_name>I had some problem with subvol option in old version of kernel/btrfs in Lucid/Natty. I use subvolid now, which seems to be more reliable. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fajar A. Nugraha <list <at> fajar.net> writes:> A problem with that, though, if you decide to put /boot on btrfs as > well. Grub uses the default subvolume to determine paths (for kernel, > initrd, etc). A workaround is to manually create and manage your > grub.cfg (or create and use a manual-managed include file, like > custom-top.cfg, that gets parsed before the automatically created > entries).Oops, sorry, I was incorrect of course. Thanks Fajar. I do have /boot in my subvolid=0 because bootloaders can''t read inside subvolumes (other than the default) as far as I understand. And I just bind /boot through fstab. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 24, 2011 at 3:24 PM, dima <dolenin@parallels.com> wrote:> Fajar A. Nugraha <list <at> fajar.net> writes: > >> A problem with that, though, if you decide to put /boot on btrfs as >> well. Grub uses the default subvolume to determine paths (for kernel, >> initrd, etc). A workaround is to manually create and manage your >> grub.cfg (or create and use a manual-managed include file, like >> custom-top.cfg, that gets parsed before the automatically created >> entries). > > Oops, sorry, I was incorrect of course. Thanks Fajar. > I do have /boot in my subvolid=0 because bootloaders can''t read inside > subvolumes (other than the default) as far as I understand. > And I just bind /boot through fstab.AFAIK you have three possible ways to use /boot on btrfs: (1) put /boot on subvolid=0, don''t change the default subvolume. That works, but all your snapshot/subvols will be visible under /boot. Some people might not want that for estetic reason. (2) put /boot (or /, when /boot is part of / ) on a subvolume, then change the default subvolume. This works cleanly, but there were some problems in the past when changing the default subvolume (at least I had problem). Current kernel version might not have this problem anymore (I haven''t tried again) (3) put /boot on a subvolume, do not change the default subvolume, and manage grub.cfg manually. This is what I currently do. I wish grub''s btrfs support is more like zfs support, where both the bootloader and tools (e.g. update-grub, grub-probe, etc) can intellegently recognize what dataset /boot is on, and create the correct entry. For example, if you have this # df -h /boot Filesystem Size Used Avail Use% Mounted on rpool/ROOT/ubuntu-1 384G 1.2G 383G 1% / rpool/ROOT/ubuntu-1/boot 383G 71M 383G 1% /boot ... then grub.cfg will have an entry like this zfs-bootfs ($root) bootfs linux /ROOT/ubuntu-1/boot/@/vmlinuz-2.6.38-10-generic root=/dev/sda5 ro boot=zfs $bootfs rpool=rpool bootfs=rpool/ROOT/ubuntu-1 initrd /ROOT/ubuntu-1/boot/@/initrd.img-2.6.38-10-generic This flexibility allows me (for example) to have multiple version of kernel, initrd, and root fs in different datasets, all selectable during boot process (possibly by manually editing grub command line to suplly the correct path/argument). Good for rescue purposes, just in case a recent update made the system broken :) The closest thing we can get to that with btrfs is currently option (1), as option (2) requires you to boot to an alternate environment (e.g live cd) to change the default subvol first. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2011 01:45 AM, dima wrote:> Hello Phillip, > It is hard to judge without seeing your fstab and bootloader config. Maybe your > / was directly in subvolid=0 without creating a separate subvolume for it (like > __active in Goffredo''s reply)? In my very humble opinion, if you have your @home > subvolume under subvolid=0 and then change the default subvolume, it just cannot > access your @home any more.Why can''t it? It appears that Ubuntu sets up two subvols, one named @ and one named @home, and mounts them at / and /home respectively. The boot loader was set to pass rootflags=subvol=@. After changing the default volume, the system would not boot until I removed that rootflags argument, then it mounted the snapshot correctly as the root, but refused to mount /home, giving this nonsense error that /dev/sda1 is not a valid block device.> Here is a very good article that explains the working of subvolumes. I used it > as reference a lot. > http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29This advice seems completely goofy. It tells you to change the default subvol and boot from the snapshot, but then to have rsync copy all of the files back to the default volume, then switch back to using that. This seems to defeat the entire purpose. If you are already booting from the snapshot, why would you want to waste time copying the files back to the original subvol instead of just deleting it, and using the snapshot volume from now on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6mBo4ACgkQJ4UciIs+XuK+wgCeOD0km3GpdseQ0h4y0FKSI7JS xC0An2JqA4aOHCkZ7+g+TORunVnpmQj7 =6KKf -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fajar A. Nugraha <list <at> fajar.net> writes:> AFAIK you have three possible ways to use /boot on btrfs: > > (1) put /boot on subvolid=0, don''t change the default subvolume. That > works, but all your snapshot/subvols will be visible under /boot. Some > people might not want that for estetic reason.Hi Fajar, I think I am doing just this, but my subvolumes are not visible under /boot. I have all my subvolumes set up like this: /path/to/subvolid_0/boot < a simple directory bind-mounted to / /path/to/subvolid_0/__active < my / subvolume /path/to/subvolid_0/__home < my /home subvolume> (3) put /boot on a subvolume, do not change the default subvolume, and > manage grub.cfg manually. This is what I currently do.Could you elaborate about this option pls., and if possible post your grub.cfg? I don''t quite understand how it works. Though I am doing syslinux at the moment, I think the process is the same. thanks ~dima -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25/10/11 02:45, Phillip Susi wrote: > (...)> > On 10/24/2011 01:45 AM, dima wrote: >> Hello Phillip, >> It is hard to judge without seeing your fstab and bootloader config. Maybe your >> / was directly in subvolid=0 without creating a separate subvolume for it (like >> __active in Goffredo''s reply)? In my very humble opinion, if you have your @home >> subvolume under subvolid=0 and then change the default subvolume, it just cannot >> access your @home any more. > > Why can''t it? > > It appears that Ubuntu sets up two subvols, one named @ and one named > @home, and mounts them at / and /home respectively. The boot loader was > set to pass rootflags=subvol=@. After changing the default volume, the > system would not boot until I removed that rootflags argument, then it > mounted the snapshot correctly as the root, but refused to mount /home, > giving this nonsense error that /dev/sda1 is not a valid block device.> > (...) Btrfs is unfortunately unable to look for snapshots by name above the currently set default root (I do not know why exectly), it can however find them by id anywhere. In the case of (Debian?) Ubuntu, you should pretty much stay away from set-default. What happens is Ubuntu mounts the _default_ subvolume, which in the normal case refers to the top of the btrfs tree (alias subvolid=5), then it looks below this for the subvolumes ("directories") named "@/" (given by the boot option) and "@home/" (given in fstab). Now, when you use set-default here, it will instead mount that subvolume as the default, and then look _below_ that for "@/" and "@home/", obviously, this won''t work, since these exist higher up in the tree. When you disable the rootflags argument, btrfs assumes the default subvolume is the root, which works, as noted. In order to find "@home/", you could rewrite the fstab to instead of "subvol=@home" read "subvolid=###", since by specifying id instead of name, it can find it anywhere in the tree, the subvolid can be found via ~# btrfs subvolume list / HOWEVER, this is not the way btrfs is intended to be used on Ubuntu. As mentioned earlier, you likely will not want to touch set-default, instead, when you want to muck around with your mounting sobvolumes, you just use mv: To backup ~# mount /dev/sda1 /mnt ~# ls /mnt @ @home ~@ btrfs sub snap /mnt/@ /mnt/@rootsnap ~# ls /mnt @ @home @rootsnap And to rollback: ~# mv /mnt/@ /mnt/@rootmessy ~# mv /mnt/@rootsnap /mnt/@ And just reboot, since it just mounts whatever is named "@/". Now in your case, if you want to go back to the Ubuntu default btrfs setup, you would: ~# btrfs subvolume set-default 5 / (since id 5 is always the top of the tree) And reinstate the rootflags boot option. Hope that explains some of it. -- Martin Werner ("arand") -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 25, 2011 at 9:00 AM, dima <dolenin@parallels.com> wrote:> Fajar A. Nugraha <list <at> fajar.net> writes: > >> AFAIK you have three possible ways to use /boot on btrfs: >> >> (1) put /boot on subvolid=0, don''t change the default subvolume. That >> works, but all your snapshot/subvols will be visible under /boot. Some >> people might not want that for estetic reason. > > Hi Fajar, > I think I am doing just this, but my subvolumes are not visible under /boot. I > have all my subvolumes set up like this: > /path/to/subvolid_0/boot < a simple directory bind-mounted to / > /path/to/subvolid_0/__active < my / subvolume > /path/to/subvolid_0/__home < my /home subvolumeActually with that setup you''re using option (3) that I described. That means all your subvolumes is still visible under /path/to/subvolid_0/, right? I''m not sure how well grub can manage this. Probably it can''t, so you''d have to manage boot entries manually.> > >> (3) put /boot on a subvolume, do not change the default subvolume, and >> manage grub.cfg manually. This is what I currently do. > > Could you elaborate about this option pls., and if possible post your grub.cfg? > I don''t quite understand how it works. Though I am doing syslinux at the moment, > I think the process is the same.For example, with the following subvolume sturcture (using default subvolid 0, unchanged) / /boot /root /home ... and fstab set to mount subvol "boot" on /boot. Then when grub looks for kernels and initrd it''d see that /boot is it''s own block device, so it''s use /vmlinuz and /initrd in grub.cfg. However, when grub actually boots, it''d see the files located an /boot/vmlinuz and /boot/initrd, and when reading the configuration it''d be unable to find the files (since from grub''s point of view there''s nothing on /vmlinuz and /initrd). Which is why I said you''d need to manage grub.cfg manually in this setup. For comparison purposes, I''d just setup two versions of Ubuntu with zfs / and /boot. In a way it''s kinda like having different linux distros/versions installed on different partitions with one master bootloader choosing which partition is active. Each distro/version can manage it''s own boot configuration file without disturbing each other (e.g. oneiric won''t be able to see natty''s kernel and initrd). Although the initial setup is done manually, each version''s grub will be able to manage it''s own kernels and initrd independently. The setup is something like this: # zfs list | grep boot rpool/ROOT/oneiric/boot 23.3M 369G 23.3M /rpool/ROOT/oneiric/boot rpool/ROOT/natty/boot 121M 369G 96.3M /rpool/ROOT/natty/boot rpool/boot 1.32M 369G 1.32M /rpool/boot rpool/boot is where the "master" configuration file for grub is installed. It''s job is to select which configfile (oneiric or natty) to use next, so it''s something like this #======================================# cat /rpool/boot/grub/grub.cfg insmod part_msdos insmod zfs search --no-floppy --fs-uuid --set=root c4f4006ef59df197 set timeout=1 menuentry ''Ubuntu Natty boot menu'' { configfile /ROOT/natty/boot/@/grub/grub.cfg } menuentry ''Ubuntu Oneiric boot menu'' { configfile /ROOT/oneiric/boot/@/grub/grub.cfg } #====================================== Each Ubuntu version has it''s own /boot directory, which will be mountted as /boot when it''s active, but remains unmounted (or mounted in alternate path) when it''s inactive. grub''s zfs support will use dataset name as part of path (regardless where it''s currently mounted), so the config for oneiric looks something like this #======================================menuentry ''Ubuntu, with Linux 3.0.0-12-generic'' --class ubuntu --class gnu-linux --class gnu --class os { search --no-floppy --fs-uuid --set=root c4f4006ef59df197 linux /ROOT/oneiric/boot/@/vmlinuz-3.0.0-12-generic root=/dev/sda5 ro boot=zfs boot=zfs rpool=rpool bootfs=rpool/ROOT/oneiric initrd /ROOT/oneiric/boot/@/initrd.img-3.0.0-12-generic } #====================================== Unfortunately this kind of setup is currently not possible with btrfs. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/25/2011 05:01 PM, Fajar A. Nugraha wrote: > On Tue, Oct 25, 2011 at 9:00 AM, dima<dolenin@parallels.com> wrote: >> Fajar A. Nugraha<list<at> fajar.net> writes: >> >>> AFAIK you have three possible ways to use /boot on btrfs: >>> >>> (1) put /boot on subvolid=0, don''t change the default subvolume. That >>> works, but all your snapshot/subvols will be visible under /boot. Some >>> people might not want that for estetic reason. >> >> Hi Fajar, >> I think I am doing just this, but my subvolumes are not visible under /boot. I >> have all my subvolumes set up like this: >> /path/to/subvolid_0/boot< a simple directory bind-mounted to / >> /path/to/subvolid_0/__active< my / subvolume >> /path/to/subvolid_0/__home< my /home subvolume > > Actually with that setup you''re using option (3) that I described. > > That means all your subvolumes is still visible under > /path/to/subvolid_0/, right? I''m not sure how well grub can manage > this. Probably it can''t, so you''d have to manage boot entries > manually. Yes, you are right. I can see all subvolumes under /path/to/subvolid_0 By the way grub2 can manage this setup correctly and generate the right menu entries without any problems. But - /boot is not in its own subvolume in this setup. I think this is the reason it works out of the box. Thank you for your explanations. I can see if I can make it work with /boot in its own subvolume. ~d -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 25, 2011 at 3:54 PM, dima <dolenin@parallels.com> wrote:>>> Hi Fajar, >>> I think I am doing just this, but my subvolumes are not visible under >>> /boot. I >>> have all my subvolumes set up like this: >>> /path/to/subvolid_0/boot< a simple directory bind-mounted to / >>> /path/to/subvolid_0/__active< my / subvolume >>> /path/to/subvolid_0/__home< my /home subvolume >> >> Actually with that setup you''re using option (3) that I described. >> >> That means all your subvolumes is still visible under >> /path/to/subvolid_0/, right? I''m not sure how well grub can manage >> this. Probably it can''t, so you''d have to manage boot entries >> manually. > > Yes, you are right. I can see all subvolumes under /path/to/subvolid_0 > By the way grub2 can manage this setup correctly and generate the right menu > entries without any problems. > > But - /boot is not in its own subvolume in this setup. I think this is the > reason it works out of the box. > > Thank you for your explanations. > I can see if I can make it work with /boot in its own subvolume.If you currently have it working, then as long as you have the full subvolid=0 mounted somewhere and use bind-mount from that, it shouldn''t matter whether it''s a subdir or a subvol. But if you mount the subvol directly in /boot, you''ll have the same problem I do. So it''s a trade off, I guess. You can have grub manage grub.cfg correctly, but you need to have the full tree mounted somewhere. Not ideal, but a possible option which I hadn''t thought of before. Thanks for sharing your setup. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2011 10:04 PM, Arand Nash wrote:> Btrfs is unfortunately unable to look for snapshots by name above the > currently set default root (I do not know why exectly), it can however > find them by id anywhere.Ok, so looking up subvols by name uses the default subvol to resolve the name, and so when I change the default subvol to the snapshot of @, there is no @home name there pointing to the subvol? Things make much more sense knowing that. I thought that the subvolumes had their own namespace outside of any one subvolume. Is there a way to create another name entry in @snap that points to @home, or can you only have the original @home entry in the default subvol?> To backup > ~# mount /dev/sda1 /mnt > ~# ls /mnt > @ @home > ~@ btrfs sub snap /mnt/@ /mnt/@rootsnap > ~# ls /mnt > @ @home @rootsnap > > And to rollback: > ~# mv /mnt/@ /mnt/@rootmessy > ~# mv /mnt/@rootsnap /mnt/@ > And just reboot, since it just mounts whatever is named "@/".Perfect... I think I''ll keep the default subvol mounted under /.subvols to make managing them easy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6nYtIACgkQJ4UciIs+XuJ/CQCgsbMLAY/h9opq/T7qBJKKrSz2 v0cAnRq8PKp1jx9r4Q6X4J6Ixjv3KpeS =GSCn -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html