Adding new kernels to iso?

[Ondřej Fiala]

Hello,

first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600 & GTX1650. After some tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes blank after 'launching installer'. When running in limited graphics mode, the same happens. The only visible error before this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am not sure how significant it is, but there is a lot of OK-looking output before the screen goes blank. When I edit limited graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE) [drm] Failed to open DRM device for pci ...", followed by X.org exiting with error. Also "Pane is dead". The driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver. Sure enough, Xorg lists the driver as only supporting cards before GTX400. However, the latest version of nouveau actually supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a newer one, which should include a newer nouveau version, could fix this issue. So now the actual subject of my email:

How do I add new kernels to the iso? I am aware of the extrakernels/ directory in the iso's root, but I haven't been able to figure out in which format I should add them there for it to work. Note: I know how to modify the iso, that's not what this question is about. Any advice will be greatly appreciated.

Best Regards,
Ondřej Fiala

[Chris Laprise]

On 9/17/20 5:00 PM, Ondřej Fiala wrote:
> Hello,
>
> first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600 & GTX1650. After some tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes blank after 'launching installer'. When running in limited graphics mode, the same happens. The only visible error before this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am not sure how significant it is, but there is a lot of OK-looking output before the screen goes blank. When I edit limited graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE) [drm] Failed to open DRM device for pci ...", followed by X.org exiting with error. Also "Pane is dead". The driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver. Sure enough, Xorg lists the driver as only supporting cards before GTX400. However, the latest version of nouveau actually supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a newer one, which should include a newer nouveau version, could fix this issue. So now the actual subject of my email:

Your underlying problem is probably the same as ours in this Ryzen 4000
laptop thread:

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

We have taken the route of building Qubes 4.1 pre-releases with
updated/patched Xen 4.14 & Kernel 5.8. These appear to be the bare
minimum versions required for Ryzen 4000/Renoir chip sets.

>
> How do I add new kernels to the iso? I am aware of the extrakernels/ directory in the iso's root, but I haven't been able to figure out in which format I should add them there for it to work. Note: I know how to modify the iso, that's not what this question is about. Any advice will be greatly appreciated.

There was some discussion about that I think in the above thread. IIRC
altering a 4.0 iso was a manageable task but using above Xen version
with it appeared unlikely... while altering a 4.1 iso seems much harder.

I think I just finished building my first Ryzen 4000-ready iso and I'm
about to test it!

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Ondřej Fiala]

Thank you for the reply! Since I don't have Google account which seems to be required to view the initial discussion (as linked in the first post of the thread), could you please give me a brief summary of what the core issue is?

On Sep 17, 2020 23:19, Chris Laprise wrote: > > On 9/17/20 5:00 PM, Ondřej Fiala wrote: > > Hello, > > > > first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600 & GTX1650. After some tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes blank after 'launching installer'. When running in limited graphics mode, the same happens. The only visible error before this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am not sure how significant it is, but there is a lot of OK-looking output before the screen goes blank. When I edit limited graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE) [drm] Failed to open DRM device for pci ...", followed by X.org exiting with error. Also "Pane is dead". The driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver. Sure enough, Xorg lists the driver as only supporting cards before GTX400. However, the latest version of nouveau actually supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a newer one, which should include a newer nouveau version, could fix this issue. So now the actual subject of my email: > > Your underlying problem is probably the same as ours in this Ryzen 4000 > laptop thread: > > https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1 > > We have taken the route of building Qubes 4.1 pre-releases with > updated/patched Xen 4.14 & Kernel 5.8. These appear to be the bare > minimum versions required for Ryzen 4000/Renoir chip sets. > > > > > How do I add new kernels to the iso? I am aware of the extrakernels/ directory in the iso's root, but I haven't been able to figure out in which format I should add them there for it to work. Note: I know how to modify the iso, that's not what this question is about. Any advice will be greatly appreciated. > > There was some discussion about that I think in the above thread. IIRC > altering a 4.0 iso was a manageable task but using above Xen version > with it appeared unlikely... while altering a 4.1 iso seems much harder. > > I think I just finished building my first Ryzen 4000-ready iso and I'm > about to test it! > > -- > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

On 9/18/20 1:25 AM, Ondřej Fiala wrote:
> Thank you for the reply! Since I don't have Google account which seems to be required to view the initial discussion (as linked in the first post of the thread), could you please give me a brief summary of what the core issue is?
>
> On Sep 17, 2020 23:19, Chris Laprise wrote: > > On 9/17/20 5:00 PM, Ondřej Fiala wrote: > > Hello, > > > > first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600 & GTX1650. After some tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes blank after 'launching installer'. When running in limited graphics mode, the same happens. The only visible error before this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am not sure how significant it is, but there is a lot of OK-looking output before the screen goes blank. When I edit limited graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE) [drm] Failed to open DRM device for pci ...", followed by X.org exiting with error. Also "Pane is dead". The driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver. Sure enough, Xorg lists the driver as only supporting cards before GTX400. However, the latest version of nouveau actually supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a newer one, which should include a newer nouveau version, could fix this issue. So now the actual subject of my email: > > Your underlying problem is probably the same as ours in this Ryzen 4000 > laptop thread: > > https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1 > > We have taken the route of building Qubes 4.1 pre-releases with > updated/patched Xen 4.14 & Kernel 5.8. These appear to be the bare > minimum versions required for Ryzen 4000/Renoir chip sets. > > > > > How do I add new kernels to the iso? I am aware of the extrakernels/ directory in the iso's root, but I haven't been able to figure out in which format I should add them there for it to work. Note: I know how to modify the iso, that's not what this question is about. Any advice will be greatly appreciated. > > There was some discussion about that I think in the above thread. IIRC > altering a 4.0 iso was a manageable task but using above Xen version > with it appeared unlikely... while altering a 4.1 iso seems much harder. > > I think I just finished building my first Ryzen 4000-ready iso and I'm > about to test it! > > -- > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
>

The link is to discourse.net, not google:

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

The core issue with the laptops is Xen 4.8 incompatibility (requiring
4.14 instead). Of course, Nvidia is not a factor in our case so maybe
this isn't a match for your situation.

In general, when it comes to using open source OSes, I recommend people
avoid Nvidia; it is a tightly closed graphics platform.

[Ondřej Fiala]

Please read more carefully next time -- "Since I don't have Google account which seems to be required to view the initial discussion (as linked in the first post of the thread)". The first post says "continuing from discussion at [link to Google groups]" without explaining anything...

Anyways, thank you for the explanation. I am aware of Nvidia GPU's limitations when it comes to compatibility with Linux, however the issue here is in Qubes not including the open source drivers, not the open source drivers working poorly..

Dne 18. 09. 20 v 21:24 Chris Laprise napsal(a):

[unman]

On Fri, Sep 18, 2020 at 09:39:30PM +0200, Ond??ej Fiala wrote:
> Please read more carefully next time -- "Since I don't have Google account

> which seems to be required to view the initial discussion (*as linked in the
> first post of the thread*)". The first post says "continuing from discussion

> at [link to Google groups]" without explaining anything...
>

It really isn't true that you need a google account to read google
groups.
I connect over Tor, and rarely use groups- much prefer to use the mail
archive ( and you could easily have done this instead of posting snitty
comments). On the rare occasions that I *have to* use google groups,
other than enabling jscript, I connect just fine.
I realise that other users have reported a log in requirement - all I'm
saying is that it isn't universally applied.

For the record, google groups for qubes-users is available at:
https://www.mail-archive.com/qubes...@googlegroups.com/
and this provides a searchable archive

It would be desirable if every one linked to the mail archive - is there
**any** chance that this could become the default?
(Also, the documentation should do this by default too.)

[Ondřej Fiala]

Forgot to give the list carbon copy, my bad.---------- Forwarded message ----------
From: Ondřej Fiala <temp.x...@volny.cz>
Date: Sep 19, 2020 16:00
Subject: Re: [qubes-users] Adding new kernels to iso?
To: unman <un...@thirdeyesecurity.org>
Cc:

> I tried opening the link in question on three different occasions and it required me to log in on all of them, which is why I asked for the summary.

[unman]

On Sat, Sep 19, 2020 at 04:00:38PM +0200, Ond??ej Fiala wrote:
> I tried opening the link in question on three different occasions and it required me to log in on all of them, which is why I asked for the summary.
>
> I agree that linking to a resource that does not (even occasionally) require login should be preferred. People looking to Qubes for security often do so to have a secure environment for privacy-enhancing tools such as Tor, so it's reasonable to expect that a lot of them don't have Google account.On Sep 19, 2020 14:53, unman <un...@thirdeyesecurity.org> wrote:
> >
> > On Fri, Sep 18, 2020 at 09:39:30PM +0200, Ond??ej Fiala wrote:
> > > Please read more carefully next time -- "Since I don't have Google account
> > > which seems to be required to view the initial discussion (*as linked in the
> > > first post of the thread*)". The first post says "continuing from discussion
> > > at [link to Google groups]" without explaining anything...
> > >
> >
> > It really isn't true that you need a google account to read google
> > groups.
> > I connect over Tor, and rarely use groups- much prefer to use the mail
> > archive ( and you could easily have done this instead of posting snitty
> > comments). On the rare occasions that I *have to* use google groups,
> > other than enabling jscript, I connect just fine.
> > I realise that other users have reported a log in requirement - all I'm
> > saying is that it isn't universally applied.
> >
> > For the record, google groups for qubes-users is available at:
> > https://www.mail-archive.com/qubes...@googlegroups.com/
> > and this provides a searchable archive
> >
> > It would be desirable if every one linked to the mail archive - is there
> > **any** chance that this could become the default?
> > (Also, the documentation should do this by default too.)

Did you do this from the same qube at the same IP address? It's just not
my experience using variety of qubes under Tor. If I get a login, I just
fire up another qube and try again.

mail-archive.com undoubtedly helps, and I think it should be the default
reference in the docs. I believe that these lists are now echoed to the
Forum - perhaps "will be echoed" - I'm not sure of that: I mean I'm not
sure of the benefit.

[Ondřej Fiala]

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2020-09-19 7:53 AM, unman wrote:
> [...]

>
> (Also, the documentation should do this by default too.)

Patches welcome. :)

Most links were probably added before the the Mail Archive
mirror existed.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl9mXwgACgkQ203TvDlQ
MDDu0BAAo20deJQ62gk9oLgRkTsOO9aH57VfEHIATqZ+EwxpjuTRrbkDgzwnFJ0l
CwQDhgUPTHkm7MlGDQrQ+2MkF4ujXHzDy5S7HFd+R6EcBR8vHT3HqEEpmng+1jjf
7VBjdj2uVbid8ZCm0cXVuDL0Z+QTtcwKi/lOnnaNdzOEO+qqZ9+2DQ9WlzqJcuKa
UiFoy6qylqUx0r+A/G7A1kvyrkHApjQFj97nzbIF/5HYdpTnqrJRicafRzV+ZMyC
jNn9oK05cbsBvrv8uty8dDa21XR8j1g2N0v6ezKYvW1y4Gml9GyVP9gzKFMgwCGY
NfpusWSMdwb4/TD4rjYzh9sDzxwvx/X2aOeIR54SMB4RT5IY+57kARZL0hfM6J7W
9wVxq+8nFmiPFx4RjHKljbLpI2MtDefkNUWtfoQCJnTh/+vTBT7ACF6zxe3UXwxi
QT5CNpWpDCrJsDikNVHE5lKSmZs7v/tm0ZZyXiKMzphgsSf9nnYCv9Q4pYne6xp0
JhwM0YkrAr81MrV3zZVKKCWOIiVcID5vIqkxooO23fHKK2LbOKTX4TO5swBPfB3Y
1uBWR8S33d22OLO+qdV2wHuYFWoit6sHs8e1airR++h+7AsggwvTql07xthFAo0n
gsxlh85tyBepdQRbmeFn5/w/W+7vTjOBp+aUL4uNEBzLmudoJn0=
=ovo3
-----END PGP SIGNATURE-----