Fedora 24 Users: Don't Run "DNF Update" From The Desktop

[andreano]

Files can have 0 hardlinks → updating running software is allowed by design.

My problem is that restarting X stops working after upgrading both X and the kernel and then NOT rebooting.

[Mystro256]

I don't know what you mean, I've always updated Kernel, running Firefox, running Desktop Enviroment, running GTK, everything. on my distro without any issue.
But Fedora seems to often hit this kind of bugs.

Well the kernel won't do that, but GTK might if you're running Wayland. Honestly, Fedora tends to tread on a lot of less tested waters, so I wouldn't be surprised if it's more prone to these bugs. Often they get fixed before hitting other distros. Arch can be prone to this too in my experience.

[Zan Lynx]

I complained about Gnome Software's ridiculous update policy back when it was new, half expecting something like this. When your official update method becomes a reboot, people stop testing other methods.

They claimed fixing live update bugs were too hard. Boo hoo. It's still a bug. Fix it.

[sarfarazahmad]

I never liked DNF. It requires a huge amount of metadata from repositories. If you are on a not-so-good internet connection, dnf takes a long while. Heck even APT now does parallel downloads and doesnt download 50MB+ of metadata from its default repos. Technology should be simple and easy to work with. I appreciate Pacman here , it works well, its commandline switches are easy to remember. With Pacman/Arch, packages are small in size, installation is snappy and maintaining repository configuration is easier.

[finalzone]

Having read AdamW on the mailing list, the issue can be reproduced by running systemctl restart systemd-udev-trigger.service as root on desktop environment especially on hardware powered by hybrid graphic cards. I recently tested on a desktop hardware running on dedicated GPU with no noticeable visual change i.e. no crash.

The bug in question can affect other distributions running on hybrid graphics powering laptop or desktop.

[Steffo]

I will switch to openSUSE Leaf when 42.2 comes out with KDE 5.8 LTS and Linux 4.4 LTS. This version will be rocksolid. And with btrfs and zypper (which makes always a snapshot before installing a package), you can easily undo upgrades. And snapper is an excellent user space btrfs tool.

[finalzone]

I complained about Gnome Software's ridiculous update policy back when it was new, half expecting something like this. When your official update method becomes a reboot, people stop testing other methods.

They claimed fixing live update bugs were too hard. Boo hoo. It's still a bug. Fix it.

On topic, here is the details of the bug:

https://lists.fedoraproject.org/archives/list/[email protected]/message/SPHOP6ULMNV3IFRAFENLNCDKWXH2EFQ3/

It is likely the issue is hardware related.

[Chewi]

Guys, a little less hate please. I'm principally a Gentoo user (and developer) but I use Fedora at work and while I don't tinker with it as much as my Gentoo system, it works far better than many of its detractors would suggest. I use XFCE and haven't seen this issue but I think my colleague, who uses KDE, may have done as he mentioned something that sounds a bit like this. But hey, bugs happen. I'm sure they'll fix it.

[finalzone]

I don't know what you mean, I've always updated Kernel, running Firefox, running Desktop Enviroment, running GTK, everything. on my distro without any issue.
But Fedora seems to often hit this kind of bugs.

He means running with any package manager on any distribution will likely have similar bug on specific hardware. I have recently reproduced the issue on a hybrid graphics card powered laptop to trigger the crash while normal hardware are unaffected.

[AdamW]

Michael, could you update the story with more concrete details from https://www.happyassassin.net/2016/1...-is-in-update/ , please? Thanks. Testing seems to quite solidly indicate the issue affects systems with multiple graphics adapters (most commonly, 'hybrid graphics' laptops) when updating systemd-udev .

For the record:

1. This isn't any kind of a bug in dnf. DNF just does what it's supposed to.
2. There are kinda two bugs. One, when the systemd-udev-trigger service is restarted, it results in a 'replug' of the graphics hardware, which isn't intended and probably shouldn't happen. Two, when that happens, on (most? we have one report of an unaffected system) systems with multiple graphics adapters, X crashes. On systems with a single graphics adapter, it doesn't.
3. It's *never* a good idea to run a traditional package-based update (whether deb or rpm) from within a graphical desktop, and we've *always* advised against doing that. It's a fundamentally unsafe operation. If *anything* happens to cause either the terminal app, the desktop, or X itself to crash at any point during the update, the update process will *inevitably* also die, leaving the update half-completed and your system most likely inconsistent. Traditional *nix package managers never operate atomically and so this is just a systemic issue. It's *always* best to use offline updates, or at least update from a VT.