[EN] [solved]Siduction Install on btrfs subvolume

[terroreek]

Hi All,


I tried to search the forums and google how to accomplish this, but I am trying to install Siduction onto a btrfs subvolume, but I am having some issues with the installer.  Now don't get me wrong but the installer is easy to use and I have successfully installed xfce4 and gnome on a virtual machine on to a btrfs partition.  You can do it on debian testing, by remounting /target and /target/home to your btrfs subvolume prior to installing. 


I am wondering if there is a way to nudge the installer to accomplish this, maybe edit the configuration file (not sure where it is located) for the installer to do this? 


Also I am thinking of switching my primary desktop to siduction, how many people use siduction for their primary desktop??

[timc]

I have Siduction installed on a btrfs root subvolume, but I think you are referring to installation on a subvolume at a lower level. Several months ago, I asked the same kind of question in the btrfs irc channel, and they said that most distros' grubs are not capable of doing that. They said that one is capable (I think it may have been Fedora), but not Debian.

What I had wanted to do was have a single very large btrfs RAID array (mine was 1.9 TB) and be able to install multiple distros on bootable subvolumes. I suspect that is what you want to do, too. This is theoretically possible, but not until the distros' bootloaders are capable of handling booting to the subvolumes.

If you just want to install Siduction to a partition on a root-level btrfs filesystem subvolume, I can help you with that. I have done it several times.

Tim

[terroreek]

Hi Tim,


Yes, I am but I believe that I think that there must be a mistake in the information you were provided.  So what I am trying to do is create a home and root partition.  I then format the partition as btrfs, upon completing that, I will create subvolumes ('root' for / and 'home' for /home) on each partition, and then install the the operating system and home to those subvolumes. 


Ubuntu has been doing this for some time 11.04 and later, where the installer actually automatically creates a @ subvolume under root, and @home for the users home partition, automatically without user intervention.


I was able to do this in debian testing, here is a guide that does something similar but encrypts the partitions as well, http://zythmer.acyclic.org/blog/2013/01/27/debian-full-disk-encryption-btrfs-subvolumes.html.  Where prior to installing debian, I created my btrfs partitions, unmounted /target, created my subvolume and then remounted /target to the 'root' subvolume I created under my root partition using the mount option/flag subvol=root


Arch also recommends for increased flexibility when you create your btrfs partition that you create a subvolume and mount that subvolume and install Arch into that subvolume.  https://wiki.archlinux.org/index.php/Btrfs#Installing_with_root_on_btrfs_subvolume


I am basically attempting to do the same, and have successfully installed siduction with btrfs in a virtual machine but the problem is it seems that siduction will install directly to the partition ex (/dev/sda1/).  My thought is that since Debian testing can pull this off siduction should be as well, the only issue is coaxing the installer to install to the btrfs subvolume vs that root partition.  My gut feel is that I can't use the debian installer to install siduction using the method above.   


Thanks Tim for getting back to me.  Based on the information I am looking at it seems you should be able to do what you were hoping to accomplish.


-Tareeq

[melmarker]

grub is capable to handle this for a very long time - i have systemd, btrfs in my office vm's since systemd 44

[timc]

Based on what you are telling me that you want to accomplish, I think you are overcomplicating things. I will tell you what I did, and maybe it will help.

1) In a partition editor, I created two partitions, one for root and another for home.

2) I ran mkfs.btrfs on the partition for home, only. The Siduction installer will mount it and use it.

3) Ran the Siduction installer and specified that it install onto the other partition, the one created for root. Then specified that it create it as a btrfs filesystem.

4) Still in the Siduction installer, selected the home partition with its pre-created btrfs filesystem for /home.

5) Completed the other setup steps for the installer and ran it. I selected the root partition to install grub onto.

This was successful. / and /home do not show up as subvolumes but, technically, they are. I can perform btrfs subvolume commands on them as if they were lower level subvolumes.

Tim

[terroreek]

Hi Tim,

Yes you are right the root partition is a subvolume, and yes you are right its a bit more complicated then a regular setup, however here is a real world example why installing siduction to a subvolume is preferential to then the root subvolume. 

Ok so if you install siduction to the root subvolume (When mkfs.btrfs creates the file system, as you said it creates a subvolume without a name but with a volume id of 0).  So before performing a dist-upgrade you take a snapshot of '/'.  So now you perform your dist-upgrade, and the upgrade breaks your system.  Now you want to roll back to your snapshot, so now you boot into your snapshot (either edit grub and fstab, or change the btrfs default subvolume id).  Once you are in your snapshot which works you then have to mount the root subvolume (id being 0) to say /mnt, and then you have to rsync your working snapshot back onto your root subvolume.  Once it's completed you should have fixed your system, you can then change the default volume id back to 0 or undo you grub and fstab changes and boot back into your restored system.  Then you can delete the snapshot you took.

Now in comparison, if you install siduction into a btrfs subvolume outside of the root subvolume, prior to performing a dist-upgrade take a snapshot of your subvolume (lets say we called it @root and the snapshot is @root_snapshot-01-12-2014).  Now run your dist-upgrade upgrade and the system is borked, easy fix, just mount the drive, and rename @root to @root_bad and @root_snapshot-01-12-2014 to @root, (assuming you are using the subvol= flags in grub and fstab).  Reboot and you have gone back to a working system and you can delete the @root_bad subvolume. 

The second scenario is much easier to recover from the first scenario, and is much quicker to recover from as well depending on the amount of data being rysnced.

The problem with say installing to the root subvolume, then creating a @root subvolume under it and mounting that as '/' is as you change any of the original files, that root subvolume will keep a copy of anything that changes from @root, which will slowly mean you will start eating up unnecessary disk space.

Hope that makes sense.  Shall I gather that what I am trying to do is not possible from the siduction installer?  I have tried looking at the wiki to maybe see if I can find where the sidu-installer saves installation configuration file and if there is a way for me to edit it, and see if I can coax it into doing what I am trying to do?

[timc]

@terroreek, I agree with everything you said. I wanted to install into lower level subvolumes, too, but like I said, I was told it could not be done in Debian so I did not pursue it further.

melmarker's post above in this thread seems to indicate that it can be done. But if so, I am not the one who knows how. If you solve this and are able to install and boot to lower level subvolumes, I would like to know your final methods of doing it.

Thanks,
Tim

[timc]

Here's another idea. If you know how to boot to a lower level subvolume and just cannot determine how to install to one, do an installation to the root level subvolume, then snapshot it to a lower level, then try to boot to that one.

Tim

[terroreek]

Yep, that was easy enough to do you just need to make sure in /boot/grub/grub.cfg for the kernel boot options you have rootflags=subvol=<snapshotname>.  The debian method is to edit /etc/defaults/grub or /etc/grub.d/ and then run update-grub.  Edit /etc/fstab and when you mount the btrfs volume just add subvol=<snapshotname> after the mount options.  Worked like a charm.  Now to verify I was in the snapshot it self after creating the snapshot I created an empty file to the '/' partition, that wasn't there prior.  If you do this I recommend making your changes prior to creating the snapshot, the reason is because if you create your snapshot, and then make the modifications, to the root subvolume, those changes do NOT carry over onto the snapshot you took. 


There is another problem with this setup, the way that the snapshots and subvolumes work.  Once I boot into the subvolume I have created over time, as you continue to add applications, remove applications and modify files.  The root subvolume continues to hold on to the original changes, so over time you slowly loose space.  To further elaborate imagine you installed gnome during the install but you decide to use xfce going forward and uninstall gnome, well on the snapshot subvolume you won't have but gnome will remain on the root subvolume ... actually ok thinking about, there is nothing stopping you from removing the contents of the root subvolume to avoid this let me test this out.

[terroreek]

OK I was able to to do it and you led me in the right direction Tim.  I was able to boot off the subvolume as well as empty and delete the contents of the root subvolume.   The tricky thing was fixing grub, the other annoying this is update-grub will automagically detect subvolumes the only crappy thing is the only way to boot into the subvolume and boot the kernel was to edit grub.cfg directly. 


I can post instructions if you wish me to.

[GoinEasy9]

If you don't mind, I think I'd like to see the instructions.  I haven't tried a btrfs install yet, but, I am interested in all fails and solutions. 
 
It would be nice for all others looking at the thread to see your solution also.

[terroreek]

*** I am not a btrfs expert nor do I take responsibility if you hose your system and your data, use this at your own risk ***

Ok so I will this is how I did it step by step, I will use a simple setup but there isn't anything stopping you from using a more complicated setup, ie btrfs raid.  Putting /home on a seperate partition

So begin the installer, I manually partition my drive with gparted.  Since I am using a gpt partitioned disk, I am going to create a 2MB unformatted partition and set the bios_grub flag on that partition, create a swap partition, then a 4GB partition for '/' and a 3GB 'home' partition. 

sda1 -> bios_grub (only needed for gpt disks)
sda2 -> swap
sda3 -> btrfs volume for '/'
sda4 -> btrfs volume for 'home'

I also set the sda3 has bootable.  Then go ahead with the install as normal, and wait for the installation to finish.

Once the installation is complete, do not reboot, just close the installer.  Open up terminal and mount your '/' partition.  Continue these steps in the live environment. 

Code: [Select]

sudo mount /dev/sda3 /mnt
Now before we create out snapshots, we want to first edit fstab and grub.cfg the reason is if we snapshot first then we have to fix the same files in the snapshot subvolume.  However we will create them later, what ever you choose for a name its up to you.  I will use @root and @home as an example, however lets continue.

Code: [Select]

sudo nano /mnt/etc/fstab
Should look similar to this; now lets add our subvol flag/option.  Also if you wish to add compression and ssd options, depending on your setup.

Code: [Select]

UUID=0fa86929-b194-4f90-b233-1519004f4122     none                 swap         sw                                            0    0   
UUID=244bab70-ce04-4b50-b546-6b55cc72e15e     /                    btrfs        defaults,relatime                             0    1   
UUID=e47c65e5-ff69-4a16-86af-497ac6921f12     /home                btrfs        defaults,relatime                             0    2   
so my '/' and '/home' mounts btrfs options will look like this.

Code: [Select]

UUID=244bab70-ce04-4b50-b546-6b55cc72e15e     /                    btrfs        defaults,relatime,subvol=@root                             0    1   
UUID=e47c65e5-ff69-4a16-86af-497ac6921f12     /home                btrfs        defaults,relatime,subvol=@home                             0    2   
Ok save and exit.  Now we should never update /boot/grub/grub.cfg directly but this is the easiest way for us to boot into the subvolume, we'll properly fix grub.cfg once we boot into the subvolume.

Code: [Select]

nano /mnt/boot/grub/grub.cfg
Look for this section we are going to edit just to boot into the subvolume, clean up the file system and then update grub.

Code: [Select]

menuentry 'siduction 2013.2.0 december (xfce) GNU/Linux' --class siduction --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-244bab70-ce04-4b50-b546-6b55cc72e15e' {
    load_video
    insmod gzio
    insmod part_gpt
    insmod btrfs
    set root='hd0,gpt3'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  244bab70-ce04-4b50-b546-6b55cc72e15e
    else
      search --no-floppy --fs-uuid --set=root 244bab70-ce04-4b50-b546-6b55cc72e15e
    fi
    echo    'Loading Linux 3.12-6.towo-siduction-amd64 ...'
    linux    /boot/vmlinuz-3.12-6.towo-siduction-amd64 root=UUID=244bab70-ce04-4b50-b546-6b55cc72e15e ro  quiet
    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-3.12-6.towo-siduction-amd64
We need to focus on these three, but we will only edit the first and last of these lines;

Code: [Select]

linux    /boot/vmlinuz-3.12-6.towo-siduction-amd64 root=UUID=244bab70-ce04-4b50-b546-6b55cc72e15e ro  quiet
    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-3.12-6.towo-siduction-amd64
to

Code: [Select]

linux    /@root/boot/vmlinuz-3.12-6.towo-siduction-amd64 root=UUID=244bab70-ce04-4b50-b546-6b55cc72e15e ro rootflags=subvol=@root quiet
    echo    'Loading initial ramdisk ...'
    initrd    /@root/boot/initrd.img-3.12-6.towo-siduction-amd64
Ok save and exit.  Now lets create our snapshots sub volumes.

Code: [Select]

sudo btrfs subvolume snapshot /mnt/ /mnt/@root
Ok since we have mounted sda3 earlier to mnt, we are creating a subvolume called @root under the root subvolume that we installed siduction under.  Now its also a snapshot as well which is what we want.  It this operation shouldn't take longer than a few seconds. 

Now lets do create a file in the new '/' so we can confirm if we have actually booted into this subvolume. 

Code: [Select]

sudo touch /mnt/@root/snapshot-01-12-2014
This creates an empty file, in that subvolume we will use to verify we are in the right subvolume.  Now if you cd into /mnt and do an ls, you should see @root as a regular folder.  Now if you cd into @root, you should see the same folder structure, (without @root) and that empty file we created as a sanity check.

Ok now if you are doing the same hing with home, we can mount /dev/sda4 to /mnt/home and create a subvolume snapshot.

Code: [Select]

sudo mount /dev/sda4 /mnt/home
sudo btrfs subvolume snapshot /mnt/home /mnt/home/@home
Ok now we need to re-install grub and tell it to boot using the /boot in the @root subvolume.

Code: [Select]

sudo grub-install –boot-directory=/mnt/@root/boot /dev/sda
Ok great now lets reboot and leave the live disc and into our new siduction install on the hard drive.  Once you login switch to the root user, cd to '/' and do a ls.

Two things you should notice first that @root is not that and second there is a file called snapshot-01-12-2014.  If you do then, perfect, now lets mount that root subvolume, clean it up and then update grub.

Now the other thing is if you cat /proc/self/mountinfo you can also confirm you have booted and correctly are in the @root subvolume.

ok so now we mount the root subvolume to /mnt and clean it up.

Code: [Select]

mount /dev/sda3 /mnt
Now this may seem confusing since we have mounted sda3 but we have actually mounted a subvolume in on sda3.  Now cd to /mnt

Code: [Select]

cd /mnt
Now be very careful, we are going to delete the folders in here but we DO NOT want to delete the subvolume.  The subvolume appears as a regular folder in btrfs.  Here is the output from ls, not that we won't delete @root but will delete everything else.

Code: [Select]

root@siductionbox-xfce:/mnt# ls
bin   dev  home  lib64  mnt  proc  @root  sbin     srv  tmp  var
boot  etc  lib   media  opt  root  run    selinux  sys  usr

If you have a better way to delete the folders, without deleting @root, let me know but I just rm -rf each folder.

So when you are done you should have @root as the only folder left.  Also for me it makes sense to use @ at the front of a volume name or _ that way you know its subvolume and not a folder.

now lets fix our home folder

Code: [Select]

umount /mnt
mount /dev/sda4 /mnt
now in when I go into /mnt I should see two folders one named @home and the other my username of course.  delete the folder named your username, in my case;

Code: [Select]

rm -rf terroreekdid the trick for me.

ok now unmount /mnt and run update-grub, this will properly fix all the grub options to use the subvolume.

Code: [Select]

umount /mnt
update-grub
That's it.  Reboot and you should be good. 

Once you have confirmed everything is working properly you can do this edit your fstab and do something like this, mount sda3 to /mnt/root/ and prior to performing an update do this as root

Code: [Select]

btrfs subvolume snapshot /mnt/root/@root /mnt/root/@root_snap-01-12-2014
Now upgrade, if your system breaks, you can simply roll back by doing this

[code]mv /mnt/root/@root /mnt/root/@badroot
mv /mnt/root/@root_snap-01-12-2014 /mnt/root/@root
reboot, and you are back into a working state.  then you just need to

Code: [Select]

btrfs subvolume delete /mnt/root/@badroot
The thing you should be aware of is that snapshots are block level changes and it doesn't show free disk properly.  So becareful with using snapshots. 

[piper]

Looks good, except for the sudo part,
which by the way won't work on siduction unless you manually use visudo in a terminal and edit the sudoers file

But why ...

[terroreek]

The sudo parts are done while still in the live environment.  I should have made that more clear, I'll edit my post to reflect it.


I know why and I have read the reasoning behind why sudo is disabled in siduction and I am sure it's unpopular opinion but I like sudo, and yes I do enable it on my machines. 

[dibl]

Nice tutorial -- thanks for that.


I'm a little confused about one aspect.  I have a "desperado" LXDE installation on a netbook that I only use for browsing and webmail, except I did install dolphin and whatever its dependencies are.  With only one kernel installed, df -h shows this system is 4.5 GB today.  If I cleaned up old logs and worked at it, I might get it down closer to 4GB.  But if your OS partition is only 4GB, how are you going to fit a snapshot into it?


BTW to answer your earlier question, my primary desktop (see my sig) started out as an aptosid system in early 2011 and I "cross-graded" it to siduction at the beginning of 2012.  It has a pair of WD hdds in a single btrfs filesystem for my main data.  There are 4 other siduction systems around my house.