qubes update -- how to hold an old kernel ??

[haaber]

Recent QSB made me run the qubes-update. Regrettably, it wants to remove
a kernel version that I need to hold (in case of foreseeable problems
with newer ones). How can I freeze that older version and forbid its
uninstall?

best, Bernhard

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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. I am not aware of any
way to do what you want given how DNF works.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKjs1wACgkQsoi1X/+c
IsGmqw//euPsJPLo1LiC4OuzMWuHWgqNS3xtxyCaVbX8FmSlSSWDB1V8iyxSVajp
SDoGY7qU1x9hgEe0PIvrt8DAOG0XnkRcPzzlQv2xkjj0qTn8boFum3LigUQ6/lAr
P7xkc3ELnd+sXAP2Urn1XtmgcMN9oLexUNpQCN2LOaFtvzpCCQpjeVLW9U5dCqN0
dFKtH/iwxGBsMKcizkSnCmExm67lVhG5qD/oSLcvrE1VpR+nw61nLXlKTC1OFG0y
Bue6m+0FNpoRGGnDFOkUktrybLLu1RHmUkBs5Hxyzn16eL8HFx1/o4JqF4RjXgq5
dj17uugo9azVmEX7Z/Ngq9uKnUeC/328sT/7Cu/Zy9op0IdMPTHtZ+wzQwfOjM4w
JpXWxE96a+gXnqPD0Q13nbTwiurvD3vrr5rgv0QqWn6xUa9+SHHyXJQR45nR8YVe
sOGRifKoZgCtcOemF6A6hveFF8fwALb55CIKgGwM6K4Q6FXNMip/FqJl2mwVxXn7
jNYG4qQveRRyzSsGdN1O4yDgTFDC36EZSPOtxKVnYs1VFbXfcCpQW7rKQPDy+S8w
tnykq7Qdvg2lK/uztgDtfs2iEqZJlt1KHN2UrU0cHRF16h/cZQm2L+RBgY6l8tvY
f2QRoBYzof29dj4Ald8JskKvBlo7sQ5tZhXEySB6T4Vq86xIOzU=
=ormh
-----END PGP SIGNATURE-----

[haaber]

> 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 ).

best, Bernhard

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Try removing one of the newer kernels on your system. 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.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmH3JoAACgkQsoi1X/+c
IsGmrA/+MhaHGQotnhmzS0Ipf13o4WunxvFBJb+kzRnbmS8QDpxqYlg0seZ7cxtZ
dCV9CjGjEEK1AfElAl/JOc0NgW0ltz6wAK3nsg9nfZ5bnq4NMpXOJ2L+Nx5qI91O
jqWvQBMnupl6ETpdX6YGsA9lDc4yCbr31L+1y/8euc+CuJja5a5Mn8AaaisjEtFK
fZdyN2PLIGnC+Jp0kUR9PK2p9YT1I8tyDljv/nvW/wTVdTV4ExBv94U4hHNH5ALe
QQ4iQp8eg/1TDcRKTgTPhc3O9rfgyeRTwgPGAIIe8CcX6NngOHfAkURHTJp7BYSx
bYVVULcQheOHx8yiMgE/rXxI2mpWlp8x6xDBVO6bc+BZZOYb6HqQXS6j+iRucpx5
s3NA8Jo8H7KDw1bin+r+LN13evWUwn0fmQJ5Ffq1zmVRuRwc+qT8okVbaubxAgJE
6C47u7Vs6p9sp8m29mBsUPR2Z84F2NXNNAMJNndWUAAzn0FZjgs4j/Al7ZSerhcz
2zrfqNJUD3fRsKFAN4Uf893xT+xTiy1g5+8YNVi45H+B7smykZIlU7NiSNTNyFci
3SGIXbb73v/CLsMg2ysj35FbFP1bqdZXL08jjF95NFf6Y9T09OfWvvaPTskwJkmD
6v/wd8qIdvfEpkh5UQPkWpTXAIql2iDvyVmcyx0usir5dz9GenQ=
=6j7H
-----END PGP SIGNATURE-----

[Peter Palensky]

Same here (Dell XPS13). The only usable dom0 kernels are 4.x and 5.4.88 (already gone :-0) and 5.4.175 (please let me keep that!).

Everything else either crashes dom0 (e.g., 5.15) or stalls sys-usb (e.g. 5.12.).

It says "00:14.0 USB controller problem", might be a usb3.0 problem, tried various things, nothing helped, my BIOS has no option to disable xHCI.

[Demi Marie Obenour]

-----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-----

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jun 11, 2022 at 10:54:39AM +0200, haaber wrote:
> Dear Marie,
>

> > Try removing one of the newer kernels on your system.
>

> lets think it the other way round: if I, say, safe-copy the
> vmlinuz and initramfs-files of my 4.19 kernel, can I just play them back
> to the EFI/qubes folder & modify the xen.cfg "as usual" in case of 5.x
> kernels bugging? As a kind of "very manual install" -- or wouldn't that
> work ??

That would likely leave you without the needed kernel module packages,
which would be bad.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzk8ACgkQsoi1X/+c
IsH2Dw//fAMldDf1ghepx1mz2tBBUz3zij5TwNvYAIhrWRMFDly8I1m9oChRzQh1
taWE60N8Cm9F14DKFQeY469ZgUbjbtRsKcJGjopsokKtRJ8o3sFZQ1fcNm8aTsIh
av8nsL+A86P4YDp3LDeLPn9pxXbDDq78FhDxBgOLKALECxUJMAstkpCIFcEoCC7m
WY30nHop6k+u87nZw4Db8zbEPORmBpcstaUSLPLtkwyHg1m0qLcA3lkuhikU80h0
+rxo42SSYwMxFoeyAHbQ9rhn+nOVnL8osFR4z+LZ4x77cVwTVIIYKYqQE4GnSJkw
XehQ2SLIhQd4E0CZ6NZjZcCHLvkSYepGpxQxn8whxz5LR2VT/KkzOgn9ZykHU5t5
oEuU4+K4PShhlZAIgEmwpo+QMKEY0DENIJL5i94ao8NS28lKHvlPkefOtJh4Q/oI
kuzolBI+wEytm75MdWJXqnVcFsKiqUW2JobnxfV2wnAho6Q4AMYgK6XL4GiB8VyP
1GkncV4SUxzoxUHsxg9N15WTzZu5M6oM0m5szIPGx409CxuK35U0v7vLXVgLSe/P
pr1PHLMwupXvvQnpXWJHoA4NZ0OlOpvb+mg2dIy425+SfG/HZcj/ret2rP28WaYk
a1McpvNYuZHzZc+Vf0/Ulz1YV5+quWA8MxKhnKE0fdgdFabGgdI=
=SZac
-----END PGP SIGNATURE-----

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I am hesitant to ask, since it would require running unsigned code
(yuck!), but would you be comfortable doing a kernel git bisection?
That would allow figuring out exactly which commit caused the problem,
and would vastly improve the likelihood of the bug being fixed.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzwoACgkQsoi1X/+c
IsH4GBAAjTkR270uIN2dukR91U3Ed/c6SYkY3VDiIcyACBg4eYSnKp15U64sfqcX
tormUiDo5EJgVJmMn5//XovQh6HhKC0NxDz29Gt3bVMTaUXKhxZsTYNdq0gaNxWZ
soYVwIW0e5+qXnu5vMytl2mLJaFKo+an1o4KxooF89D8IDHjY1hThOKOB8REPsEu
sOY1xal74dxJVNiWivJaHd0Unru41Of6oegFZQVqZ2fty7NJiSPBdu6GB591rBBH
jbce2YfwR5R4nllpvx3lKHZxxLfwvTHYbz3BxLpMvdof2IheE2+cxv2vstTT6ykV
t9SYnApBT3ytddgypa6iOsmhlccCJ/h+TZEvJN+1/HNBTRzZcSE2c4Fv9+OxTa03
NK2wrIDYRa6LeZHe6RJU8ykeJB+m1Ojap+N2J1nhlC+/5C/bUhPvDScwfXbrP9pJ
JyGAvuonGXagBY6vjg2tSMM4eeNpetHURHm5iuufVsarlAUg/IQkzERhnWY2saov
DB1hmouC0aKf8O5riLKmudQWNGl+CY7VCMAJu97GHBBPN8edSEhSg5jXoRA4JRrV
+5nPf8VQfgry+IEsSeSqWedcU6CJ0Q14j2LxsklrqANS7pTrh9eGQFLPALptiWTM
7Zl6ODTqqTZyv/XQCnrg34LUEH08tiubr7lN3BLfNfiX+Wx+3g0=
=S7ZL
-----END PGP SIGNATURE-----

[Peter Palensky]

Aaehm... It is my work computer, i need it every day and  can not risk anything...

Is there a safe/standard procedure in qubes to compile the bisects, add them to grub without removing the working kernel, etc.?

[unman]

On Fri, Jun 10, 2022 at 08:55:41AM +0200, haaber wrote:

Hi Bernhard

There are a number of things you can do: the simplest -
Increase the number of kernel packages that are retained:
In /etc/dnf/dnf.conf change installonly_limit=3 to some higher number.
Then manually delete kernel packages that are intermediate.
That way you keep the working version *and* get the updates so you can
try them as they come in.

There used to be a plugin to lock dnf updates to a specific version, but
I think that disappeared a few years ago.

You can try `dnf mark install kernel-VERSION` which *should* hold that
package version on the system, but that hasn't always worked for me.

There is another simple approach - run the update while booted in to the
kernel you want to hold. dnf wont remove the running kernel, and will
uninstall newer versions to stay within the installonly_limit you have
set.

Some combination of these should allow you to hold (some) older kernel
version while still allowing you to try updated kernels.

unman

[haaber]

On 6/11/22 08:55, Demi Marie Obenour wrote:
> Adding kernel.panic_on_oops=0 and kernel.panic_on_warn=0 to /etc/sysctl.conf
> should do the trick.

I did that. The 5.16.18 kernel freezes, as all 5.x ones, but here is a
funny detail: I froze on login, and I just kept typing the password and
hit enter.Nothing happened. So I forced a cold boot. BUT: the journal
contains the line

Jun 12 21:27:49 dom0 runuser[3526]: pam_unix(runuser:session): session
opened for user USER by (uid=0)

and some other lines. Which means that the pwd was recognised and
accepted - and only the screen freezes. Which brings the suspecions
closed to the f*cked up intel graphics card. Alone, using modesetting
driver does not save 5.x kernels. So it is more complicated than that.

Bernhard

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Not that I am aware of, sadly. Marek (CCd) might have suggestions.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKmVR4ACgkQsoi1X/+c
IsF58Q/+JzZexj7w/tQodLlJ4WrELfqVZ7eODyqX+4oJmh7YzzABkDJBgB9+z5p4
Ucftj7MyCjb9sYBrE2Lj9BDjw/uNQXhwL/eOakLScSdHwoO5q4xMsGiCsEheZ7jP
G6bOGpF5LPlNegDJR2bXpgKg+snbQ0MAAXydBp1WtWs+GF8oKUl/WSFxLZiPK2/v
tDmGECM0Uw0hNd5P4SD1Pz9P78A6U5mK5mW4bHVDyCQM2hTmIweR7iCBi4K8C0Jf
toH1eC6YG5LMFfNApltYk3yZrvbUYOkfOE8T94txgW9xJuLWOAqxu1mTgZTp1VNb
BKMzYClPJQYti4vd61I/E06Pc321SxsmbFh3gCywOPCLrIRyFD/8zKuw7p3cDOtB
B37MYk/JeFhl3tyTIHfTqIF+FbhL+EVkEvkM4jvMWEA3BiPhQif1dLXexCwDoh/S
yeHPWzq1ISI5oMZeepNlfQJYhcUZn3qCYWYkbO3lp+FD5V1RbWV9TijSb1R8OsUP
SwdTXO/xXVriSiTucuNg30r/4gzZxjPcHXHM8+f0Z8+wUauRr6zG6ijdxCipg4b/
sdw3Jqxxk1abxWJeUk1/asBxwm0PpWlCQJAws+rqrt43kOGwhRW23+KXou6bkMZ9
NMvJ8KMlQp3fbBmGRk/2Dy80n+Car+EeI1JJL5SXVbrkek8r4JM=
=+YEO
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

There are a couple more options to choose from - for LTS kernels we keep
some of them updated, even after the default is switched to the next
one. For R4.0 there is for example kernel-419. You can check available
options via `qubes-dom0-update --action=search kernel`.

> > > > Everything else either crashes dom0 (e.g., 5.15) or stalls sys-usb (e.g.
> > > > 5.12.).
> > > >
> > > > It says "00:14.0 USB controller problem", might be a usb3.0 problem,
> > > tried
> > > > various things, nothing helped, my BIOS has no option to disable xHCI.
> > >
> > > I am hesitant to ask, since it would require running unsigned code
> > > (yuck!), but would you be comfortable doing a kernel git bisection?
> > > That would allow figuring out exactly which commit caused the problem,
> > > and would vastly improve the likelihood of the bug being fixed.
> >

> > Aaehm... It is my work computer, i need it every day and can not risk
> > anything...
> > Is there a safe/standard procedure in qubes to compile the bisects, add
> > them to grub without removing the working kernel, etc.?
>
> Not that I am aware of, sadly. Marek (CCd) might have suggestions.

For any tests, I usually place kernel+initramfs under some arbitrary
name that does not interfere with version-based entries. And do that by
installing kernel "manually", exactly to avoid dnf/rpm removing older
packages. For the grub entry, I usually edit
/boot/efi/EFI/qubes/grub.cfg manually (copy existing section and just
replace file names). But regenerating it with grub2-mkconfig should be
safe too.
This does require manual cleaning after testing is finished,
though...

Here is example script to build and install kernel in dom0:

#!/bin/sh

set -e
make olddefconfig
make -j2
kver=$(make kernelrelease)
sudo make modules_install
sudo cp arch/x86/boot/bzImage /boot/vmlinuz-test
sudo dracut -f --kver="$kver" /boot/initramfs-test.img

it can be launched from kernel sources.

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmKmY0MACgkQ24/THMrX
1yy76AgAgUS+jgFIaNeFSGr7ZMfudTbFNkGvBET6vyem+ddHOais32FHlNcAscmL
qf1MVvl8GmJCH/FozJ6ZEFmFOVcE8/fEok2IL131fzkNTc+YRuH0GmLvH5a0X1o/
mHFRoYvkaD+MKNSFv7gz4n1SadeDoFDyfed9iJaV2PjCIsEohcbDzvtVyTCnFvxM
GUiIPUE+OW/P6AKtR7iEFkNsdnWtahHzPsCuizOW6H/8lWVmOITtWDI1UzVL19zo
jVAUhmUhB9exh17wL/YG1g2MvpN5VxP48yQNuUtQGLJ5ta1AykKrYBqDEZu3Napu
JHfB3xy/WIxVN8kazzq/1khe8Q+LUQ==
=qPpk
-----END PGP SIGNATURE-----

[haaber]

Dear Marek,

kernel testing would be so much easier if the xen.cfg would allow an
option like

default=menuselect

to get a boot menu -- instead of

default=[5.16.whatever]

which makes it actually necessary to "hack" the xen.cfg via a
live-linux-usb intrusion if a kernel should fail to work ... that
produces an attack-vector & is annoying.


Maybe such a function exists already? If not that would be a feature
request!



Thank you, Bernhard

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jun 13, 2022 at 10:28:43PM +0200, haaber wrote:
> Dear Marek,
>
> kernel testing would be so much easier if the xen.cfg would allow an
> option like
>
> default=menuselect
>
> to get a boot menu -- instead of
>
> default=[5.16.whatever]
>
> which makes it actually necessary to "hack" the xen.cfg via a
> live-linux-usb intrusion if a kernel should fail to work ... that
> produces an attack-vector & is annoying.
>
>
> Maybe such a function exists already? If not that would be a feature
> request!

That's the main reason why Qubes 4.1 doesn't use xen.cfg at all. There
is standard grub, where you have menu, editor etc.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmKnnvMACgkQ24/THMrX
1ywXBAf+PU9g3NQ81dwzbVWBzM1x1cRO9MBCsTb/oalKoU9ywOOvok+wDU5pcaC8
8e5QHH0yn4eLFd5cT3x0OGCu6RY8IuPKbKRoUxfpoP+XyQL7Q3iuSEQJ08B8eUj1
Ia/OAjdDKR+IcwlCzSSQnkhyuDXTHwfvOe6nTVxVuykAXqfQgY1QVEUivCDLx475
bMOAkWjSRIt9xM9pKo/JTMYz4E/XJ6qxy3j/hvQO9V0gVjnBk+HICpEZ/y8IErx0
tczn9EejONvx5iH/6lUBQR7gq4p9ncHVnVRiT7Uim+Ha1GICUgZOv20HYlA/RsfI
bFSD3aWKCB3DN5sdVHmnDUSlfH0E3g==
=FHSZ
-----END PGP SIGNATURE-----

[haaber]

Dear Marek,
>> kernel testing would be so much easier if the xen.cfg would allow an
>> option like default=menuselect
>> to get a boot menu -- instead of

>> Maybe such a function exists already? If not that would be a feature
>> request!
>
> That's the main reason why Qubes 4.1 doesn't use xen.cfg at all. There
> is standard grub, where you have menu, editor etc.
>

Brilliant. And I'd love to re-install 4.1 for that. But the 5.x kernel
on the iso fails either on boot, or at latest while install... is there
a grub on the 4.1-iso as well? (i.e. possibility to manually add a
kernel like 4.19?) If so: is the procedure explained somewhere? 'Cause
grub-hacking is very unpleasant, as well :) Thank you, Bernhard

[Peter Palensky]

Update: I can use newer kernels if I remove device "Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader" from sys-usb VM.

If it _is_ attached to that VM, the entire computer crashes upon sys-usb start (when newer kernels are in use, it is fine with [very] old ones).

So I guess not having the card reader is my solution towards upgrading to 4.1.1....

[David Hobach]

On 8/5/22 17:00, Peter Palensky wrote:
> Update: I can use newer kernels if I remove device "Realtek Semiconductor
> Co., Ltd. RTS525A PCI Express Card Reader" from sys-usb VM.
> If it _is_ attached to that VM, the entire computer crashes upon sys-usb
> start (when newer kernels are in use, it is fine with [very] old ones).
>
> So I guess not having the card reader is my solution towards upgrading to
> 4.1.1....

Hm interesting. That's quite similar to my experience [1].

Maybe some Xen code wrt attaching Express Card Readers broke?
Last somewhat good kernel for me was 5.10.109-1.

[1] https://github.com/QubesOS/qubes-issues/issues/7637