13.1 : dual boot, btrfs and root partition

English Install/Boot/Login
1

Hi there,

I just installed the 13.1 version, seems great !

But I encountered a trouble at installation. I found a workaround, so no big deal, but still, I’d like to have some explanation, if someone can give it to me.

I have a pc, x64, with 2 hard drives, and a dual boot with windows 8.1. My linux hard drive has a / partition and a /home one (besides the swap). I usually install grub on the root partition, and handle the dual boot with EasyBCD.

I read in the release notes that although btrfs wasn’t the default filesystem, it was deemed suitable for everyday use, and as I was doing a neat install, I wanted to give btrfs a shot.
So I installed OpenSUSE ticking the “use btrfs as the default file system” box (the log screen shows a handful of subvolumes are created), edited the partition to mount and format / and /home, edited the bootloader to set it on the root partition (and not the MBR).
The install went fine, but upon rebooting, I end up with the “grub>” command. I tried “ls”, it showed something really close to my windows partition.

After a few attempts, I tried the same thing, but setting my / partition as ext4 (leaving the /home one as btrfs). And guess what ? It worked !
So I have now a functional system, with a btrfs home partition, and an ext4 / partition.

Any ideas as what I should do to have both on btrfs ?

Thanks a lot, and congrats to the OpenSUSE team !

2

There is no way to boot from a btrfs partition as it cannot support booting. You can use btrfs for the root partition, but you will need a separate /boot partition formatted to another file system e.g. ext4. Mine uses uses ext2 and is 500MB. You need enough to support multiple kernels and 300MB would probably suffice.
You would install grub onto the /boot partition. However some further planning is also needed.

If you install btrfs to the root partition, by default Snapper is installed and you should plan to double your normal root partition size to allow for snapshotting whenever YaST or zypper is used to make changes to the system. e.g. 20 GB would be a minimum for that, and you might also need to reconfigure Snapper’s default settings for snapshot retention and cleanup, in order to avoid running out of space and breaking your system.

A separate /home is excluded from snapshotting by default. You can also disable Snapper from any snapshotting even for the system partition, and just use btrfs on root and home partitions.

The details can be found in official openSUSE documentation at Chapter 4. Snapshots/Rollback with Snapper.

You may also have seen 3.1.2.1 Btrfs Partitioning in Chapter 3. Advanced Disk Setup.

3

Had I have read the f* manual more thoroughly, I’d have been able to solve this on my own …

Thanks a lot anyway for taking the time to give me detailed info, much appreciated !

4

Indeed, even good “reference” manuals (IMO that one is) need repeat readings for actual implementation ;). Thanks for your comments.

In fact, for others reading this thread, I missed out the [additional] hourly snapshots you get when Snapper is active by default on a btrfs root partion. It contributes to the double-size “rule of thumb”. I believe the frequency of capture cannot be configured, but the number retained can definitely be changed for the cleanup (a daily cron job).

5

Just an FYI
but with btrfs you do not really need /home partition. you can use a /home sub-volume instead.
the only features that is not compatible with btrfs are Booting and swap.
so for booting as itt said above you need to create a /boot partition with other FS
and swap partition is also need to be created as it’s own space.

6

That is right. So for those using Snapper on a root partition with /home included, making /home a sub-volume is the way to exclude it from those hourly system snapshots. Why exclude? Typically /home contains large static files for multimedia and perhaps for downloaded .iso images and other stuff. To include it would increase significantly and unnecessarily the size of system snapshots and performance overhead.

7

What happens to a sub-volume when you format / it to do a clean install of the next version??

BTRFS looks like a swiss army knife to me and you know swiss army knives are not the best knives

8

A good question to which I don’t know the answer, without researching sub-volumes further. There is a long thread (btrfs as default file system?) in Pre-release forum, including short discussion on the impact of formatting a btrfs partition wrt to recovery using a previous system snapshot. Although it may not have covered sub-volumes specifically.

One doesn’t lose the option to configure /home as a separate partition formatted with btrfs or any other file system type. :slight_smile:

For testing btrfs with Snapper, I used 12.3 (clean-install) with /home on the root partition, openSUSE installer formatted btrfs, and /home set as a sub-volume. After a dist-upgrade to Tumbleweed and regularly applying masses of updates [using zypper dup], I recently chose dist-upgrade again for reaching 13.1, in order to test the impact of a major upgrade on Snapper, disk usage, and partition sizing. So for all that, the clean-install and /home questions just didn’t arise.

9

I don’t know the answer. But I have an impression that the old filesystem is not erased, and at least some snapshots are retained. So I guess that sub-volumes are also retained.

That seems like an apt description.

I experimented with “btrfs” for 13.1 Beta1 and 13.1 RC1. However, I’m back at “ext4” for 13.1 final. And that probably tells you something about my opinion of “btrfs”.

10

I don’t see how that impression can hold up. :slight_smile:

Snapshots are stored within the same partition, so the system snapshots will be in the root partition. If you reformat a btrfs partition, all data in the file system would be irreversibly lost. My understanding is that sub-volumes just work at the logical level, you can add and remove them with YaST Partitioner but not format or reformat them in any way. They are just a useful tecnique, e.g. for preventing /var and other system directory structures from inclusion in snapshots, where openSUSE does the obvious ones by default but it’s a user choice to do /home or not.

11

IMO snapshots should not be on by default. It is just going to raise problems for those that don’t follow things as close as most of us do. I have no real problem with the idea just that bells and whistles should always be an opt in. As to subvolumes it definitely should not have /home subed by default since one of the powers I love about openSUSE is that a default install keeps all my data separate from the system and thus easier to protect when install new versions or even different OS’s

12

On 2013-11-21 10:26, AKoine wrote:
>
> Had I have read the f* manual more thoroughly, I’d have been able to
> solve this on my own …

YaST should also know this.

And the release notes paragraph about btrfs should say this, too, as
YaST does not.

The people reading forums and lists are aware of the pitfall, but not
everybody is, as the OP.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

13

On 2013-11-22 20:36, gogalthorp wrote:
>
> IMO snapshots should not be on by default.

They are needed for features such as package installation reversal.

> It is just going to raise
> problems for those that don’t follow things as close as most of us do. I
> have no real problem with the idea just that bells and whistles should
> always be an opt in. As to subvolumes it definitely should not have
> /home subed by default since one of the powers I love about openSUSE is
> that a default install keeps all my data separate from the system and
> thus easier to protect when install new versions or even different OS’s

I don’t yet understand how to do an install keeping home intact when
both home and root are different volumes of the same partition. I’m
afraid that this would need a new setting in YaST, and YaST isn’t ready
for new features this cycle (they were busy migrating to ruby).

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

14

They are needed for features such as package installation reversal.

You mean like uninstall the new package and revert to an old like Yast already does.

I can see possible scenarios where snapshots could be useful but really for most desktop situations it is just a CPU grabber like neponuk. Another thing that should not be on by default. First thing I do with a new install is turn it off. Ok so some people may like it and have a use, but most people don’t and the indexing just gets in their way. Lawyers would probably love it.

My point is that if you want and or need it then turn it on it should not be turned on by default.

15

On 2013-11-23 00:16, gogalthorp wrote:
>
>> They are needed for features such as package installation reversal.
>
> You mean like uninstall the new package and revert to an old like Yast
> already does.

Huh, no. You have to undo the entire yast operation, not a single
package, as long as the system made a “photo” just before the operation.
You simply undo it, but /var/log has to be a separate volume so that the
logs remain and keep track of both operations and whatever happened in
between.

> I can see possible scenarios where snapshots could be useful but really
> for most desktop situations it is just a CPU grabber like neponuk.
> Another thing that should not be on by default. First thing I do with a
> new install is turn it off. Ok so some people may like it and have a
> use, but most people don’t and the indexing just gets in their way.
> Lawyers would probably love it.

They are thinking of a lot of neat ideas to do if the filesystem is
btrfs with volumes and snapshots, so get used to the idea :wink:

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

16

I’m going to wait till those neat ideas are in place, before I try “btrfs” again. At present, it looks too much like hard work to make full use of it.

17

On 2013-11-23 02:06, nrickert wrote:
>
> robin_listas;2600611 Wrote:
>> They are thinking of a lot of neat ideas to do if the filesystem is
>> btrfs with volumes and snapshots, so get used to the idea :wink:
>>
>
> I’m going to wait till those neat ideas are in place, before I try
> “btrfs” again. At present, it looks too much like hard work to make
> full use of it.

I don’t know how many years you’d wait :slight_smile:

Or maybe you can do it right away, just that YaST is not aware of it.

But then, I also heard of very nice ideas to do with reiserfs4, and I
have not seen them…

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

18

I do not know what you mean under “it cannot support booting” but you of course can install bootloader on btrfs partition and do not need any extra partition for /boot.

TARGET                           SOURCE       FSTYPE     OPTIONS
/                                /dev/sda2    btrfs      rw,relatime,space_cache
├─/sys                           sysfs        sysfs      rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security         securityfs   securityfs rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup               tmpfs        tmpfs      rw,nosuid,nodev,noexec,mode=755
│ │ ├─/sys/fs/cgroup/systemd     cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
│ │ ├─/sys/fs/cgroup/cpuset      cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,cpuset
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,cpuacct,cpu
│ │ ├─/sys/fs/cgroup/memory      cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/devices     cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/freezer     cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/net_cls     cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,net_cls
│ │ ├─/sys/fs/cgroup/blkio       cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,blkio
│ │ ├─/sys/fs/cgroup/perf_event  cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,perf_event
│ │ └─/sys/fs/cgroup/hugetlb     cgroup       cgroup     rw,nosuid,nodev,noexec,relatime,hugetlb
│ ├─/sys/fs/pstore               pstore       pstore     rw,nosuid,nodev,noexec,relatime
│ └─/sys/kernel/debug            debugfs      debugfs    rw,relatime
├─/dev                           devtmpfs     devtmpfs   rw,relatime,size=379604k,nr_inodes=94901,mode=755
│ ├─/dev/shm                     tmpfs        tmpfs      rw,relatime
│ ├─/dev/pts                     devpts       devpts     rw,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/mqueue                  mqueue       mqueue     rw,relatime
│ └─/dev/hugepages               hugetlbfs    hugetlbfs  rw,relatime
├─/run                           tmpfs        tmpfs      rw,nosuid,nodev,relatime,mode=755
├─/proc                          proc         proc       rw,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1    autofs     rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
├─/var/run                       tmpfs        tmpfs      rw,nosuid,nodev,relatime,mode=755
└─/var/lock                      tmpfs[/lock] tmpfs      rw,nosuid,nodev,relatime,mode=755

grub2 is installed in /dev/sda2. Actually, btrfs has better support for booting off partition as it reserves space to embed bootloader which avoids issues with using blocklists on file system in case of ext*.

Now there could be a bug in installer of course, although above system was installed straight from NET CD.

19

I agree, that bit is a bad choice of wording in my first post, and unnecessary. :shame:

20

Why not wait, but also why must one make full use of it? Given there is additional work, planning and knowledge required to implement properly, a phased approach might be better.

Btrfs may be suitable right now as candidate “default file system”. With my simple configuration, btrfs appears to add some performance overhead at boot time, during some snapshotting, and at cleanup.

It is important (IMO), particularly when voicing concerns, to distinguish between Btrfs and Snapper. Not everyone will want/need to use snapshots on a mainly desktop system. At the moment YaST’s support for btrfs seems limited - enough to enable the openSUSE Installer to offer it perhaps.

Right now I wouldn’t recommend that Snapper be enabled by default for a typical default desktop installation. Certainly not because a developer thinks it should always be done that way if btrfs is chosen to be installed over the raw partition known as root. If the Snapper settings’ default values for retention and/or frequency of snapshot capture were reduced, it might change my position re default activation.

BTW root is implemented as the default sub-volume aka default LV (can never be deleted), which can only be cleared by reformatting the btrfs file system apparently. If btrfs file system is installed over the raw partition as it seems to be here, I can’t see how you can then preserve the sub-volume for /home if it’s part of the same file system. Perhaps it’s possible if you implement btrfs using an LVM configuration (I’ve no experience using LVM).