begin with? Reply-To:
Forwarded thread from the users' list below. In the normal case, since we ask people to do a `dnf upgrade` before `dnf system-upgrade`, there will almost always been at least the release-day kernel and an updated one of the older release installed. Is the case where there's just one running kernel installed tested? What *would* happen in this case?
----- Forwarded message from Andras Simon szajmi@gmail.com -----
Date: Thu, 24 Nov 2016 08:33:35 +0100 From: Andras Simon szajmi@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: dnf system-upgrades wants to remove the running kernel
2016-11-24 1:42 GMT+01:00, Jon LaBadie jonfu@jgcomp.com:
On Wed, Nov 23, 2016 at 10:25:30PM +0100, Andras Simon wrote:
2016-11-23 21:30 GMT+01:00, Matthew Miller mattdm@fedoraproject.org:
On Wed, Nov 23, 2016 at 09:20:23PM +0100, Andras Simon wrote:
The same: it wants to remove that old kernel. But after booting again the latest kernel and starting the upgrade, dnf wanted to erase the old kernel, not the newest, running one. So I let it. Now I'm sitting here with fingers crossed...
Keep in mind that it's gonna reboot to do the actual package installation anyway.
Right, so I was wrong: letting dnf remove the only working f23 kernel wouldn't have been risky; it would've led to disaster.
Thanks for pointing this out!
What about temporarily increasing the number of retained kernels. I think the parameter is in /etc/dnf/dnf.conf, "installonly_limit=3".
Raise it to say 6 so it will not deleted the currently running kernel. Later return it to default 3 or whatever you want.
It's too late now because the upgrade has already succeded (though I may run into these issues again when I go to F25 or upgrade other laptops) but this problem came up even when I had only one kernel installed with installonly_limit=3.
Andras _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
----- End forwarded message -----
On Thu, 2016-11-24 at 12:23 -0500, Matthew Miller wrote:
begin with?
Reply-To:
Forwarded thread from the users' list below. In the normal case, since we ask people to do a `dnf upgrade` before `dnf system-upgrade`, there will almost always been at least the release-day kernel and an updated one of the older release installed. Is the case where there's just one running kernel installed tested? What *would* happen in this case?
I think in at least most and probably all cases, the automated tests wind up with more than one kernel installed before the upgrade operation.
I'm rather confused by the thread you're replying to, though. I don't see how any of it makes an awful lot of sense. If the case is starting from a single installed kernel, how is increasing the 'installonly_limit' going to change anything? And if dnf didn't want to remove the kernel that the user was at the time of running (I assume) `dnf system-upgrade download` using successfully, how exactly would letting it remove an older(?) kernel have 'led to disaster'? Did you remove some important earlier context?
dnf is supposed to have a protection which prevents it removing the currently-running kernel. If that's somehow being omitted for system- upgrade, that's certainly a bug.
On Thu, Nov 24, 2016 at 09:44:31AM -0800, Adam Williamson wrote:
I'm rather confused by the thread you're replying to, though. I don't see how any of it makes an awful lot of sense. If the case is starting from a single installed kernel, how is increasing the 'installonly_limit' going to change anything? And if dnf didn't want to remove the kernel that the user was at the time of running (I assume) `dnf system-upgrade download` using successfully, how exactly would letting it remove an older(?) kernel have 'led to disaster'? Did you remove some important earlier context?
Full thread for context: https://da.gd/Idg3
There's some other oddity involved, where it's trying to install the *base* (non-updated) kernel from F24 over an updated F23, and then it says those kernels conflict rather than installing them in parallel.
dnf is supposed to have a protection which prevents it removing the currently-running kernel. If that's somehow being omitted for system- upgrade, that's certainly a bug.
That _possibly_ is the case here.
On Thu, 2016-11-24 at 13:23 -0500, Matthew Miller wrote:
On Thu, Nov 24, 2016 at 09:44:31AM -0800, Adam Williamson wrote:
I'm rather confused by the thread you're replying to, though. I don't see how any of it makes an awful lot of sense. If the case is starting from a single installed kernel, how is increasing the 'installonly_limit' going to change anything? And if dnf didn't want to remove the kernel that the user was at the time of running (I assume) `dnf system-upgrade download` using successfully, how exactly would letting it remove an older(?) kernel have 'led to disaster'? Did you remove some important earlier context?
Full thread for context: https://da.gd/Idg3
Oooh. PAE. You shoulda said.
https://bugzilla.redhat.com/show_bug.cgi?id=1333591
It got closed, but I don't think the fix was sent to anything before Rawhide.