On Thu, 2019-10-24 at 11:07 -0700, Samuel Sieb wrote:
On 10/24/19 10:53 AM, Felix Miata wrote:
> Samuel Sieb composed on 2019-10-24 08:15 (UTC-0700):
>
> > Felix Miata wrote:
> > > This has been rather routine here in recent weeks trying to system-upgrade
to f31
> > > from a freshly upgraded f30. This is with/without allowerasing and/or best
and/or
> > > skip-broken options. Does it happen to others? Is there a known
workaround? Is
> > > there a way to get dnf to report what's trying to cause kernel and/or
systemd
> > > removal? The only workaround I've found is to not exclude kernel*,
which used to
> > > be an easy way to gain some freespace back from filling / with 100% of
rpms
> > > downloaded in advance. With a fresh new kernel, there's no rush to
have a nearly
> > > identical kernel available right away. On my systems, it won't get
used on first
> > > post-upgrade boot anyway (booting the symlink to the most recent kernel,
which the
> > > upgrade doesn't touch).
>
> > You need to include the command you're running and the output from dnf
> > for this to be useful.
>
> $SUBJECT is the output.
No, it's not. dnf prints out a lot more than that and to find out
what's happening, we need to see it.
I mean, excluding the kernel from the transaction is already kinda out
of bounds. Just don't do that. :P
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net