New Tumbleweed user - First Impressions and Issues

English Open Chat
1

Having grown tired of the unstable nature of Arch Linux, I was on the lookout for a somewhat more stable distro which also has reasonably up-to-date packages.

Initially, I settled on the interim releases of Ubuntu, but after its development team somehow managed to make it less stable than Arch by first bricking everyone’s KDE desktop with the 25.04 upgrade, followed by breaking automatic updates as well as the ability to install Flatpaks with the 25.10 upgrade (neither of which ever happened to me on Arch), I knew I needed to find something else.

And after excluding Fedora for instability issues, and Leap for old packages (Leap 16 ships with kernel 6.12, while the latest Ubuntu has 6.17), I knew it had to be a rolling release again, which in practice limited my options to either going back to Arch, or trying out Tumbleweed, so here I am.

Installation

First up, the installer.
After entering all the basic details about the system I wanted to set up, it came to the partitioning stage, where I selected the “guided” option, during which I set up the standard Btrfs main partition, but with encryption.

When I wanted to set up my password however, the installer would not accept a password that contained apostrophes or quotation marks, even though according to the generic error message I received, quotation marks at least should be fine…
I’m not sure why that is, since my Ubuntu system had no issue with handling these characters.

With that hurdle cleared, the next issue came at the end of the installation process, when I received an error message telling me that there is not enough space on the EFI partition to write kernels.
I don’t remember the exact message, but I believe this had something to do with secure boot (which is disabled in my system’s BIOS, so not sure if that was the cause).
There were also a few more error messages, which appear to have been related to the first one, since they referenced some files not being found, but the installation finished up, and the system booted without issue.

After booting, I tried to connect to a WiFi network, but NetworkManager kept failing and re-trying indefinitely, and disabling and re-enabling NetworkManager didn’t fix the issue either.
I eventually re-installed and selected wicked for networking, but for some reason NetworkManager ended up working fine when I switched to it from wicked using YaST.

Usage

Ever since the installation finished however, things have been rather smooth so far.

I especially appreciate how easy it was to install the NVIDIA drivers, which can be done using just two simple commands.

# zypper install openSUSE-repos-Tumbleweed-NVIDIA
# zypper install-new-recommends

These installed both the correct graphics as well as compute drivers for my GPU, and everything worked instantly.

Even on the “beginner friendly” Ubuntu, the tool that is used to install NVIDIA drivers erroneously selected server drivers for my desktop system, so I had to manually select the correct ones, and even then it only installed the graphics driver without compute, so the openSUSE way has been a breath of fresh air.

To my surprise, SELinux didn’t get in my way even once, despite being in enforcing mode.
Security wise, I did notice that it takes root privileges to install Flatpaks, which I haven’t seen before in other distros, though it’s not much of a burden to do so.

Ongoing issues

There is only one issue which I’m still dealing with, which is that one of my CPU cores occasionally end up being pinned to 100% utilization for a minute or so, which results in considerable lag throughout the whole system.

Based on what I’ve been able to observe in the system monitor, the only processes which consumed CPU during these lag periods were related to KDE, though I haven’t been able to find the precise cause or a fix.

Side note: On the openSUSE website, the link that leads to the forum on the bottom of the page is a dead link, which may be worth fixing. :wink:

1 Like
2

@niel234 Hi and welcome to the Forum :smile:
The efi space issue is likely the recent switch to grub-bls which requires a minimum (?) I always configure /boot/efi for 4GB.

1 Like
3

Cheers! :slight_smile:

I did think that 300 MB for EFI seemed rather small, but I didn’t expect the guided partitioner to be making such mistakes.
It’s not like I can easily change it now though, so hopefully it doesn’t break going forward. :sweat_smile:

4

@niel234 I missed the flatpak issue, I’m on GNOME here, but stuck in the old ways and use the command line to install both the flathub repo and flatpacks as my user…

I suspect there may some indexing going on in the background hence the cpu activity, AFAIK it should go away…

5

@malcolmlewis I also use the CLI, but when using flatpak install or flatpak update, PolicyKit pops up when the package is due to be installed (after download) and asks for a password. If it’s not provided, the install fails.
The only way to avoid this is using sudo.

Returning to the partitioning, do you have any idea what partition 2 is here, since it’s not labeled?

nvme0n1                                                                                            259:0    0  1.9T  0 disk  
├─nvme0n1p1                                                                                        259:1    0  300M  0 part  /boot/efi
├─nvme0n1p2                                                                                        259:2    0    4G  0 part  
└─nvme0n1p3                                                                                        259:3    0  1.9T  0 part
6

@niel234 that would have been created by the installer for /boot/efi but not used…

I use flatpak --user install and add the repo via;

flatpak --user remote-add --if-not-exists --subset=verified flathub-verified \
        https://flathub.org/repo/flathub.flatpakrepo
7

@malcolmlewis Upon closer inspection, this appears to be the EFI directory of the previous system, which the installer did not clean up, since it is actually labeled as kubuntu_boot, and contains images which correspond to the kernel version I was running.

I’ve only done basic manual partitioning before, so would it be possible to merge the 300 MB EFI partition with this unused one to create a single EFI partition with a proper amount of space?

Ah, I did not use --user, so that’s probably why, though on Ubuntu (and Arch) this appeared to be the default.

8

In addition to the answer above, you could also add your user to the wheel group to avoid flatpak command asking for a password.

While Tumbleweed doesn’t put the user in wheel group by default, the package system-group-wheel typically gets installed as a recommended dependency. If the group is not available on your system you have to install the package manually.

1 Like
9

This may be of interest to you.

1 Like
10

Cheers, though I am familiar with the issues regarding Flatpak’s sandbox, so much so that I lost count on how many times I’ve gone into Flatseal and removed the filesystem=host permission, and replaced it with something more sane like xdg-download :sweat_smile:

I’m not sure why there is a permission toggle which allows full filesystem access at all, considering how few programs would need such broad permissions, and those that do would likely be better off being installed as system packages anyway.

1 Like
11

After examining the partitioning issue I described earlier again, it seems that I am currently unable to upgrade my kernel due to the lack of space on the EFI partition.
I noticed the same error message I encountered during the installation, about being unable to install new kernels, during a zypper dup recently.

When I examined my installed packages, I found that the 6.17.8 kernel is listed as installed, but the GRUB entry and uname -r return only the 6.17.7 version.
So it appears that I need to do some re-partitioning to avoid eventual system breakage due to partial upgrades.

At this point I need to find out whether I can safely delete the kubuntu_boot partition which was apparently left over from my previous system, and expand the EFI partition to take up its space.
Also, I need to find out whether I can do this on my running system, or whether I need a live environment to do so, since YaST warns about editing partitions which are currently in use.

12

@niel234 since it’s a fresh install, I would suggest start again, a learning experiment :wink:

Almost all of my setups are 4GB type ef00 for /boot/efi, then / rest of device… most of my systems just run 128GB devices. Primary desktop is ext4, rest of them all run btrfs.

13

Since I had not expected the system to be in a partially broken state, and had already moved my files onto the new Tumbleweed installation, I initially tried to save myself the need to re-install Tumbleweed.
I booted up a live system, deleted partition 2, and grew the EFI partition to take its place, but while the system did boot, any subsequent updates through zypper would cause an error with LUKS verify during boot, which would cause the system to fail to boot and shut down instead.
After trying to re-install the kernel and bootloader through zypper in --force as well as commands like update-bootloader --install, I couldn’t find any success, so had to re-install.

During re-install, the guided partitioner made some seemingly more sensible decisions, like re-using the now 4GiB sized EFI partition, so I went ahead with that suggestion, only to find that it chose not to format the partition, and all previous boot entries were still present.
So I had to re-install a third time, during which it initially didn’t want to let me manually partition the drive at all, claiming it was in use, which I was eventually able to address by telling it to start from the existing partition scheme, rather than the one suggested by the installer’s partitioner.

This time, it finally worked, the installation didn’t throw any errors and the system booted, and also updated to the newest kernel without issue.

Conclusion

This has been by far the worst experience I ever had with any Linux installer.
The only one that came remotely close was when Arco Linux’s installer left me with an unbootable system after I tried to install it inside a VM, but this was still far less egregious, since I knew the system was broken straight away, unlike in this case of Tumbleweed, where I only found out after I had moved my files back, which caused me about a day’s worth of work to fix.

Based on a video by Nick from The Linux Experiment, this is not the first time this installer caused major issues either, as in the case of his 2023 review OpenSUSE Tumbleweed made me reconsider rolling release distros!, he too ended up with a broken system, and was only able to address it after manually partitioning his drive.
He too remarked that this was a rather exceptional thing to happen to him.

If it breaks again, I won’t be installing it again, since Tumbleweed’s installer has convinced me that it is in fact a Kobayashi Maru test - i.e. a no-win scenario.

14

How did you install Tumbleweed?

A few days ago I switched my wife’s machine to Tumbleweed using an DVD ISO that I downloaded on October 31, 2025.

She has a previous install of Mageia 9 using a 300 MB EFI partition and Grub2-efi, not Grub-BLS. I used Mageia to make the ext4 home and root partitions for TW in the free space on her NVMe SSD before installing.

Everything installed perfectly and it’s updating without any problems. It’s now dual bootable with Mageia and Tumbleweed grub2-efi.

I’ve seen users having problems with grub2-BLS due to the size of the EFI partition. I read a post on the mailing list that said they changed the default bootloader to grub2-BLS. It also explains how to switch to grub2-efi during install.

TW default bootloader

That’s why I used the October ISO instead of downloading a newer ISO. I didn’t want to have to figure anything out while installing on her machine. I needed her machine working without problems. She’s not a technical type of Linux user. She just wants it to work and I install the tools that I may need to work on it if there’s any problems in the future. I’ll be switching her over to Slowroll.

I have a 1TB NVMe in my machine that I’m going to clone to a 2TB and enlarge the EFI partition along the way. I should end up being able to boot Tumbleweed and Mageia using the cloned OS partitions from the 1TB drive and have a larger EFI partition.

This is my standard practice when upgrading SSD drives. I use a USB NVMe enclosure and clone using Mageia, then swap the SSD’s. You can’t clone mounted partitions so a second OS is very handy. You can also use various bootable DVD 's or a live OS on a USB drive.

You can’t just put the 2TB SSD in the machine with the 1TB because they have the same partition ID’s, but you can put the 1TB in a laptop and have a clone of your desktop OS that’s already set up the way you like it. You can also change the partition ID’s on either the 1TB or the 2TB and use both in the same machine, but that’s a little tricky.

You can also delete your swap partition to free up space to enlarge the EFI, then reduce the size of your home partition to free up space to create a new swap partition. You’ll have to move your partitions to the end of the drive to have the free space available next to the EFI.

I still put my swap between the root and home partitions as was standard practice with conventional hard drives. It was supposed to speed up your swap because the head wouldn’t have to move so far. It really doesn’t matter with direct access SSD’s, but you need your free space to be next to the EFI so you can enlarge the EFI.

I believe you could’ve enlarged your EFI partition by any of these methods, but nothing beats getting it correct the first time which can be done at install time.

Grub2-bls is new to me, too. I don’t think you’d have had this problem using a slightly older TW ISO, and there are ways to fix it, but since it’s a new install, I’d just do it over as Malcolm said. You’ll learn something and be able to help others get it right.

Finally, with BLS being new, the installer needs to make the boot partition larger when using BLS, and give the user information about BLS and the boot partition size so they don’t make it smaller, but can make it even larger if they want.

With the size of drives today, Malcolm’s suggestion of 4GB seems reasonable so users can avoid problems in the future.

1 Like
15

@jsmith64 I installed Tumbleweed using the regular offline image from the download page, which was labeled Snapshot20251114.
Since I’m not familiar with disk or partition cloning, I simply transferred my home directory using a graphical file manager after installing.

Prior to Malcom mentioning it, I had not heard of grub2-BLS, and I am unfamiliar with how it differs from a normal grub2 bootloader.

After re-installing Tumbleweed, I did try out Slowroll as well using the migration tool, but when I tried to install NVIDIA graphics drivers, they wouldn’t work upon a reboot.
It may be that these drivers only work with certain kernels, since zypper did install some older ones during zypper install-new-recommends, but those appeared only inconsistently in the boot menu, and never as the default.

Eventually, I used the migration tool again to return to Tumbleweed, after which I found that the old NVIDIA drivers were inconsistently removed, and were causing package conflicts.
Though after removing the offending NVIDIA packages manually, I was able to install the NVIDIA drivers fine for Tumbleweed.
The only “issue” that remains as far as I can tell is that my splash screen on boot is still branded as Slowroll rather than Tumbleweed.

16

I figured you were fairly new to Linux, or at least new to getting under the hood. It does take time to learn things and then we get those new curve balls like grub2-BLS. I hadn’t heard of BLS until recently.

I found this while researching systemd boot a few months ago. BLS means “Boot Loader Specification”.

The Boot Loader Specification

First it says:

On disks with GPT (GUID Partition Table)

The EFI System Partition (ESP for short) — a partition with a GPT type GUID of c12a7328-f81f-11d2-ba4b-00a0c93ec93b — may be used as one of two locations for boot loader menu entries.

Then it talks about the XBOOTLDR partition. It sure looks like a way to create a new boot partition that is large enough.

  • Optionally, an Extended Boot Loader Partition (XBOOTLDR partition for short) — a partition with GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 — may be used as the second of two locations for boot loader menu entries. This partition must be located on the same disk as the ESP.

Each partition type mentioned above can be present only once on the same disk.

I think it means that you can have an EFI and a XBOOTLDR partition.
It says each type can only be used once, not just one of one type. If that’s the case then you could’ve fixed yours with XBOOTLDR, if you had a little space anywhere on the drive.

I need an old pro to chime in and tell us if the XBOOTLDR partition can be used to extend the EFI partition in TW. Surly it can, but maybe openSUSE hasn’t implemented that part yet. It looks like it should since it’s part of the BLS specification.

I’m still going to clone my SSD and enlarge my EFI partition. I posted the cloning info for you and others so you’d know about it. If you don’t know then you can’t research and learn to do it. It’s pretty easy but you must learn and follow the instructions. If you’re doing an SSD upgrade (or swap) on a running system, then that’s the perfect chance to enlarge your EFI partition.

Actually, using the XBOOTLDR partition may be easier than all of the work to move and resize partitions, but I think I want just one boot partition to worry about. The good news in all of this is that it’ll be better than grub2-efi in the end. You’re wanting FDE (Full Disk Encryption) and I think that’s one of the main reasons for switching to BLS.

Tumbleweed is a great rolling distro and we get the newest stuff pretty fast. I think Fedora has had this for a while though. I read a lot about it from Fedora users, but then went and read the specifications for myself because it made it easier to understand what they were talking about. That’s what happened here. You jumped onboard just as they changed to BLS and problems followed.

Again, we need an old pro (someone who has actually used it a few times) to chime in and tell us if the XBOOTLDR partition can be used to extend the EFI partition in Tumbleweed when the EFI is too small.

Hang in there and here’s a good piece of advice. If you’re fairly new, wait a day or two before upgrading TW and look at the forum first. If there’s a big problem it’ll be posted. This summer an NVIDIA packager was on vacation and there was a mis-match in the version numbers of the NVIDA packages. I think that affected other distros too, but you’d have found the warning on the TW forum right away.

17

It is supported neither by grub2-bls nor by sdbootutil.

1 Like
18

I never complain about suggestions made by the installer. Try Agama:

“The starting point at the Agama interface is pretty simple, you can choose the disk to install into and decide what to do in order to find space for the new system in that disk, like deleting or shrinking the current partitions.”

https://agama-project.github.io/docs/overview/webui#storage

1 Like