-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
(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
>
> microcode_ctl.x86_64.2.1-35.qubes1.fc25
>
> or underscore? like
>
> microcode_ctl.x86_64_2.1-35.qubes1.fc25
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 ....
It is.
> > 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.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzgMACgkQsoi1X/+c
IsFILA/+J7K+pc8P60DufMajZscukK6blfOFUd0BCyb9uEWgoVaE/b0K4hXDCVRE
3sud/2qz6arpjZxCdmrNk48/0S2r+lpeAHghhM/osOWNBb/1b4jZdgH2bJemaS5N
KSuoLDCNpqUhKN8kzNP6XiuMZrkvluv2nsRr+w1cbdJREB92PFyJGvkIJfqHQOuE
1lJu39qW/msIJrU1Zki3f9cUsJ9vG9pFVOo98P7Uxa6C9Utu2wP9OZdLNojOMEDc
yXmob1YwbNJYiFW6SN7blCO79Qhgo+WZaSq0CYxDnM7r8C0YJbd64UNOR+F0NuA8
2f9ySzc+kB9HLUqf3iJOaYXLZIbvHUQaSUQaY0zRVrjhg8gt2p3ylTyjQwzsOza0
P/jKclYz+woXJwQr8Pq7CeIvcUM9doinB+u/9NCjDiQiUuJIINrHPbZ9kuQvhDoi
QvMZ5Pm6fp6a6uya+FeNfVSoQ4V2xCYlgfW5cD0noyldrzqNFrQ9Qz5kCLuMAawS
NVL3OOmzyENSJrLntaZkRnBr2X4H6H0s5C1zBCE47gsoW47R5x/91wuyOAk2r2zO
gi5mFKwSx7in0H8umSwAJ4o2yHsbnesuSSVmTAZW2vIV/TWOSLAMHmpuj1iI6M7w
TGM9ffsUDsEATlEUVdBNBsM4JlVe4Uxh26glzd73v0OI9gOwSQw=
=U8A5
-----END PGP SIGNATURE-----