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
-
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.
- Top
- Bottom
Leave a comment:
-
Originally posted by oshunluvr View PostMost 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 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.
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.
- Top
- Bottom
Leave a comment:
-
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 }
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.
- Top
- Bottom
Leave a comment:
-
Guest repliedHi 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.
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
- Top
- Bottom
Leave a comment:
-
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!
- Top
- Bottom
Leave a comment:
-
Originally posted by oshunluvr View PostHmm (to borrow from woody!) ...oshuncrazygodgeekluvr... I like it
Originally posted by oshunluvr View PostVinny, you'd end up with:
P1: 4GB swap
P2: 496GB@Kubuntuand all the free space floating around would be consolidated. Not to shabby, eh?
@home
@Ubuntu
@Backtrack
@storage
I mean I couldn’t just convert 6 partitions to BTRFS without loosing every thing ,,,,,could one.....
VINNY
- Top
- Bottom
Leave a comment:
-
Originally posted by Qqmike View PostJeez, oshun, vinny, reads like Greek to me. You ARE on a roll!
- Top
- Bottom
Leave a comment:
-
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@Kubuntuand all the free space floating around would be consolidated. Not to shabby, eh?
@home
@Ubuntu
@Backtrack
@storage
- Top
- Bottom
Leave a comment:
-
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!
- Top
- Bottom
Leave a comment:
-
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
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
- Top
- Bottom
Leave a comment:
-
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.Tags: None
- Stuck
- Top
- Bottom
- Likes 1
Leave a comment: