Fedora 33(fedoramagazine.org)
fedoramagazine.org
Fedora 33
https://fedoramagazine.org/announcing-fedora-33/
57 comments
Just spent 24 hours grappling with docker issues on fedora 32. In the midst of these issues my OS prompts me to download F33 and I see the migration to btrfs.
I no longer trust the Fedora maintainers.
I no longer trust the Fedora maintainers.
Sounds like you should be running Red Hat, not Fedora. RHEL has a 10 year support cycle, so you can wait for technologies to mature before you migrate to them.
btrfs is well over 10 years old and RHEL ditched support for it. My experience with it has not been positive.
As Fedora is the testing distro for RedHat Enterprise Linux, I’m guessing they are planning to use BTRFS in upcoming versions.
I wouldn't read that much into it. While a lot of Fedora people also work at Red Hat, Fedora really is a community project. It's quite possible that the community voted to use btrfs as the default file system, even though support is not planned for RHEL.
That said the RHEL people will be paying attention. If btrfs proves successful, I could totally see it going into RHEL 9.
Disclaimer: I work for Red Hat but not on Fedora. I'm just a happy Fedora community member for a little over 10 years now
That said the RHEL people will be paying attention. If btrfs proves successful, I could totally see it going into RHEL 9.
Disclaimer: I work for Red Hat but not on Fedora. I'm just a happy Fedora community member for a little over 10 years now
Note that your existing system will not be migrated to BTRFS.
I'm sorry to lose your trust. I think that comes from a misunderstanding about expectations. We want to provide a functional, usable system -- but we also are going to change things in new releases, and while we do weigh user impact, we're tilted towards bringing upstream innovation to users. That means we're likely to bring you things like cgroupsv2 sooner rather than later.
If you have these expectations, I hope we're holding to them pretty well. See our mission and foundations page at https://docs.fedoraproject.org/en-US/project/, and hopefully that will make things more clear.
I'm sorry to lose your trust. I think that comes from a misunderstanding about expectations. We want to provide a functional, usable system -- but we also are going to change things in new releases, and while we do weigh user impact, we're tilted towards bringing upstream innovation to users. That means we're likely to bring you things like cgroupsv2 sooner rather than later.
If you have these expectations, I hope we're holding to them pretty well. See our mission and foundations page at https://docs.fedoraproject.org/en-US/project/, and hopefully that will make things more clear.
What's the reason for no release/ETA?
As an alternative, Podman works well, but some features may be missing. It does, however, allow running containers rootless and remove the need for a daemon.
https://podman.io
https://podman.io
I've made the switch entirely over to podman and haven't actually found any features to be missing besides docker-compose support, but their k8s style pods more or less have solved that for me.
There is only one 'gotcha' that I've hit, when building images specifically for AWS's ECR or Docker Hub, you need to add the flag `--format=docker` to your build step. Quay and a few others don't have this issue.
There is only one 'gotcha' that I've hit, when building images specifically for AWS's ECR or Docker Hub, you need to add the flag `--format=docker` to your build step. Quay and a few others don't have this issue.
There is podman-compose, but it is most definitely missing features vs. docker-compose (as in whole subcommands are absent). I cannot remember what (if any) missing podman features remain, but I do run into occasional bugs and regressions with certain functionality.
Curious you mention needing `--format=docker`; I’ve pushed images to Docker Hub without doing that without issue.
https://github.com/containers/podman-compose
Curious you mention needing `--format=docker`; I’ve pushed images to Docker Hub without doing that without issue.
https://github.com/containers/podman-compose
You'll be able to successfully push the images without it. Tags you pushed won't properly show up in docker hub and clients will have issues pulling not just the tags but the layers.
It's been a hot minute since I hit that issue, but I kind of doubt docker hub fixed it. I suspect fixing issues around OCI format images are fairly low priority for them.
It's been a hot minute since I hit that issue, but I kind of doubt docker hub fixed it. I suspect fixing issues around OCI format images are fairly low priority for them.
I have to add to this that I gave cgroupsv2 an honest chance, still use it on workstations. But on my homelab server I reverted back to cgroupsv1 because 1) Ansible does not yet support podman and 2) podman-compose does not fully support compose. It also confuses compose files with its native pod concept which makes things even more convoluted.
[deleted]
How's box working on 33? Any incompatibility?
Yeah I wish docker would add support. For now I just disable cgroupsv2 via kernel param on my fedora laptop to get docker working.
Used this workaround successfully for Fedora 32 which turned on cgroupsv2 (haven't tested it on 33, but I imagine it works similarly):
https://fedoramagazine.org/docker-and-fedora-32/
One small tweak to the article, for Step 2 I didn't need to use Moby in place of docker as by the time I set things up the `docker-ce` package was available for Fedora 32.
One small tweak to the article, for Step 2 I didn't need to use Moby in place of docker as by the time I set things up the `docker-ce` package was available for Fedora 32.
Yea, but you can enable the old cgroups pretty easily, and then it only require a couple of firewall instructions to get docker working.
Edit: This still works in 33: https://fedoramagazine.org/docker-and-fedora-32/
The only difference between what they have here and what I do is that I install docker-ce from the 31 repo, as the seem to have some SELinux related change in there that doesn't require me to label volumes like installing moby-engine does.
Edit: This still works in 33: https://fedoramagazine.org/docker-and-fedora-32/
The only difference between what they have here and what I do is that I install docker-ce from the 31 repo, as the seem to have some SELinux related change in there that doesn't require me to label volumes like installing moby-engine does.
testing docker-ce repository contains release that support cgroupsv2
Docker was broken on Fedora 32 as well.
I switched to Podman, which comes by default with Fedora, no issues so far.
Kudos, guys!
Time to wait three months for all the kinks to be worked out, though.
Time to wait three months for all the kinks to be worked out, though.
Fedora QA has gotten a ton better in the last years. I would use it as my daily driver if work would allow it, we're an all Ubuntu shop (at least for Linux devices).
I run a fully virtualized configuration and I frequently have encountered issues related to the virt stack during the initial months of new version cuts ever since switching to a virt configuration in 2016.
There has also been a ton of improvement, too. So kudos to Fedora, and kudos to everyone out there maintaining those libraries!
There has also been a ton of improvement, too. So kudos to Fedora, and kudos to everyone out there maintaining those libraries!
Hmm, bummer then. Best to wait a bit before upgrading.
It is good to wait a few weeks at least but I have been running fedora the last few years and the last 2-3 fedora releases have been stellar. I have upgraded within a few days of release and had zero issues (with fedora 33 I upgraded last eve :) ). It has gotten much much better...
Congrats to Fedora team!
Thinkpad carbon X1 6th gen
Congrats to Fedora team!
Thinkpad carbon X1 6th gen
This appears to be a solid release, just as stable as 32 for me.
As a long time nano user, this makes me happy!
"To make the default Fedora experience better, we’ve set nano as the default editor. nano is a friendly editor for new users. Those of you who want the power of editors like vi can, of course, set your own default."
I can only imagine the mailing list discussion around that one :-)
Looking forward to upgrading as Fedora remains my daily driver, so thank you at all involved.
"To make the default Fedora experience better, we’ve set nano as the default editor. nano is a friendly editor for new users. Those of you who want the power of editors like vi can, of course, set your own default."
I can only imagine the mailing list discussion around that one :-)
Looking forward to upgrading as Fedora remains my daily driver, so thank you at all involved.
As someone who used nano in the late 90s, it makes me nervous. I recall that you had to be careful to always use "nano -w" otherwise it would silently corrupt long lines, breaking configuration files which use one entry per line (like crontabs). Since then, I have always removed nano from every system I touch, to prevent accidents.
> I can only imagine the mailing list discussion around that one :-)
Here it is [1].
This was actually discussed on HN a few months ago as well [2]. I've used Linux for 20 years and still use nano for all quick config file edits. It's part of my setup so I didn't even realize that it wasn't set at all by default.
[1]: https://lists.fedoraproject.org/archives/list/[email protected]...
[2]: https://news.ycombinator.com/item?id=23818199
Here it is [1].
This was actually discussed on HN a few months ago as well [2]. I've used Linux for 20 years and still use nano for all quick config file edits. It's part of my setup so I didn't even realize that it wasn't set at all by default.
[1]: https://lists.fedoraproject.org/archives/list/[email protected]...
[2]: https://news.ycombinator.com/item?id=23818199
Even as a vim/neovim user for the best part of twenty years I think nano being the default is a good idea. Attracting new users to the shiny world of desktop linux, only to put them off by getting 'trapped' in vim is a pointless exercise.
This crowd will probably be more interested in https://fedoraproject.org/wiki/Releases/33/ChangeSet which has all the good stuff.
* btrfs is the default desktop fs
* Java 11 is the default.
* ifcfg scripts won’t work by default anymore in favor of NM keyfiles
* systemd-resolved is used by default
* earlyoom used by default on desktops
* disabled automatic Python bytecompilation
* xorg-utils is retired
* btrfs is the default desktop fs
* Java 11 is the default.
* ifcfg scripts won’t work by default anymore in favor of NM keyfiles
* systemd-resolved is used by default
* earlyoom used by default on desktops
* disabled automatic Python bytecompilation
* xorg-utils is retired
it seems weird that you can't easily find the kernel version on any of these release/change notes
For Fedora, the kernel version is always "the latest with a lag of a couple of weeks". All the currently supported Fedora releases update to the same kernel version at the same time; currently, both Fedora 32 and Fedora 33 (and Fedora 31 if you're still using it) are using kernel 5.8, and when Fedora 33 updates to kernel 5.9, Fedora 32 will update to kernel 5.9 too.
This is exciting!
Although I'm worried about BTRFS being their new default. I've had horrendous experiences with it and I wouldn't recommend it!
I hope it has improved and requires to be less hands-on otherwise it's a massive turn-off
Although I'm worried about BTRFS being their new default. I've had horrendous experiences with it and I wouldn't recommend it!
I hope it has improved and requires to be less hands-on otherwise it's a massive turn-off
BTRFS is the one change that makes me most excited.
It has improved a lot, I am sorry they default to it only for workstations and not for servers, too. Hope to see it back in RHEL!
It has improved a lot, I am sorry they default to it only for workstations and not for servers, too. Hope to see it back in RHEL!
Btrfs is notoriously ill-adapted to database workloads. Although interestingly, some people seem to run Postgres on ZFS just fine, even without disabling copy-on-write like one is advised to do for btrfs.
A lot of it comes down to the default settings. ZFS is just well tuned for a workload like that, and I believe automatically detects some features of the disk it's on. BTRFS by comparison is worse off by default, but if you tune it right it runs pretty much the same.
Indeed, even OpenSuse disables checksumming etc on /var.
It certainly has improved.
Don't worry though, you can still select another filesystem at install time.
Don't worry though, you can still select another filesystem at install time.
I've always thought Jolla's biggest mistake with Sailfish OS was using BTRFS as the default on a mobile operating system. (They later switched back to more conventional file systems.)
It certainly was (not opening up their code is close second) - the outdated ~2013 era BTRFS on a small 16 GB slow eemc flash & default allocation policy (that resulted in space for metadata running out after s while) turned out to be very very bad.
Thankfully on all supported hardware post Jolla 1 they switched to EXT4 on LVM and had no storage issues at all since then.
Thankfully on all supported hardware post Jolla 1 they switched to EXT4 on LVM and had no storage issues at all since then.
My Synology DS918+ network fileserver uses BTRFS for everything. Knock on wood it has been incredibly reliable and easy to manage.
BTRFS has seen incredible improvement, especially for a workstation type system. I'd probably use ZFS for a system with a bunch of disks I want to mount independently of the OS drive, but that's more a matter of tooling than technical issues. ZFS is just more ergonomic when it comes to managing pools.
Interesting to read about the new ARM64 boards. Does anyone have experience using one of these as a desktop computer?
I've lived off of each main release of the Pi and a few other SBCs. I've stuck to running 32bit releases for the time being because of bad experiences with 64bit issues.
Things are much more livable currently with SBCs largely adopting faster USB, PCIE or EMMC storage.
Even as an ARM enthusiast we are still years away from the average person being happy with the experience so tailor your expectations accordingly.
Things are much more livable currently with SBCs largely adopting faster USB, PCIE or EMMC storage.
Even as an ARM enthusiast we are still years away from the average person being happy with the experience so tailor your expectations accordingly.
Congrats Fedora team! I upgraded last eve on a thinkpad carbon x1 6th gen. Took 15 min and was seemless! My 4th upgrade on this laptop.
I have the same laptop and this is also my fourth upgrade on it. Really excellent.
It is impressive how much the upgrade process has improved over the years. Years ago you could either risk updating your repo files and yum updating, or just do a full reinstall. Then they built fedup which was a command line tool that made it easy, but still required several different commands. Now it’s driven through the GUI and a better experience than macOS upgrades in my opinion.
It is impressive how much the upgrade process has improved over the years. Years ago you could either risk updating your repo files and yum updating, or just do a full reinstall. Then they built fedup which was a command line tool that made it easy, but still required several different commands. Now it’s driven through the GUI and a better experience than macOS upgrades in my opinion.
For the record you can still upgrade from the command line with the DNF system upgrade plugin:
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-u...
Once started the upgrade process is preatty much the same as the GUI update - download all needed packages, check if there are no conflicts with what is already installed, then reboot to minimalistic systemd target and run the update here.
Doing it like this makes sure that packaging conflicts, network connectivity or unrelated processes running on the machine can break your system.
Once started the upgrade process is preatty much the same as the GUI update - download all needed packages, check if there are no conflicts with what is already installed, then reboot to minimalistic systemd target and run the update here.
Doing it like this makes sure that packaging conflicts, network connectivity or unrelated processes running on the machine can break your system.
Big concern I've seen is around btrfs being the default. I was concerned too, especially with the old versions losing data, but I've heard that a ton of work has gone into btrfs and it's maturing/stabilizing nicely.
Has anybody used a recent (last couple of years at the most) btrfs as their main filesystem who can comment on how it has been?
Has anybody used a recent (last couple of years at the most) btrfs as their main filesystem who can comment on how it has been?
I am running Btrfs on about a dozen machines (solid state and spinning disks). All of them are servers and run "business-critical" stuff. No issues during the last 2 years, everything flawless.
The ability to scrub your data and have strong data integrity guarantees is just one of the benefits of Btrfs. I'm also using transparent compression (GZIP and ZSTD) and even RAID1 (disk replacement procedure worked flawless last time I had to use it).
For workloads such as MariaDB (heavily updated-in-place files) you may want to go ahead and disable CoW features, though. This leaves you without data checksumming (InnoDB uses it's own checksumming - not losing much there) but you still get a lot of the other great Btrfs features.
The ability to scrub your data and have strong data integrity guarantees is just one of the benefits of Btrfs. I'm also using transparent compression (GZIP and ZSTD) and even RAID1 (disk replacement procedure worked flawless last time I had to use it).
For workloads such as MariaDB (heavily updated-in-place files) you may want to go ahead and disable CoW features, though. This leaves you without data checksumming (InnoDB uses it's own checksumming - not losing much there) but you still get a lot of the other great Btrfs features.
I used to run a couple of hundred servers and workstations with SLES and openSUSE with btrfs for /. Just SUSE's vanilla supported setup, and user data on smb/nfs filers. I tended to forget that btrfs was even involved. I can't remember a single time btrfs gave us any trouble. But snapper snapshots saved a customers ass on one or two occasions.. That was several yeas ago. I also imagine that btrfs has only improved since then.
"... And no longer use swap partitions by default." [1]
Finally! I've installed a 256GB RAM desktop recently, and swap is so 90's...
[1] https://fedoraproject.org/wiki/Releases/33/ChangeSet
Finally! I've installed a 256GB RAM desktop recently, and swap is so 90's...
[1] https://fedoraproject.org/wiki/Releases/33/ChangeSet
Fedora uses cgroupsv2 to push things forward, but no Docker release supports it yet, it's in master[0], but there are no release in sight as there is no ETA.
[0] https://github.com/moby/moby/pull/40174