Announcement

**GreyGeek** · Oct 02, 2012, 10:52 AM

Awesome post, Oceanluver!

**vinnywright** · Oct 02, 2012, 03:42 PM

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

**SteveRiley** · Oct 02, 2012, 04:31 PM

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

**Qqmike** · Oct 02, 2012, 04:41 PM

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!

**oshunluvr** · Oct 02, 2012, 04:58 PM

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?

**SteveRiley** · Oct 02, 2012, 05:01 PM

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.

**vinnywright** · Oct 04, 2012, 07:27 PM

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

**oshunluvr** · Oct 04, 2012, 11:05 PM

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!

**Guest** · Jun 15, 2013, 01:45 PM

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

**oshunluvr** · Jun 15, 2013, 02:27 PM

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.

**SteveRiley** · Dec 14, 2014, 11:23 PM

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.

**GreyGeek** · Dec 15, 2014, 01:52 PM

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!

**SteveRiley** · Dec 15, 2014, 02:23 PM

Abstractions, FTW!

Announcement

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment