Partitions and security setup for single-boot device


I am waiting for my first tumbleweed install to finish. Coming from another distro and hoping it will work out so that I can stay as it seems well suited to me. I’m a long-term non-advanced/hobby type user. I can often solve problems but I don’t like to create them on a recreational basis. This is my “daily driver” machine.

Now that I have gone through the installer I’m wondering if I made the right choices; maybe I will re do it. So looking for feedback on this. Below are some specific questions but a general answer for someone like me would be very helpful. Or links to somewhere with a bit more information compare to the regular documentation.

On my laptop I have 1 TB SSD available. It already has a /home partition which is 700GB ext4 encrypted. System on another encrypted ext4 partition which I wrote over with the same for Tumbleweed. I don’t boot any other OS and I don’t use RAID. I want to keep everything encrypted.

I do have backups for home but I would like to get away without using them because restoring backups is never straightforward. But I could do it with a little more planning if motivated.

I have never used any of the fancier filesystems suggested by the installed such as btrfs or xfs. Should I? I looked into zfs and related setups in the past but decided against them. They seemed to add a layer of complexity that I wasn’t prepared to deal with. Too much to go wrong. Is the implementation in tumbleweed extremely reliable? I am honestly not that interested in learning about the low-level functioning of a storage device. If there is much chance of this being required than I will stay away.

Who should not use btrfs or xfs? And do they go together somehow? If you use one, do you usually use the other? Why use 2 different file systems?

The documentation is a little too concise. Something that described use cases with appropriate cases would be helpful if anyone has a link. And what problems are likely to be encountered.

Will the installer allow me to create non-compatible set ups? For exmaple, it says:

To encrypt the root partition, make sure to use the GPT partition table type instead of the MSDOS type

Will it allow me to proceed with this or does it have error checking?

Does “data volume” mean something specific in this context? Or is it just any partition where you keep data?

How badly could I screw up the device by enabling trusted boot, secure boot, or the option about NVRAM? Assume for the sake of argument that I am a person who makes errors, forgets things, and there is a limit to how deep into a machine I can go to fix problems. Also I purchased this device refurbed so I do not have any original keys, documentation etc. (But there doesn’t seem to be any existing locks on the bootloader.)

Thanks for reading and maybe replying!

Wow - a multitude of questions!!
Unfortunately, I won’t provide much feedback, but others will be along soon.

Only thing I can offer is my own experience and opinion. I have a separate /home that is XFS. The / is BTRFS. My opinion is BTRFS is good for snapshots and rollbacks (which I’ve never had to do).

I only do backups (using rsync) of the /home. I backup once a week, on average (laptop and desktop). To me, XFS is well established, reliable.

If anything catastrophic happens to /, and I can’t do a rollback, I’ll simply reinstall. Faster and easier (to me, anyway).

I’m using “ext4”. I do have “btrfs” on one system for testing. But even there, I use “ext4” for “/home”.

I’m also using encryption, including on one computer with MSDOS partitioning.

When you use GPT partitioning, there is a special partition required – a “bios_boot” partition. And part of the grub boot code goes there. Booting with an encrypted system does require more boot code, and that’s probably why they are recommending GPT partitioning.

It should be okay with MSDOS partitioning if the gap between the MBR and the first partition is large enough. On recent systems, that gap is 1023 sectors. On really old MSDOS partitioned systems, it is only 63 sectors, and 63 is possibly too small for the crypto code needed.


I simply use GPT partitioning and all partitions are ext4, done so for years and still see no reasons to change.

Personally, I have never bothered to use trusted boot, nor secure boot. That is a personal decision.

Both XFS (from what happened to someone else I know) and Btrfs (IME) would lead to complete FS corruption on one too many unclean reboot/reset. In this regard when using with a mobile device that could potentially run out of charge it’s recommended to use ext4. For example, Android still uses ext4 extensively and most distros in the Debian sphere also default to it.

Forget XFS, if you want a no-nonsense hands-off FS that just works it’s ext4. If you could learn a little bit about the FS, then btrfs is the best IMHO. You don’t need to have a Phd in btrfs, but learning the bare minimum of how it works and the basic commands in btrfs --help gives you a level of control over your data and features (like atomic snapshots, subvolumes) that other filesystems can’t. If what makes a good programmer is memory management, then I would say what makes a good user is storage/FS management. All that CPU, GPU, NPU, DPU, TPU jazz is after all retrieving data from the disk/FS, manipulating it in someway, and storing it back. So as a user, it’s quite important that you remain in control of your data through exercising some measure of control over the filesystem.

Not much, you can leave it in the default setting. I believe OpenSuse defaults to enabling Secure Boot and access to NVRAM (UEFI settings like boot order) but Trusted Boot is disabled by default. I had trouble installing with Trusted Boot enabled but once the installation was done I was able to enable it from Yast settings on my secondary machine.

I use only Secure Boot on my main machine because I’m not really sure what Trusted Boot does.

thanks everyone! based on the very strong “it depends” vibe I decided to go with what I know and stay with ext4.

Kind of weird to me that the installer defaults to file systems that introduce complexity without providing any warning or even explanation. If I hadn’t already done prior research into fancier filesystems I might have gone with the suggested setup then landed myself in trouble down the line.

Any other dangerous defaults in this distro that I should be aware of?

I read your /home is 700GB.

I would buy a external USB harddrive, I see 2TB around €80 and encrypt it and then use rsync to back up.

Next step, get one more and keep that somewhere external (I have it on my work). Swap the two semi–regularly.

1 Like

I am trying hard to break the btrfs created on 2021-11-24 21:33:32. Some 47 unsafe shutdowns (displayed by smartctl -A /dev/nvme1n1) didn’t corrupt the only partition of infamous host erlangen:

erlangen:~ # fdisk -l /dev/nvme1n1
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F5B232D0-7A67-461D-8E7D-B86A5B4C6C10

Device           Start        End    Sectors  Size Type
/dev/nvme1n1p1    2048    1050623    1048576  512M EFI System
/dev/nvme1n1p2 1050624 3907028991 3905978368  1.8T Linux filesystem
erlangen:~ # 

I had some help from my graphics driver hardware causing kernel panics :sweat_smile:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        27 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Read:                    17,329,214 [8.87 TB]
Data Units Written:                 19,772,138 [10.1 TB]
Host Read Commands:                 139,650,359
Host Write Commands:                251,428,940
Controller Busy Time:               1,380
Power Cycles:                       279
Power On Hours:                     883
Unsafe Shutdowns:                   160

@karlmistelberger Why do you always refer to host erlangen as infamous. I’m curious, what did it do? :thinking:

Is that general advice or specific to this question? If general, how is it an improvement over my existing backup system?

It is generic advice. Not sure how it is an improvement over your existing backup system as I did not read how that looks like.

What I like about rsync is it simplicity and at the same time it’s configurability but if it also something for others depends on liking to write scripts to configure things.

Backups are all good with ext4 and rsync or whatever equivalent you’re using but restoration would be a pain. There are many reasons why OpenSuse chooses to use btrfs as the default FS but this is one of them.

If your backups are not atomic (point-in-time) like with btrfs snapshots, then it would be in an inconsistent state and restoration may or may not work in that state. You would generally be expected to do a deep dive to fix each and every inconsistency issue or selectively restore files that you know are certain won’t be in such a state.

Also, the time to take a backup would be orders of magnitude more (even when using deduplicated solutions such as borg) than incremental snapshot backups using btrfs send/receive.

If you install TW it is best to use BTRFS since TW is more likely to have broken updates and BTRFS has snapper that lets you roll back.

1 Like

But OP doesn’t want to deal with btrfs’ relative complexity, perhaps he might be better off with Leap and ext4 (or Debian) for something that just works.

Well… TW is requires more knowledge and willingness to fix things when the fall over. Snapper is the thing that makes it more manageable, If you don’t want to learn the OS best to use the more stable Leap.

1 Like

If @notsofast is using Tumbleweed, then maybe MicroOS Aeon/Kalpa and flatpaks are they way to go…

1 Like

The app “backintime” available from package management and run as root uses rsync to do complete or increment backups. I have found it’s restore capability to be flawless in restoring files, directories, and needed permissions for user and/or system files. I use ext4 file system for both root and user home.

tom kosvic

Tom, thanks for sharing your experience with backintime and I’m glad it has so far worked for you!
I’m sure you realize this, but have you given some thought to how by the time rsync copies over your files and directories that are being actively modified by you or some other program that it could result in parts of the files and directories being in an incompatible/inconsistent state?

As the rsync backup process is not a point-in-time snapshot like btrfs, cute-cats-program that uses sqlite.db for storing metadata and directory cat-pics for storing the actual data would be out of sync. When you restore this, cute-cats-program would either miss some of the metadata to retrieve the cat pics in its sqlite database or it could have entries in the database pointing to missing pictures in directory cat-pics .

I see. btrfs issues could be related to the SSD, which already uses a substantial amount of spare with only 10.1 TB written. The 970 EVO has:

erlangen:~ # smartctl -A /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.7.5-1-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke,

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        37 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    131,306,041 [67.2 TB]
Data Units Written:                 66,347,601 [33.9 TB]
Host Read Commands:                 697,226,740
Host Write Commands:                1,167,705,733
Controller Busy Time:               2,311
Power Cycles:                       1,995
Power On Hours:                     1,217
Unsafe Shutdowns:                   46
Media and Data Integrity Errors:    0
Error Information Log Entries:      3,117
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               37 Celsius
Temperature Sensor 2:               41 Celsius

erlangen:~ # 

Stuff happened with erlangen too: Disturbing messages from infamous host erlangen - they call it a BUG But it never affected btrfs.

The term “infamous host erlangen” was coined by the administration of the forum. I am using it since then. It started ten years ago: Personal Computer Maßanfertigung: Ich bin beeindruckt | Karl Mistelberger

1 Like