Announcement

Collapse
No announcement yet.

More BTRFS fun: Multibooting to subvolumes on the same partition.

Collapse
This topic is closed.
X
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    More BTRFS fun: Multibooting to subvolumes on the same partition.

    One of the cool features of BTRFS is subvolumes. Subvolumes sort of act like partitions but reside together on a single partition. One of the greatest advantages to this is all your free space is available to any subvolume on a given partition.

    One of the other features of BTRFS is it can reside on a whole device thus no partitioning is required at all. Yes - that's right - mkfs.btrfs /dev/sda rather than mkfs.btrfs /dev/sda1. As an added bonus, BTRFS performs slightly better when it occupies an entire device in this manner.

    As I noted in several previous posts of mine, I multiboot several different distros. I am in the midst of replacing a failing drive and partition re-arranging is going on so I thought this would be a good time to experiment with the idea that one could have several distros installed to the same BTRFS device (partition). Since I multiboot I also use this method of maintaining GRUB and I will reference this post here. For now: the BTRFS partition I am using is not the boot partition so GRUB is being maintained elewhere. I will update this thread when I go full BTRFS.

    It's worth noting that a BTRFS device can be a single partition on a drive, an entire drive, or a combination of drives and/or partitions.

    The basic steps to create multiple installs on a single BTRFS device:

    1. Install your new Kubuntu (10.04 or newer) to the BTRFS device selecting BTRFS as the partition format type. Do not create separate /boot or /home partitions. The installer will automatically create a separate home subvolume. If you were to mount the root device you would see two "folders" named @ and @home. These are actually the subvolumes created by the installer. @ holds the contents of / and @home will contain the contents of /home.

    2. Rename the new subvolumes to something unique. Since I installed Kubuntu Quantal Quetzal this way, I changed @ to @12_10 and @home to @12_10home. This paves the way for the next install to take the default subvolume names without wiping out the current install. NOTE: There is no special btrfs command needed to rename a subvolume. Just use "sudo mv" like you would to rename any other folder or file.

    3. Change the subvolume names in the new install fstab to match the above edits. This is also a good time to add any desired mount options to your fstab, like space_cache, discard, ssd, compress and any others that your system benefits from.

    4. Edit the new install's /boot/grub/grub.cfg to match the new subvolumes names. This is necessary for the first boot into the new subvolumes. Once you're in, running update-grub will put everything right. ***IMPORTANT NOTE*** the root subvolume becomes /@12_10 in grub.cfg rather than just @12_10.

    5. Update 40_custom on your boot install (see the GRUB post linked above) to reflect/@12_10and run update-grub.

    6. Boot into your new install and run update-grub.

    You can now install a second distro and repeat! It should be obvious, but I'll state it anyway: Don't select formatting for the subsequent installs or you'll wipe out this one!

    As multi-booter, this has some serious advantages:
    No lost space or over-full partitions due to over/under-estimating partition sizes. In fact: No partitioning at all.
    When removing unwanted installs the space is immediately reusable.
    All the available space can be used for /home storage.
    All my installs can be backed-up using snapshots.
    For more space simply add in another partition or drive to my BTRFS device without going off-line.

    Admittedly for now; This is more trouble than just partitioning and using ext4. Hopefully soon Ubiquity and other installers will have the ability to create custom subvolumes at install time and this will become the defacto method of installing. However, I just can't help myself and I must lead the pack! As BTRFS grows in features and becomes more widely used, it's many advantages will benefit even the most basic users.

    I'll report back any sucess/failures with this concept soon as I'll be re-doing my system in the next couple of weeks. Happy Kubuntu-ing!
    Last edited by oshunluvr; Sep 27, 2017, 11:44 AM.
    Please Read Me
    Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

    #2
    Awesome post, Oceanluver!
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #3
      awesome cool ,,,,I will half to seriously consider this for my next box or complete redo of this one ,,,,,but for now with all this
      vinny@Vinnys-HP-G62:~$ sudo parted -l
      [sudo] password for vinny:
      Model: ATA WDC WD5000BEVT-6 (scsi)
      Disk /dev/sda: 500GB
      Sector size (logical/physical): 512B/512B
      Partition Table: msdos

      Number Start End Size Type File system Flags
      1 32.3kB 4195MB 4195MB primary linux-swap(v1)
      2 4195MB 26.0GB 21.8GB primary ext4 boot
      3 26.0GB 237GB 210GB primary ext4
      4 237GB 500GB 264GB extended
      5 237GB 268GB 31.6GB logical ext4
      6 268GB 300GB 32.0GB logical ext4
      7 300GB 500GB 200GB logical ext4
      already going on on my 1 little drive I probably don’t want to muck around to much

      P2=Kubuntu /
      P3=Kubuntu ~/
      P5=testing / Ubuntu at the moment
      P6=testing / Backtrack
      P7=storage ,,,,,,Humm the geek in me is screaming "O come on do it" LOL

      VINNY
      i7 4core HT 8MB L3 2.9GHz
      16GB RAM
      Nvidia GTX 860M 4GB RAM 1152 cuda cores

      Comment


        #4
        I am OSHUN, god of BTRFS. Hear me mkfs.roar!

        Comment


          #5
          When I used to post all those cryptic GRUB experiments/configuratuions, did I also appear to be this crazy, I mean geeky?
          !
          :-)

          Jeez, oshun, vinny, reads like Greek to me. You ARE on a roll!
          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

          Comment


            #6
            Hmm (to borrow from woody!) ...oshuncrazygodgeekluvr... I like it

            Seriously - the one thing missing from BTRFS right now is swap support. If you had a single drive system you'd still have to have a swap partition somewhere (or do without it if you're RAMed enough). I have 8GB and rarely have touched swap, but you never know. I also keep tmpfs in RAM which expands into swap space if needed.

            Vinny, you'd end up with:

            P1: 4GB swap
            P2: 496GB
            @Kubuntu
            @home
            @Ubuntu
            @Backtrack
            @storage
            and all the free space floating around would be consolidated. Not to shabby, eh?
            Please Read Me
            Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

            Comment


              #7
              Originally posted by Qqmike View Post
              Jeez, oshun, vinny, reads like Greek to me. You ARE on a roll!
              Yeah... Jeez, Oshun, and Vinny are all definitely some cool dudes.

              Comment


                #8
                Originally posted by oshunluvr View Post
                Hmm (to borrow from woody!) ...oshuncrazygodgeekluvr... I like it
                he he I like it to!!


                Originally posted by oshunluvr View Post
                Vinny, you'd end up with:

                P1: 4GB swap
                P2: 496GB
                @Kubuntu
                @home
                @Ubuntu
                @Backtrack
                @storage
                and all the free space floating around would be consolidated. Not to shabby, eh?
                you do mean if I opted to scrap it all and redo from scratch ,,,right?
                I mean I couldn’t just convert 6 partitions to BTRFS without loosing every thing ,,,,,could one.....

                VINNY
                i7 4core HT 8MB L3 2.9GHz
                16GB RAM
                Nvidia GTX 860M 4GB RAM 1152 cuda cores

                Comment


                  #9
                  Yeah - you'd have to redo it all.

                  In my case since I'm swapping out hard drives anyway it makes sense. In your case, maybe not...

                  ..at least for now!
                  Please Read Me
                  Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

                  Comment


                    #10
                    Hi oshunluvr, thanks a lot for these insights on multibooting with btrfs.

                    I stumbled upon your post a few weeks ago, while I was looking for informations on how to multiboot two GNU/Linux OSes with GRUB2 (it's been only a few months for me in the FLOSS universe and I haven't dualbooted anything else than Ubuntu and Windows yet).

                    I've been running some tests for a while so as to determine what my next install will use/rely on (partition scheme, filesystem, distro...), and hence I have been considering the alternative between LVM + ext4 or btrfs so as to get some flexibility (encryption being a less important concern, although still present).
                    I went on to install Gubuntu 13.04 on a test box with the following simple partitionning scheme: sda1 --> 2G swap and sda2 --> 158G Btrfs with lzo compression, two subvolumes (@ and @home) being automatically created by Ubiquity as you mentioned.

                    After fiddling a bit with snapshots and btrfs tools, the next step was to try to install another distro in my btrfs partition along Ubuntu.

                    1. The subvolume renaming tragedy

                    First issues arose when I changed the two subvolumes' names: I didn't quite follow your advices, as I thought they were especially intended for those already multibooting --step 5 links to your GRUB multiboot post--, and as a result I simply ran a "sudo update-grub" after changing the fstab entries. However I happily discovered that grub.cfg had the new root subvolume name correctly inserted, and I thought step 4 had been automatically handled without requiring me to manually edit the tenth of occurrences.

                    I then rebooted... To be presented with a GRUB rescue console, stating that "Error : file /@/boot/grub/i386-pc/normal.mod not found". I rebooted on a liveCD to check again grub.cfg, but a ctrl+F on the character "@" didn't return any results! So I was left contemplating the fact that maybe it was the MBR part of GRUB that hadn't been updated...
                    Hence I tried to reinstall grub with Boot-repair's default repair, as suggested per the Ubuntu Community Documentation, but as it didn't work I also tried the "restore MBR" advanced option... Which actually made my BIOS unable to find a boot device at all :-/

                    So I decided to reinstall GRUB from liveCD's terminal as the documentation later suggests, following the specific case for btrfs. That did repair my install and I could then go on to the next step: installing another distro.

                    2. The rigid installer paradigm

                    I wanted to install OpenSUSE to check it out, however it appears that despite the great many configurations this distro provides with its YaST installer and despite the fact SUSE has been one of the first to include btrfs support in its commercial distro SLES, it is actually impossible to use a pre-existing Btrfs tree to nest OpenSUSE install in it. First of all it wouldn't recognize Ubuntu being installed in the btrfs partition, offering in the suggested parameters to wipe it altogether (reformat to btrfs: what's the point?), and in the expert partionner while it would let me see my btrfs subvolumes, and even create a new one, there was no way I could commend the installer in using this subvolume as root.

                    I think it has to do with YaST not willing to put /boot in a btrfs partition, besides wanting to create a whole bunch of subvolumes for a server-like use (tmp, opt, srv...). Finally, it seems like SUSE's pretty backwards with btrfs :P My guess is, if I want to try this setup, I should first install OpenSUSE and let it have it its way with btrfs, and then try to install Ubuntu in a subvolume within Ubiquity (not sure Ubiquity has this option in manual partionning though, but as it seems you succeeded in doing it :-)).

                    TL; DR: Not every distro allows installing in a subvolume within a pre-existing Btrfs tree. Chances are that many incorrectly let their choosen distro's installer format the existing partition, even though you do warn against it.


                    I had a second remark, more related to your GRUB multiboot tutorial: while doing all that I had to delve in the GRUB manual so that I'd find info on how to use the rescue console, and at the turn of a paragraph I found this:
                    At least on BIOS systems, if you tell grub-install to install GRUB to a partition but GRUB has already been installed in the master boot record, then the GRUB installation in the partition will be ignored.
                    If possible, it is generally best to avoid installing GRUB to a partition (unless it is a special partition for the use of GRUB alone, such as the BIOS Boot Partition used on GPT). Doing this means that GRUB may stop being able to read its core image due to a file system moving blocks around, such as while defragmenting, running checks, or even during normal operation. Installing to the whole disk device is normally more robust.
                    I was curious about your advice of chainloading to "Sub-OSes"' GRUB, as for example the Arch wiki says that it's not advisable to install GRUB to a partition. The manual kinda stumped me.

                    Sorry for the long post, and thanks again for your interest in this rarely tackled issue of multibooting from within a single btrfs partition.
                    All the best

                    Comment


                      #11
                      Most distros have been slow to consider btrfs when writing their installs. I was shocked when Ubuntu variants supported it so well, actually. It seems I read these comments regularly: "btrfs is still experimental" and "If possible, it is generally best to avoid installing GRUB to a partition".

                      The first comments is just because they are afraid of any file system not 20 years old. I've been using btrfs full time for three years without any issues and many benefits, yes it's under development but so what? That just means we get improvements with kernel updates unlike almost all other file systems.

                      The second comment is actually to protect dummy users from thinking you can boot directly to a partition. It's not like you're damaging anything if you install it to a partition, it's just harder to get to. Here's my logic:

                      If you install grub2 to the MBR with every install you do, that means every time you do an install, the new distro controls grub. What if you don't like the distro? You delete it - and your grub files along with it, leaving your system un-bootable. If you don't install grub2 at all with each distro - you don't have a grub.cfg for that install and you must manually create one and manually update it forever. Why the heck do all that work? Simply install grub to some partition and both problems are solved.

                      To keep your system booting, you should either have a main distro that you will never delete (at least not often) and only allow it to use the MBR, replacing only when you replace that distro. Or do as I did - install a stripped down distro and use it for grub only. I used Ubuntu Server 12.04 and re-labeled it's subvolume to @grub. I boot to it, it uses a manually created (only once) 40_custom file that has a list of all the other distros that point to their grub.cfg's. Thus all grub.cfg updating is automatic. Here's what the stanzas look like:

                      Code:
                      menuentry 'Kubuntu 13.04' {
                      insmod gzio
                      insmod btrfs
                      set root='hd0,msdos2'
                      configfile /@Kubuntu_13_04/boot/grub/grub.cfg
                      }
                      This looks at /dev/sda2 partition and into @Kubuntu_13_04 for it's grub.cfg and then displays it. A simple ESC will return to the previous grub.cfg if I make a wrong selection.

                      Yesterday, I tried ZevonOS "Neptune 31" which supports btrfs install and doesn't force a format, but it does not do a subvolume install - the only way it's of any use. I moved all the files into a subvolume after the install but I haven't tried to boot it yet.
                      Please Read Me
                      Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

                      Comment


                        #12
                        Originally posted by oshunluvr View Post
                        Most distros have been slow to consider btrfs when writing their installs. I was shocked when Ubuntu variants supported it so well, actually. It seems I read these comments regularly: "btrfs is still experimental" and "If possible, it is generally best to avoid installing GRUB to a partition".

                        The first comments is just because they are afraid of any file system not 20 years old. I've been using btrfs full time for three years without any issues and many benefits, yes it's under development but so what? That just means we get improvements with kernel updates unlike almost all other file systems.
                        Indeed. From the Btrfs wiki:
                        The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels.

                        The Btrfs code base is under heavy development. Every effort is being made to keep it stable and fast. Due to the fast development speed, the state of development of the filesystem improves noticeably with every new Linux version, so it's recommended to run the most modern kernel possible.
                        There's a lot great new stuff coming to Linux: Btrfs, systemd, Wayland. Can't wait. All the crufty whiners just don't like change!

                        X simply cannot die early enough. It's buggy, inefficient, and full of security holes.
                        Last edited by SteveRiley; Dec 14, 2014, 11:27 PM.

                        Comment


                          #13
                          Ditto to what Steve said!
                          I've been using Btrfs since I installed Kubuntu 14.04 alpha last January. It has been faultless. It is fast. It is stable. It is EXCEEDINGLY flexible. Need some more room? Plug in an HD, an SD or a memory stick or two and do btrfs device add /dev/sdXn (/dev/sdYm ...) /home and follow it with btrfs filesystem balance /home. These two commands can be done on a LIVE system, i.e., you do NOT need to unmount your file system!

                          Done using the extra space and want to remove the added device? Issue btrfs device delete /dev/sdXn, and when the process is completed you can unplug the device. Again, the file system does NOT have to be dismounted.

                          And this doesn't even touch on all the joys and powers of subvolumes!
                          Last edited by GreyGeek; Dec 15, 2014, 01:55 PM.
                          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                          – John F. Kennedy, February 26, 1962.

                          Comment


                            #14
                            Abstractions, FTW!

                            Comment

                            Working...
                            X