Going from Fedora to openSUSE

Hi,

I’ve been using Fedora on my laptop the last couple of years, and are happy with how it works etc. but I’m getting a bit tired of the short lifecycle. I also want to play with a server where the short lifecycle is going to be a pain when I have to do major updates once a year.

I’m thinking of moving to Tumbleweed on my laptop and Leap on my server.
The laptop is GNOME and is mainly for hobby, and the server will be for virtualization (KVM) and backup (rsync); maybe some file sharing later on (Samba).

I started with my server and tried to install Cockpit, which didn’t just work out-of-the-box; needed to manually create a user and group before it worked. In Cockpit the network tab doesn’t work, something about NetworkManager, and I couldn’t find a Samba tab either; in general it doesn’t seem to have all the things that Cockpit in Fedora got?

The reason for using Cockpit is to have an easier way to create VM’s, which I can also do using virt-manager, so I’ll properly just jump to that.

I guess that openSuse uses some other applications to control e.g. networks etc. but what kind of other “surprises” (differences) will I find when moving to openSuse from Fedora - what are the big differences?

Any help appriciated.

Using TW Slowroll here on both my primary and secondary personal machines for almost an year now. Quite stable and I’m happy except for some pitfalls like:

  • Btrfs quota / qgroups enabled by default which trashes the FS over time.
  • SR is not tested like normal TW, so more buggy releases that leak through but SR has much saner update schedules compared to TW, so you have a choice to make here! :wink:

There are some longstanding bugs specific to openSUSE that I’m aware of:

  • Gnome DB and associated libraries
  • Podman network namespaces

I don’t use cockpit, so can’t comment on that, but it’s not surprising the defaults don’t work. With most packages, you’re expected to read the docs and configure it yourself. Installing the package alone won’t make everything just work. :dizzy:

@rofe Hi, adding the user to libvirt group should be enough, on my desktop I run the org.cockpit_project.CockpitClient flatpak for access.

You only need the client for Tumbleweed, Cockpit integration is there, so don’t have to install anything on the system…

For access to remote file systems, I would suggest sshfs over samba it’s it’s just files.

@malcolmlewis What about the network tab - I get an error with NetworkManager. I assume it’s because openSUSE uses something else to manage the network?

I didn’t know about the client; I will try that thanks! :slight_smile:

@pavinjoseph I think I will stick with the out-of-the-box TW. I don’t mind being on a rolling distribution if it’s stable and bugs/errors are rare. Fedora works fine for me in that way.

What do you mean by trashes the FS over time? Does it corrupt the filesystem and can something be done like cleaning it - prevent it from crashing?

@rofe I use NetworkManager, but all good there as well, four bridge devices for VM’s and my local lan, I don’t use a firewall on internal devices…

@pavinjoseph Cockpit will be the default going forward with the slow demise of YaST… Install the client and look, it works OTB if you log in on a localhost… nothing to install except the client…

@rofe I got bored with btrfs, no snapshots running, it never broke… in saying that I had vm’s running on xfs as well. I just recently re-installed (nothing broke, put in a faster NVMe) and just stuck with ext4. I have MicroOS and Aeon running on btrfs with snapshots etc, it runs fine. These are only light weight machines, not much hard work.

Hmm… I tried that on Leap on my server and accessing it through IP-address:9090 but got an error.
I will try a new install and accessing it with the client.

@rofe Not on Leap, but Tumbleweed has the support. All you need on the Leap server is cockpit-bridge and the plugins you want, you don’t need cockpit-ws and then use the local (flatpak) client to connect using ssh.

I know nothing about Cockpit, but I do know a server doesn’t need its network “managed” other than by its own admin. Officially supported, as in controllable via YaST, and I suppose also Cockpit, are only choices NM and Wicked, but outside YaST there is a third choice with roots in upstream - systemd-network, which I use to the exclusion of all other types of network setup since discovering its existence quite some years ago. NIC setup is simple and lives in /etc/systemd/network/. On its installation, I purge everything purporting to manage or control resolv.conf, creating file from scratch, purge any bits of wicked and NM that may have escaped my prohibition, enable systemd-networkd.socket, then either reboot or systemd daemon-reload, same as in Fedora and every other systemd distro I’ve tended on a server.

# rpm -qa | egrep 'd-net|ager'
yast2-services-manager-4.6.1-150600.1.2.noarch
yast2-packager-4.6.9-150600.1.1.x86_64
systemd-network-254.21-150600.4.21.1.x86_64
# systemctl list-unit-files | grep netw | grep enable
systemd-networkd.socket                  enabled         disabled
#

Clean and simple.

@mrmazda it does, the only plug in for Cockpit is for NetworkManager (like YaST Lan module) for Tumbleweed, OP is going to use Leap which still defaults to wicked and will need to switch to that.

Managed is a misnomer vs function… I can add interface, bridges, vpn connections etc and like wicked, it’s just a flat text file for configuration…

1 Like

I use both Fedora KDE and openSUSE TW KDE workstations. Both rpm based of course so that knowledge translates well. GNU/Linux/systemd/rpm/KDE - it is not much different on either distro. I don’t know about GNOME, I would imagine it is even more vanilla than KDE. openSUSE has YaST. I find myself using YaST less and less as KDE is doing more system management these days like setting up printers and stuff.

Honestly the biggest difference I run into is the package availablity. Both distros have most of what I need but not all. You can add 3rd party repos, or do the flatpaks and snaps if you are into that.

Yes, it corrupts the FS beyond repair over time. Solution is to disable btrfs quota / qgroups post installation.
https://bugzilla.suse.com/show_bug.cgi?id=1220912

1 Like

I made a new install and changed the Wicked to NetworkManager during install.
After the install I couldn’t figure out which Cockpit packages to install to get it working with the client, so ended up with the -ws package, but that’s fine - everything works now in Cockpit.
I also had to add the following to /etc/nsswitch.conf to get it working:

passwd:         compat systemd
group:          compat [SUCCESS=merge] systemd
shadow:         compat systemd

Thanks for helping out :slight_smile:

1 Like

Out of curiosity, as I’ve not really looked into this aspect of BTRFS… how does this trash the filesystem over time? What ends up happening?

I’ve never made any explicit changes to my BTRFS setups outside of setting up a few subvolumes for snapshots and adjusting compression.

This is just speculation as I’m not a btrfs dev: I think as btrfs stores the quota info and metadata inside btrees, the faulty quota implementation corrupts the btree itself. Coming from Debian based distros, quota wasn’t enabled by default there and I wasn’t exposed to this bug.

More snapshots you accumulate, more severe the problems. :smiling_face_with_tear:

Well, I was reading this thread for entertainment, but (as almost always) there’s a useful tip :slight_smile:

I use TW on my work laptop. I got saved from reinstalling by a using a BTRFS snapshot a few days ago. My BIOS is blocked so that I can’t reinstall without bothering the guys at internal IT.

Your comment is, thus, worth gold!

Have some virtual :beer: :slight_smile:

1 Like