QubesOS 4.1 installer doesn't boot on sandy/ivy bridge (xx20/xx30) #789
Comments
|
@Asiderr @osresearch @marmarek:
|
|
I just downloaded the Qubes 4.1 ISO and it appears to be using Xen 4.13. Grepping through the 4.13 source it appears that which is used here: This parser has moved from The Xen code in 4.13 that does the trampoline setup has changed, so I wonder if we can retry with the ancient patch that prevents the EBDA from being consulted. From my 2016 xen-devel post: The other possibility is that something in the VGA has changed, which was the other place that I had to hack back in the distant past... I'm attempting to get Heads running in qemu again so that I can test it against the Qubes ISO. |
|
@osresearch @tlaurion I've built the Xen hypervisor with the patch. After the hypervisor replacement, the problem still arises. I tried to run the installation media with an older version of the hypervisor and I’ve found out that regression has appeared between 4.11 and 4.12 version. |
|
Does it only fail on real hardware? I'm running under qemu and the installer is able to boot into the graphical installer after a while, although the Xen console does not appear on the vga.
Once Heads is booted, these commands to (You can use |
I'm using x230. I've bisected Xen from the 4.11 to 4.13 version and This is the first commit where Qubes OS doesn't boot properly. The Qubes I've started the thread in the xen-devel ml: |
|
Has anyone tried to use builds from here? |
|
@0rb677
Those are built by openqa, qubesos QA platform. I didnt built myself but if bug is upstream in Xen and non patched by @marmarek in QubesOS, I do not see the point building from scratch. Should I see something different? |
This in linked to #749 (Resulting QubesOS installation has a LUKS v.2 header that Heads cannot pplay with) and is not related to Xen not being able to boot installer with "no-real-mode" on real hardware. Were you able to boot the installer? |
|
I tried to boot installed 4.0 system with replaced Xen to Xen 4.14 built directly from stable-4.14 branch and it worked, so there is hope. |
|
no issues booting Qubes-R4.1.0-alpha20201014pre1-x86_64.iso on Librem 13v2/4, Mini, or L1UM |
|
Downloading https://mirrors.edge.kernel.org/qubes/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso |
…de of coreboot in attempt to resolve linuxboot#789 (glitches with repeated patterns all over the screen where FB is not being reinitialized by linux kernel)
…the source of the gfx corryption is linked to the linux kernel, since librems don't seem to have issue linuxboot#789. Innocent copy of librem_mini kernel first, then will customize to add sdcard reader required modules and remove unused modules and compare to x230 kernel config of 4.x
|
With newer iso, same behavior as #789 (comment) is observed. Trying to migrate kernel to have newer i915 support with tlaurion@bafaecb |
…at to ease understanding of configuration changes..... I think i'm actually against storing in savedefconfig format for both linux config and coreboot configs, since it complexifies understanding of board differences. Still trying to figure out linuxboot#789
|
No success on my side for the moment. @jans23? |
…boards (coreboot 4.8.1 boards first) xx20-maximized boards: deactivation of NKSTORAGECLI (Fix linuxboot#926 while permitting support of newer OSes linuxboot#789 which requires cryptsetup2 (linuxboot#876)
|
Newer Xen version might fix the issue (coming next week). Crossing fingers, Xen 4.14 :) |
…boards (coreboot 4.8.1 boards first) xx20-maximized boards: deactivation of NKSTORAGECLI (Fix linuxboot#926 while permitting support of newer OSes linuxboot#789 which requires cryptsetup2 (linuxboot#876) x230-nkstorecli board removal: was already not having dropbear, e1000e. Was a testboard to test compilation of nkstorecli. Integrated under xx30-maximized boards.
|
Proven to work under KGPE-D16 by @blobless with that PoC build https://app.circleci.com/jobs/github/tlaurion/heads/770?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link |
|
Requires #876 to install. Proven to work also. |
|
@tlaurion Problem still occurs on the x230. Tested with current master ( |
|
there is some improvement... I think. NOTE: My heads rom throws a message that may be related: i915 0000:00:02.0: Invalid PCI ROM header signature expecting 0xaa55, got 0x230c but it works perfectly with qubes 4.04 I made a regular USB-device with dd as usual, because the iso in a ext4 partition method is not possible due to lack public key for verification. (I also think that is not relevant) same initial screen, but after a while it continues then it shows this error trace: ? add_wait_quewe_exclusive +0x70/0x70 and after another (long) while Starting Installer, one moment... Posting this here only to give feedback, although I am not sure this is the right place (maybe Qubes github?), but I feel this maybe usefull. If you fell this info is not relevant, feel free to remove it. Just want to help Regards |
|
There is no CircleCI build because older then 30 days. Flashing build/x230-hotp-maximized/heads-x230-hotp-maximized-v0.2.0-1034-gc3b0bd6.rom internally |
|
Just to make sure I haven't corrupted blobs from past tests: Prior: |
|
After importing public key in firmware and booting from USB (Options, USB boot, choosing QubesOS Install option)
|
|
Same error reported by @qubicrm from i915 and drm_fb_helper |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1792515 https://gist.github.com/i0z0m/17b01ebe9a50db5c122edf06e892cdb6 Looking and testing. Let's remember that Heads always kexec the OS kernel by passing the additional following arguments to kexec when booting Xen: here:
Let's also remember that coreboot passes some arguments to Heads linux payload at boot and that additional, defined kernel arguments are defined under board config, which are passed to OS kernel at boot Attempts: 1- Rebuilding with newer 5.10 kernel inside of Heads. |
|
My terminology might be off here. But couldn't we just avoid using modesetting modules? So remove i915 and have just the native graphics used. It wouldn't look as nice but we can set a close resolution with |
|
@Tonux599 : I can revisit this. But the reasoning behind this is the usage of FBWhiptail vs Whiptail(console based) UX requirements behind gui-init usage under heads, which passed vga=current to QubesOS without issues before. If we do not have i915 and DRM defined, then FB is not initialized and whiptail codepath will pick on console based menus. That is not so bad for Heads. If no FB is initialized, we go into Whiptail mode, not FBWhiptail. For what interests us here (QubesOS install), not having a FB defined is the reason why QubesOS installer fails under KGPE-D16 server if not activating VNC installer, since QubesOS have not implemented terminal based installer, and requires a working FB there. From what I understand that is happening here under QubesOS 4.1 installer is exactly that now; no initialized FB so the Installer fails to switch to the graphical installer. The other KGPE-D16 server board just doesn't use neither FBWhiptail nor Whiptail and uses generic-init. Where KGPE-D16 workstation uses FBWhiptail with graphical cards supported in kernel, permitting QubesOS installer to boot. This explains why QubesOS 4.1 booted successfully on KGPE-D16 workstation as reported here. So basically, this doesn't seem to be a Xen problem as before anymore, but being platform specific with graphical cards init being in the way of success.
So sure all xx20 and xx30 and older librem owners would want to retrograde into console Whiptail. A bit more understanding of what is happening into i915+drm seems to be the way here. |
|
I would have to investigate more but from past experiences booting from Grub into, say debian, with nomodeset still allows for for X (along with gnome, xfce etc.) to still display graphics. Usually at a super low resolution but that can be fixed with Unless the driver (i915, nouveau etc.) is still being used to allow that functionality. Edit: my thinking being why wouldn't FBWhiptail work in the same way |
|
@Tonux599 agreed, but then all the previous:
Would not apply. |
|
Closest to this issue found: https://gitlab.freedesktop.org/drm/intel/-/issues/2414 |
|
So from my understanding of what is happening here, the timeout is happening while attempting to set the fb on non-existing output devices. tried:
Will try:
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=101269 So its going to be a configuration battle to get the fixes applied from i915 down to drm_kms_helper to not lock, from what I understand, and the bug only exists on Sandy/Ivy. |
|
@Tonux599 : the problem here with kexec is that it is expected that the heads kernel already initialized the FB which is supposed to be reused. When there is difference between initialized FB, there is flickering. As shown here, when heads tries to boot xen, it passes My intuition here is that the kernel drivers for drm, drm_kms_helper and or i915 are the culprits in QubesOS 4.1. There is probably a workaround that can be pushed in KERNEL_ADD board configurations for sandy/ivy bridges. i915drm_kms_helperdrm |
…eters, just upgrading kernel version, and removing heads kernel quiet option in the goal of troubleshooting linuxboot#789
tlaurion
changed the title
|
Resolved with combination of QubesOS/qubes-issues#6792 (comment) and #1015. Waiting on boards owners to test and report successes/failures under #1015. |
|
Not related to boot issue, but resume issue: QubesOS/qubes-issues#6066 (comment) To be tested, but supposed to be fixed in Xen 4.14.3 which came with 4.1 RC1 |
Resume issue fixed when running #1015 and QubesOS 4.1 RC1. |
|
I just tryed to install Qubes 4.1.0 RC1 on my X230 doing a clean install and I still have the graphical glitch (same as above). The glitch goes away after a minute or so and then errors out when trying to load the installer "X startup failed". |
|
I currently have V0.2.1 from the release area so like you said I will have to upgrade it which is why it is not working I see. I do not have a reprogrammer. Do we have any roms made with this new upgrade yet? |
@no-sauce : Heads didn't receive any github releases since forever. If IFD is unlocked: you can theoritically flash internally the whole 12mb opaque flash with maximized builds (hotp if you have Nitrokey pro/Librem Key), x230-maximized if not. If unsure, you would have to flash x230 internally, just flashing the BIOS region without taking advantage of fully neutered ME liberated space (if not completely neutered, you have 7.5MB BIOS region available. If IFD was unlocked, you can take advantage of 11.5Mb available). This is why #1015 is pending still. I currently receive a lot of individual questions. I think it is time to create an upgrade guide. A lot happened inside of Heads since release 0.2.1. So: You can answer at #1015, that would be probably beneficial for the whole community. |
|
#1015 merged |
|
Some notes on patches we keep for kexec: those are applied when kexec uses elf kexec loader, not xen (multiboot). So OP referring to q4.1 to fb corruption even though 116787f was merged was irrelevant. Conclusion here was that Xen had a regression. Kinda important here since Xen is dealt differently under kexec scripts and is still detected today as multiboot from kexec-parse related scripts. |
Booting
https://openqa.qubes-os.org/tests/10816/asset/iso/Qubes-4.1-20200726-x86_64.iso results in this even though 116787f was merged in :
@marmarek any idea?
Originally posted by @tlaurion in #788 (comment)
The text was updated successfully, but these errors were encountered: