-----BEGIN PGP SIGNED MESSAGE-----
(FYI, it looks like you forgot to CC the mailing list)
On Sat, Jun 11, 2022 at 10:45:44AM +0200, haaber wrote:
> Dear Marie,
> > > > Which kernel version do you need to hold? You can update a subset of
> > > > packages by giving them as arguments to qubes-dom0-update, but I would
> > > > like to know what the forseeable problems are.
> > > The reason is simple: all (!) 5.x xen kernels I tested so far
> > > crash/freeze my system in less than 5 minutes, often only seconds (open
> > > issue on github since 18 months). Therefore I keep a 4.19 kernel for xen
> > > (only) -- until now the updater respected that: it installed some new
> > > 5.x kernel and kernel-latest. Every single time, I bravely try them out,
> > > and each time they crash: each time I can revert back to 4.19 by a
> > > linux-life usb hack.
> > > Last kernel update wants to remove my 4.19 kernel, and no way I can
> > > accept that, given the history. ( again a curse on Intel and Dell for
> > > their buggy hardware ).
> > Try removing one of the newer kernels on your system.
> That did not help. But I could use the output and manually install all
> the lines qubes-update suggests, but not remove the old-kernel.
> qubes-update did download them all. I would have to make sure not to
> introduce a security flaw (not checking signatures), and invoking maybe
> dnf directly with the correct full package name?: the (terminal
> qubes-update) line
qubes-dom0-update unpacks the packages in a temporary directory. They
are then copied to an anonymous temporary file in the final directory by
rpmcanon, and only linked into the filesystem if rpmcanon verifies the
signature successfully. The signature is then checked *again* by
rpmkeys before you even get the “Is this ok [y/N]” prompt.
In short, no, you will not introduce a security flaw doing this.
> microcode_ctl.x86_64 2.1-35.qubes1.fc25 qubes-dom0-cached
> would have to become one word, but I do not know the "linking char": a
> dot? like
> or underscore? like
You need to move the architecture to the end, and then use a dash to
join the name and epoch/version. In your example, you would run
$ sudo dnf upgrade microcode_ctl-2.1-35.qubes1.fc32.x86_64
> But I am unsure if that is a "safe way" to go ....
> > Also, would you
> > be willing to try disabling panic_on_oops? That won’t fix the bug, but
> > it has a chance of leaving the system running afterwards. Adding
> > kernel.panic_on_oops=0 and kernel.panic_on_warn=0 to /etc/sysctl.conf
> > should do the trick.
> I'll try that, of course. I'll keep you informed ...
That would be great.
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----