Suggestions for Dual - Boot Hard Drive Partitioning

[oshunluvr]

I will say that due to both installers defaulting to "@" and "@home" you must install one of them first, rename the subvolumes, then install the second.

openSUSE Leap had some partitioning requirements that Kubuntu doesn't have. Specifically a very large EF02 (BIOS BOOT for gpt disks) partition (8MB) that it required before installing. I've never needed my EF02 to be larger than 1007B (the amount you can fit in sectors 34 to 2047 ). I didn't try to pre-create this partition prior to the openSUSE install to see if it would proceed with the smaller size, but it might.

What I would probably do if this were my setup is let openSUSE install and configure the drive. Then boot to Kubuntu LIVE and mount the root btrfs file system and rename openSUSE's "@" and "@home" to something else. Then install Kubuntu onto the btrfs partition without reformatting. Do the edits and move Kubuntu to "@Kubuntu" and "@Kubuntu_home". Then move openSUSE back to "@" and "@home" and reboot. Then Kubuntu would be controlling grub for when I deleted openSUSE later

[oshunluvr]

FYI for all reading this, when I said

but reformatting the btrfs volume (which does nothing in reality)

in post #15, I was referring to the fact that BTRFS formatting or reformatting does not actually remove any data including existing subvolumes. To actually "reformat" a btrfs file system, you have to use "wipefs" first to clear all the inodes. Then your old subvolumes will be destroyed (or at least not easily found).

IF you wish to reuse a btrfs file system without wiping it completely, you must remount it at the root level and manually delete (with "commit") each of the subvolumes. Otherwise, they may still exist and you won't be able to create a subvolume of the same name.

The

[GreyGeek]

I downloaded and burned the big 3.6Gb verson onto a 32Gb USB using Etcher. When I booted into it I was totally surprised by what I was presented with. Thinking that I'd get a LiveUSB version that I could explore and play with, and from which I'd select a 64GB USB stick I had prepared and install Leap 15 to it using Btrfs as the root filesystem, what I got instead was a menu on which the only viable option at the moment was "Installation". No "Live" version to play with. I started it and at the point where it wanted me to select a drive the only offering it made was my three internal HDs. I plugged in the 64GB USB stick but SUSE wouldn't play ball. So, I aborted. I did take a picture of the 13 subvolumes it proposed to create.

[oshunluvr]

Seems like a lot doesn't it? I guess if you separated out the portions of the OS you wouldn't want included in a backup, it might makes sense. Seems like overkill tho.

I had all kinds of trouble getting openSUSE to boot Kubuntu after it was installed. The "default subvolume" kept blocking my ability to see the @Kubuntu subvolume. I finally figures out that if I set the default subvolume to 5 (the root subvolume), it seems to work normally.

I wonder if the installers are setting that or where it's coming from. I just checked my KDEneon install and it's set to 5.

Seems like a bug to me because it prevents booting to another distro on the same btrfs file system.

[oshunluvr]

With it set to 5 I can boot Kubuntu OK but not openSUSE. It's grub menu depends on the default subvolume apparently. Definitely a bug.

[oshunluvr]

Add to that the really poor way the installer sets up fstab if you don't use the "Guided" or default installation and it's a no-go for me. Too much work just to get it usable for no reason. It didn't even use the swap at installation unless you manually entered it.

If you want an alternative to Kubuntu to boot to once in a while, try Manjaro. It's totally different from Debian based systems but installed easily and runs quickly. Worth a look...

[oshunluvr]

Well, I did a fresh install of K18.04 and it did not reset the default subvolume so it must be an openSUSE only thing. Also, with the default subvol set at 5 like it's supposed to be, the root volume mounts easily as it has before.

Again, I can't understand why they do all of this purposeful obfuscation? Why make 13 subvolumes only to practically hide them by changing the default subvolume? What a piece of crap.

[GreyGeek]

For a reference, here is what OpenSUSE Leap 15 offered me for subvolumes on installation.



Notice what it wants to do with /home!!! Assign 652Gb out of 698Gb as XFS.

OpenSUSE Leap 15 isn't really a Btrfs installation, it is mostly an XFS installation. Combined, it makes a hybrid monster. One would have to follow two backup & restore paradigms to maintain it.

Wow. They have jumped off the deep end. It is a distro I will never return to. And I thought all modern distros were pretty much equal except for KDE. Was I ever wrong. I take back all I said about "you can't go wrong using OpenSUSE".

[jlittle]

I'm sure someone has reasons for them all.

For me, mysql puts its default tablespace in /var, and that's a nuisance; I'd really like to roll back a dodgy update without rolling back mysql. And not backing up /tmp with the rest of @ would be a win.

[GreyGeek]

Suggestions for Dual - Boot Hard Drive Partitioning

I’m sure SUSE devs have a basic use case in mind for using two filesystems, and putting all of /home on XFS, but having xfsdump copying /Home one file at a time, regardless of how fast it is, can’t match the speed of COW in Btrfs. Using xfs_copy requires shutting the system down or using xfs_freeze. I researched its xfsdump speed and found almost no info, which was surprising. One report talked about taking 5,700 seconds to back up 273 Gb, reading between the lines.

As far as your requirements are concerned:

Mount /dev/disk/by-uuid/xxxxxxxxxx /mnt

btrfs subvol create /mnt/@tmp

Edit fstab to bind @tmp to /tmp

Umount /mnt

Reboot

Since /tmp is now a subvolume its contents will not be included in a snapshot of @, just the way @home’s contents are not included in a snapshot of @. When making “backups” of your system @tmp can be ignored. IF, of course, /tmp’s contents are deleted on a regular basis and some app hasn’t taken to use it for data retention.

Do the exact same thing for /var, which can then be snapshotted without necessarily snapshotting @ or @home.

After creating @var and before unmounting /mnt copy the contents of /var to @var.
mv/mnt/@/var/* /mnt/@var
This action will, no doubt, require the DB engine be shutdown.

And, like VirtualBox’s virtual drives, @var has to be created as a “nocow” subvolume for the same reasons.

There is no problem with creating a snapshot of a subvolume mounted with nodatacow. But since cow is required to create a snapshot, when you create one on a subvolume with nodatacow it will essentially ignore nodatacow; acting as it normally would. Nocow still remains on the subvolume after snapshotting. So, while snapshotting, MySQL can remain in operation. Its snapshot disk space usage will probably expand rapidly to match the subvolume, but I’m just guessing.

Btrfs send & receive of @var to archival storage (local a/o off-site) can then be done in the background while the server continues to serve.

Win-win.

And the only FS involved is Btrfs.

[jlapinsk4]

I ran into some strange installation issues when I install Suse or Gecko myself. I have been able to get the system to boot each time (but I have not tried to dual boot). I ran into some issues with Manjaro as well but I think they may have been related to the way I made the live USB drive. I do want to take a look at Manjaro, hear great things about it.

[jlapinsk4]

I don't know. I installed Neon LTS User Edition from an ISO and use the repositories that it connects to. I've never attempted to install Neon from a PPA and I don't (didn't) know if such a PPA exists (existed).

Thank you! I just "won" a used laptop on Ebay that I intend to use as a back up system. Once I get it up and running I plan to migrate to Plasma Neon.

[oshunluvr]

I'm sure someone has reasons for them all.

For me, mysql puts its default tablespace in /var, and that's a nuisance; I'd really like to roll back a dodgy update without rolling back mysql. And not backing up /tmp with the rest of @ would be a win.

I agree some custom setups have advantages but the openSUSE scheme isn't a one-size-fits-all so why are they doing it?

For my server, I have /var/www and /var/lib/plexmediaserver in subvolumes just for the reason you describe. Also, I'm transition from 14.04 to 18.04 so I can boot to either and my Nextcloud and Apache2 files (var/www) and my Plex Media Library (/var/lib/plexmediaserver) work and look the same in either install.

If your mysql is in /var/<SOMETHING> moving it to a subvolume and mounting is is cake. I usually put /tmp in RAM but you could easily move it too. I would make sense to pull out whatever didn't need to be in a full backup and put them in their own subvolumes, but it makes initial setup somewhat more work. In m setup, I have to remember to backup those two additional subvolumes but I automate backups so no big deal.

[oshunluvr]

Back to openSUSE, I think they use XFS for home for performance reasons. /var is NOCOW because databases are stored there, but why /root /opt and /usr/local in separate subvols? In the old days of little hard drives, you might mount /opt and /usr/local on a different filesystem to add space to your install, but why now? Separating root makes no sense at and I don't know what /srv would hold. Same for /boot - why move that unless you were using LVM or full encryption?

[oshunluvr]

BTW, unless this has changed recently, you can't make a whole subvolume NOCOW without making the entire file system NOCOW. You can set directories as NOCOW using CHATTR +C, but not a mounted subvolume.

So if for example you wanted to do this to /var/lib/mysql, you could make a subvol for /var/lib and then a directory for mysql and set mysql as NOCOW.