Can't get heads to boot on t430

[ghost]

did a fresh clone of heads pulled and cleaned the ME blobs for xx30 built t430-hotp-maximized roms flashed top & then bottom upon booting, my t430 made a continuous beep with microphone and power lights blinking

flashed backup dump and the t430 boots. hardware is good.

then I tried just the t430-flash rom on the 4096kb chip only, and I get the same boot error: blank screen, blinking lights, continuous beep. heat sink fan starts up then immediately slows to a stop.

any ideas?

since the backup bios flash worked-- is there some way i could get a prebuilt t430-flash heads rom just for the purpose of testing, to confirm/deny that the rom build is the problem?

[tlaurion]

@walliams basic troublshooting first.

Is the wifi physical slider off?

[ghost]

i figured it out! somehow on reflashing, the Centrino card was dropped off of my sys-net "Devices" list. added it back in and it's working! so, not a problem with heads, but i guess something to be aware of that could cause people trouble with existing qubes installations.

thanks again to both of you for the advice. i am now very happy with this heads rom. now if only i could get my fedora template to boot with the nvidia drivers :(

@eganonoa since you have gone to some lengths to enable dGPU's in heads, any rec's on a qubes template that plays nice with nvidia drivers? I read something about the fedora kernel being an issue. I was running fedora-34 in a cloned template, and now it still starts but no apps will open, not even terminal.

[eganonoa]

@walliams Good stuff. Glad this worked out. I'm not a regular Qubes user. But I do have one (non-Heads, but coreboot nonetheless) device running Fedora 35 (silverblue). Getting the nvidia card set up was no problem at all (on 33, 34 and 35). I just have the nvidia-470xx driver installed (esp. xorg-x11-nvidia-470xx) and use system76-power (via this COPR https://copr.fedorainfracloud.org/coprs/szydell/system76/) for graphics switching.

@tlaurion I have set up a new clean branch for this rebased on master, one commit, etc (see https://github.com/eganonoa/heads/tree/dgpu-t430). Happy to make a PR for it, though obviously I can't test on it going forward and will rely on @walliams and others with a t430 dgpu to test. Let me know.

[ghost]

@eganonoa great. qubes doesn't provide a fedora-35 template yet, but it looks like i can upgrade from a 34 template. I'll try that, then i might try an ubuntu template if that won't work. goal is to make this an all purpose machine as well as a security beast.

really appreciate the help getting setup. i'm happy to test any boards you are trying to merge with master for the good of the project. feel free to mention me in a thread if you have another t430-dgpu build that needs testing. obviously i would appreciate if you verify that the updates work on your T530 first to minimize risk ;)

would you like me to verify that the new t430-dgpu branch you just made is working, or is it essentially the same as what I just built?

[eganonoa]

@walliams You should be able to get it to work with Fedora 33 and 34 also. I certainly have, always using the latest nvidia driver and system76-power. Ubuntu probably the same, though I have no experience with it beyond servers.

Thanks re testing on the t430-dgpu going forward. The latest branch is just a copy of the one you used, just with the additions to master (with dgpu boards for t530 and w530) that happened today included. So there's nothing new related to what you've tested already.

[tlaurion]

@walliams @eganonoa

About https://github.com/eganonoa/heads/tree/dgpu-t430

There are validation concerns (nothing gets validated) because of lack of:

{ do this | pipe here } || { echo failing; exit 1 }

thorough vbios code as reported through Matrix @eganonoa. Result is that the script continues without exiting when a step fails. Other steps should also fail (script calls) without continuing when there is an error.

Also, those scripts lack manual installation of bundle in apt install, and then upgrading to proper bundle version.

I'm not sure yet why Qubes fails to call rom-tool without sudo in its call to UEFIExtract in your scripts.

But that should be looked on independently prior of merging in another PR fixing other vbios extract scripts and then deduplicating here.

No problem on debian-10 docker image.

@walliams is https://github.com/eganonoa/heads/tree/dgpu-t430 working for you?

[ghost]

@walliams is https://github.com/eganonoa/heads/tree/dgpu-t430 working for you?

@tlaurion no problems for me so far. the vbios script took two tries-- one without sudo and then one with. i can't say i understand why this was necessary.

i had some issues installing nvramtool... the command wouldn't call the script, so i had to manually identify it after cloning the coreboot git. But once I got the rom built & flashed and figured out why my wifi went out i have had no problems

[ghost]

to be clear though, I am still having trouble getting the dGPU to run properly on the machine. every time i add it into a qube my system freezes up... but that's more likely a combination of qubes & user error than a heads build issue.

[tlaurion]

to be clear though, I am still having trouble getting the dGPU to run properly on the machine. every time i add it into a qube my system freezes up... but that's more likely a combination of qubes & user error than a heads build issue.

Those needs to be HVMs, and pci/gpu passthrough guides need to be followed. If you have issues there, I would recommend posting under Qubes forums and come back to create a new seperate issue if something inside of coreboot/heads is missing.

Some links:

• https://forum.qubes-os.org/t/qubes-gpu-passthrough/661
• https://www.qubes-os.org/faq/#can-i-run-applications-like-games-which-require-hardware-acceleration