How to migrate from btrfs to ext4 ?

English Install/Boot/Login
1

Hello

I want to migrate from btrfs to ext4 on leap 15.0
Btrfs needs a lot of cpu after a crash and other times too on netbooks so I want to go back to ext4.

My question: What is the right way to backup and restore whole system?
Dump does not work, the only solution I see is with tar, recreated partitions and restore with a live system.

Any other idea?

Thanks

2

That is how I would do it. Thus, no, not another idea :wink:

BTW, I am not sure that “recreating partitions” is needed. Just create an ext4 file system on the existing partition is enough. Except if you of course have other wishes the just what your title and post say.

3

Yes, I would do what you suggest – using “tar” for the backup.

And note that after restore, you probably need to reinstall grub. And you need to fix any UUID in “/etc/fstab” (and “/etc/crypttab” if that file exists).

I’ve been using “ext4” all along. I experimented with “btrfs” for a while, then changed to “ext4”. But I did that with a reinstall – it was Tumbleweed, so I reinstalled with the current iso.

You might want to consider reinstall, except use Leap 15.1 for the reinstall (currently at a release candidate level).

4

I’ve only recently started thinking about this, here are some suggestions if you want to try an in place conversion (of course when experimenting you should make sure your data is fully backed up).

First,
You have to consider the BTRFS volume/sub-volume structure.
I don’t know if that can be left in place, noting that the YaST Volume Manager module is supposed to manage both LVM and BTRFS volumes seamlessly (I haven’t verified this but take documentation at word).
If you want to instead convert subvolumes to directories, the following may provide some guidance… The posters didn’t actually convert anything, they appear to have created new and then copied data from old to new.

https://www.reddit.com/r/archlinux/comments/7dsfbo/how_to_convert_btrfs_subvolume_into_regular/

The data in the parent volume is easier to address.
The following “fstransform” is supposed to be able to convert almost any filestem to another including BTRFS to EXT4

https://software.opensuse.org/package/fstransform?search_term=fstransform
https://github.com/cosmos72/fstransform

If all this seems too much trouble especially if your system is very new and has very little customization, you would likely find it easier and more sure to simply save your data to an external location and re-install.

TSU

5

If you’re on Leap 15.0 then, there’s usually a Btrfs system partition and, an XFS User (/home) partition.

Simply overwrite the existing Btrfs system partition with a new ext4 system partition and, leave the XFS User (/home) partition as it is – do not recreate the /home partition …

  • After the reinstallation has completed, review the Package list you saved to your home directory (which shouldn’t have been touched by the reinstallation process) and, reinstall any missing packages.
  • Of course, you should, before starting, backup your Home partition to another drive – an attached disk or a NAS.
  • There’s no real need to backup to system partition as such but, the list of user’s using the system does of course need to be backed up and, any customized system settings.
  • If you’re not using LDAP to authenticate the people using the system then, they’ll have to re-enter their passwords when the system comes back online after the system partition change – the files ‘passwd’ and ‘shadow’ in “/etc” will be recreated, with new keys, by the re-installation.
  • Don’t forget to make a note of the password for the user “root” before performing the re-installation …
6

If you don’t have to deal with any subvolumes, you might be able to simply run the “fstransform” utility I mentioned.
Am guessing that the remaining Volume structure can be managed like an LVM volume, but would need to be verified…
I’m also guessing that any such operations on the root partition would need to be done by unmounting the partition first which would mean running fstransform from an alternate boot like a LiveCD. I don’t know that this kind of relatively low level disk operation would be done through a re-boot although it’s probably technically possible.

TSU

7 
Currently, the programs mentioned above have been tested on Linux with the following filesystems, both as source and as target: ext2, ext3, ext4, jfs, reiserfs, xfs.

Do NOT use these programs with other filesystems unless you are willing to LOSE your data.
8

The warning you found is boilerplate that applies to general use of fstransform and is not specific to BTRFS.

First, if anyone wants to use fstransform, although the openSUSE package might work, its codebase is about 4 years old and the fstransform project on Github indicates last major codebase changes were 2 years ago with minor patching since… and as recently as a few weeks ago. If you’re in a hurry, you may want to build from the Github source, else check the date in the OBS repo.

The fstransform Github page

The fstransform OBS for the package

The first thing to note in the project’s TODO page is that a group of file systems that include BTRFS is just not tested adequately that the author can feel comfortable supporting officially. Note that the TODO page was last updated in 2017, and documentation is slow to be updated… NTFS “experimental” support was added 2 years ago, NTFS testing was completed satisfactorily a year ago and yet this TODO page has not been updated.

Some people have gone ahead and used fstransform to convert their BTRFS to EXT4 anyway and been successful, you can find those postings by doing an Internet search “fstransform btrfs to ext4”

To run fstransform doing this conversion, you may need to add the “–force-untested-file-systems” option as follows, and is described in this Fedora article dated January 2019

 fstransform /dev/sdb1 btrfs --force-untested-file-systems

TSU

9

You may install squashfs and try mksquashfs: http://tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html

10

I’m suggesting that, the only reliable method is to reinstall – i.e. boot the installation DVD and then perform an installation which will reformat the system partition and, the EFI partition as well but, leave the User partition (/home) “as is” …

11

Hello

I’ve done the backup with tar, created a new partition, installed tar, changed /etc/fstab to mount new root (sda10), disabled all subvolumes
and reinstalled grub with yast.
There is reconigzed installation for sda10 and created grub entries but booting new version will hang before displaying sddm.
Booting to single user shows, that old root is mounted from sda2 not sda10.
My question. Is the root configure in initrd? Or is the problem the /boot which is a subvolume?
Should I create a ext4 for boot which is shared amoung this 2 versions?

What is strange for me that old root UUID is used in new version in grub, but if I change it to uuid of sda10 it will not boot.
Is this to find /boot?
Other which surprise me that ext2 module is loaded instead of ext4.
Partition was created with gparted because disk is in GPT format…

Any ideas?

Here relevant grub config

BEGIN /etc/grub.d/10_linux

menuentry ‘openSUSE Leap 15.0’ --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-simple-01c691d6-a48a-4b79-8454-2e9fae48c909’ {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod btrfs
set root=‘hd0,gpt2’
if x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 01c691d6-a48a-4b79-8454-2e9fae48c909
else
search --no-floppy --fs-uuid --set=root 01c691d6-a48a-4b79-8454-2e9fae48c909
fi
echo ‘Loading Linux 4.12.14-lp150.12.58-default …’
linuxefi /boot/vmlinuz-4.12.14-lp150.12.58-default root=UUID=01c691d6-a48a-4b79-8454-2e9fae48c909 ${extra_cmdline} resume=/dev/disk/by-uuid/584318b1-7b12-4955-a069-1d583b535bf2 splash=silent quiet showopts
echo ‘Loading initial ramdisk …’
initrdefi /boot/initrd-4.12.14-lp150.12.58-default
}
submenu ‘Advanced options for openSUSE Leap 15.0’ --hotkey=1 $menuentry_id_option ‘gnulinux-advanced-01c691d6-a48a-4b79-8454-2e9fae48c909’ {
menuentry ‘openSUSE Leap 15.0, with Linux 4.12.14-lp150.12.58-default’ --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-4.12.14-lp150.12.58-default-advanced-01c691d6-a48a-4b79-8454-2e9fae48c909’ {
load_video

…

END /etc/grub.d/10_linux

BEGIN /etc/grub.d/20_linux_xen

END /etc/grub.d/20_linux_xen

BEGIN /etc/grub.d/20_memtest86+

END /etc/grub.d/20_memtest86+

BEGIN /etc/grub.d/30_os-prober

menuentry ‘openSUSE Leap 15.0 (on /dev/sda10)’ --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option ‘osprober-gnulinux-simple-f34a1f92-f4fb-4868-aee3-d64533bf135e’ {
insmod part_gpt
insmod ext2
set root=‘hd0,gpt10’
if x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10 --hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10 f34a1f92-f4fb-4868-aee3-d64533bf135e
else
search --no-floppy --fs-uuid --set=root f34a1f92-f4fb-4868-aee3-d64533bf135e
fi
linuxefi /boot/vmlinuz-4.12.14-lp150.12.58-default root=UUID=01c691d6-a48a-4b79-8454-2e9fae48c909 ${extra_cmdline} resume=/dev/disk/by-uuid/584318b1-7b12-4955-a069-1d583b535bf2 splash=silent quiet showopts
initrdefi /boot/initrd-4.12.14-lp150.12.58-default
}
submenu ‘Advanced options for openSUSE Leap 15.0 (on /dev/sda10)’ $menuentry_id_option ‘osprober-gnulinux-advanced-f34a1f92-f4fb-4868-aee3-d64533bf135e’ {
menuentry ‘openSUSE Leap 15.0 (on /dev/sda10)’ --class gnu-linux --class gnu --class os $menuentry_id_option ‘osprober-gnulinux-/boot/vmlinuz-4.12.14-lp150.12.58-default–f34a1f92-f4fb-4868-aee3-d64533bf135e’ {
insmod part_gpt
insmod ext2

12

Yes, but root= parameter on kernel command line should override it.

13

I would recommend rebuilding the “initrd”.

14

Migration requires grub2-install and grub2-mkconfig: https://forums.opensuse.org/showthread.php/530526-migrate-USB-installation-to-internal-disk

15

grub was reinstalled with yast module grub, so I guess this will to the stuff right…

If I created initrd the other installation would not work anymore because both use this kernel :frowning:
No other solution?

16

I’m not understanding that. The “initrd” file is in “/boot”. Are you sharing the same “/boot” between two system?

17

Yes I have a shared boot.
I always had a shared boot as first partition from the the plan old problem that /boot must be before cylinder 1024 for lilo.
I know that this barrier ir not anymore existent, but if /boot is not shared between different systems, how a system kernel update
can update grub.config which is in /boot?

18

Even if I don’t share /boot for same distro and version twice installed (as backup for example on same disk, for test purpose)
/boot/efi/EFI/opensuse/grubx64.efi
would be the same for both installation and will suffer from the same problem…
So what is the solution to this problem?

19

I normally turn off “os-prober”. And then I add boot entries to “/etc/grub.d/40_custom” for other systems. And the boot entry uses “configfile” to run the “grub.cfg” from the system that I want to boot. That way each system need only update its own “grub.cfg”. But it does result in going through a two-level menu (main menu + menu from configfile).

20

You can actually have a different directory (instead of “opensuse”) in the EFI partition. You just have to set the DISTRIBUTOR line in “/etc/default/grub”. The first word of DISTRIBUTOR becomes the directory name to be used.

I tried that, but didn’t like it. So my alternative strategy is:

I keep a separate subdirectory for each system. So “tw” is the Tumbleweed subdirectory. That’s “/boot/efi/EFI/opensuse/tw”. And I keep a copy of the files in the subdirectory for that system. Then I can decide which I want to control booting, by copying that subdirectory to its parent. The drawback is that you have to maintain those subdirectories (update them whenever grub is reinstalled).00000