Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kexec can't boot qubes 4.1 iso #672

Closed
ghost opened this issue Feb 13, 2020 · 34 comments
Closed

kexec can't boot qubes 4.1 iso #672

ghost opened this issue Feb 13, 2020 · 34 comments

Comments

@ghost
Copy link

ghost commented Feb 13, 2020

Hi @tlaurion any chance to boot from heads? Did you try 4.1 iso?
I use master branch. 4-14.62-heads

test2
test1

@MrChromebox
Copy link
Contributor

MrChromebox commented Feb 13, 2020

where are you seeing Qubes 4.1? 4.0.3 is the latest release

edit: would also help to mention what hardware is in use

@ghost
Copy link
Author

ghost commented Feb 13, 2020

@MrChromebox

laptop : x220
install media: https://openqa.qubes-os.org/tests/5493/asset/iso/Qubes-4.1-20200113-x86_64.iso
firmware: heads - boot fails.

laptop : x220-tablet
install media: https://openqa.qubes-os.org/tests/5493/asset/iso/Qubes-4.1-20200113-x86_64.iso
Rufus MBR/Legacy method dd (only legacy mode, uefi stuck before Anaconda start)
bios: modified 1.46 (unlocked RAM and whitelist wifi) NOT coreboot (http://www.mcdonnelltech.com/X220_v1.46_Modified_BIOS.zip) - boot success

@MrChromebox
Copy link
Contributor

any reason you're using a nightly build instead of the 4.0.3 release? Can you test that so we know if it's version-specific?

@ghost
Copy link
Author

ghost commented Feb 13, 2020

any reason you're using a nightly build instead of the 4.0.3 release? Can you test that so we know if it's version-specific?

Yes. fedora-25 on dom0 is totally outdated and not supported (status on December 12th, 2017)
Qubes 4.1 runs fedora-31, xfce-4.14, new features, include installation, a lot of fresh packages etc.
Qubes builder works good for 4.1. Ok, i will try.

@MrChromebox
Copy link
Contributor

I'll test both here as well and see if I can replicate on a Librem

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 13, 2020

@0rb677 @MrChromebox I confirm install works on my branch (not main Heads) for x230 for latest official QubesOS release (4.0.3). I didn't test any 4.1 release yet, while there are another issue linked to LUKS V2 not being supported (#669) which would probably fail to boot Fedora-31(?) based QubesOS install anyway until resolved (upgraded cryptsetup module, reproducibility of produced ROM images confirmed on CI for different host builders configs ( ubuntu, debian, fedora etc).

There was a fix a while back to be able to boot fedora-30 (#553) that I tested but your issue seems to be related to igfx corruption, which is supposed to be fixed under x220, but i'm not the best to confirm this.

Unfortunately, I just own x230 for testing. Will put that in my todo list but i'm quite busy right now.
If you want to ship a x220 to me, be my guest but reading QubesOS release schedule shows that we are far from 4.1. (So this is not a priority for me to test this now).

Please check in other issues for t420 and x220 users and ping them here. If you can confirm that their patchwork work, poke me in those PR and I will merge them asap. I lost track of the current t420 and x220 statuses, being more interested in 9elements work to port coreboot 4.11 correctly for those boards with VBOOT+measured boot with IFD and ME cleaned out so we have enough space to do interesting things for those boards.

We might as well open an issue to track who tests what hardware. That would be really helpful.

@MrChromebox
Copy link
Contributor

Installers for both Qubes 4.0.3 and 4.1-20200113 boot fine on a Librem 13v4 running Heads master (bcf522c) + the handful of branding changes from Purism's tree. Given the display artifacts, there's at least an IOMMU config issue at play, perhaps more. I'd start by adding intel_iommu=igfx_off to the x220's coreboot config CONFIG_LINUX_COMMAND_LINE param, which both the x230 and Librems already use. That param only affects the Heads payload, not any kexec'd kernels.

@tlaurion
Copy link
Collaborator

See here

@tlaurion
Copy link
Collaborator

Personally, I would remove the quiet there for all the boards.

@MrChromebox
Copy link
Contributor

Personally, I would remove the quiet there for all the boards

I'll push a PR after testing

@MrChromebox
Copy link
Contributor

Personally, I would remove the quiet there for all the boards.

hmm, it's pretty verbose w/o 'quiet' and not in a particularly useful way

@tlaurion
Copy link
Collaborator

Agreed. Tested too. Nope!

@ghost
Copy link
Author

ghost commented Feb 14, 2020

@MrChromebox @tlaurion thanks, i just woke up, now i will reflash my laptop today.

@ghost
Copy link
Author

ghost commented Feb 14, 2020

Also changed chip to Winbond W25Q64.V and added iomem=relaxed

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 15, 2020

@0rb677 I wouldn't recommend 4.1:
QubesOS/qubes-doc#828

Fedora-25 on dom0 is not problematic, all needed packages are backported and all your actions should be in AppVMs, not dom0 anyway.

I would stick to 4.0.3 if I were you.

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020 via email

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020 via email

@tlaurion
Copy link
Collaborator

@0rb677 iomem=relaxed
Why is that?

@tlaurion
Copy link
Collaborator

Please follow the breadcrumbs by starting where it works:
#578

@ghost
Copy link
Author

ghost commented Feb 16, 2020

@tlaurion wow gui-init is amazing. Its works with my nitrokey-start

@tlaurion sorry i wrote make board=x220 instead make BOARD=x220
also fbwhiptail package available only if you connect your vm to vpn in my country.
iomem=relaxed you can dump flash from dom0 use coreboot-utils and flashrom for example

2020-02-16 10:41:32+03:00 MAKE coreboot
2020-02-16 10:42:12+03:00 DONE coreboot
"/home/user/heads/build/coreboot-4.8.1/x220/cbfstool" "/home/user/heads/build/coreboot-4.8.1/x220/coreboot.rom" print
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           86884 none
cpu_microcode_blob.bin         0x15480    microcode       25600 none
fallback/ramstage              0x1b900    stage           96557 none
cmos_layout.bin                0x33280    cmos_layout      1816 none
fallback/dsdt.aml              0x33a00    raw             13646 none
fallback/payload               0x36fc0    simple elf    6977487 none
(empty)                        0x6de800   null           954328 none
bootblock                      0x7c7800   bootblock        1968 none
2020-02-16 10:42:12+03:00 INSTALL   build/coreboot-4.8.1/x220/coreboot.rom => build/x220/coreboot.rom
e2c4e3d2de9c434155a1bee6d30741884a9985dfa1698a9c5efbe01c47ee7d1c  build/x220/coreboot.rom
e2c4e3d2de9c434155a1bee6d30741884a9985dfa1698a9c5efbe01c47ee7d1c  /home/user/heads/build/x220/coreboot.rom
make[1]: Leaving directory '/home/user/heads'


@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020 via email

@ghost
Copy link
Author

ghost commented Feb 16, 2020

@tlaurion i dont understund what you mean,
i use this commit https://github.com/osresearch/heads/pull/578/files#diff-d8b4fe91f08f8822cbab99f7ea3eedf7R23 with intel_iommu=igfx_off enabled.

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020 via email

@ghost
Copy link
Author

ghost commented Feb 16, 2020

@tlaurion 10-15 minutes, waiting for downloading iso.

@tlaurion
Copy link
Collaborator

If yes, please close the issue (kexec qubesos 4.1) and open other/comment in other tickets linked to your issues!

Happy that you like whiptail!

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020 via email

@ghost
Copy link
Author

ghost commented Feb 16, 2020

@MrChromebox @tlaurion thanx o lot but it doesn't help. Screen artefacts and boot stuck!
intel_iommu=igfx_off is enabled when kexec try to boot. need more time for tests. I can close temporary this ticket if you want.
i use this https://github.com/osresearch/heads/pull/578/files#diff-976724db470cd69ca59874dcba28ab59 and this
https://github.com/osresearch/heads/pull/578/files#diff-d8b4fe91f08f8822cbab99f7ea3eedf7
commits.
Can you please add to FLASHROM_OPTIONS winbond spi chip?
i agree with you @tlaurion and switch to Qubes Stable. It works better now.

DSC_0102
DSC_0104

@ghost ghost closed this as completed Feb 16, 2020
@ghost ghost reopened this Feb 16, 2020
@ghost
Copy link
Author

ghost commented Feb 16, 2020

@tlaurion @MrChromebox @flammit @SebastianMcMillan also x220 has different spi chips.
heads/initrd/bin/flash.sh need update. For example, my x220 tablet use -c "MX25L6406E/MX25L6408E" and x220 use -c "W25Q64.V", not -c MX25L6405D. Or you can't flash bios internal from heads or add gpg keys. I changed it manually.

 x220* )
    FLASHROM_OPTIONS='--force --noverify-all -p internal --ifd --image bios -c MX25L6406E/MX25L6408E'

and add to boards/x220/x220.config

export FLASHROM_OPTIONS='--force --noverify-all -p internal --ifd --image bios -c MX25L6406E/MX25L6408E'
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on linux_spi.

also need add cbfstool build/x220/coreboot.rom add -t raw -n initrd/.gnupg/public.key -f public.key instead documentation
and add textinfo package to build requirements (musl-cross)

also please do not remove this option CONFIG_ANY_TOOLCHAIN=y

coreboot: Using /home/user/heads/crossgcc/bin/i386-linux-musl-gcc
toolchain.inc:176: The coreboot toolchain for 'x86_32' architecture was not found.
toolchain.inc:212: 
toolchain.inc:213: To build the entire coreboot toolchain: run 'make crossgcc'
toolchain.inc:217: For more toolchain build targets: run 'make help_toolchain'
toolchain.inc:218: 
toolchain.inc:220: To try to use any toolchain in your path, run 'make menuconfig', then select
toolchain.inc:222: the config option: 'General setup', and 'Allow building with any toolchain'
toolchain.inc:224: Note that this is NOT supported. Using it means you're on your own.
toolchain.inc:226: 
toolchain.inc:228: *** Halting the build.  Stop.

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 16, 2020

Please leave this ticket open to track newer Xen kexec problems(?)
QubesOS 4.1 bug is probably linked to kexec needed changes to handle newer xen correctly.
Ping @osresearch @flammit @MrChromebox : if you have time to play with QubesOS 4.1 on qemu (and/or create a small draft on how to properly test with qemu to help others troubleshoot this would be awesome.)

@0rb677 : My intuition on (irrelevant here) internal flash chip definition is happening here

@0rb677: Please participate under relevant tickets to continue troubleshooting, testing of other PRs. If it works for you, say it there. It will help merging those changes upstream for everyone.
Universal flash (flash command under board config)
X220/T420 support

X220/T420 and X230/T430 are very similar while different. Don't hesitate to tag SebastianMcMillan techge and flawedworld in relevant tickets for those people owning the same boards to facilitate collaboration to resolve remaining issues upstream, test code and facilitate merging.

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 19, 2020

@osresearch pointed to this, that may have reappeared in latest Xen and doesn't permit kexec to launch Xen, maybe because of bad ELF format.

@marmarek, can you take a look?
Edit: link corrected.

@marmarek
Copy link
Contributor

Are you sure that is the correct link? It points at flashrom options, I don't think that has anything to do with kexec.

@tlaurion
Copy link
Collaborator

@marmarek: sorry. link corrected.

@tlaurion
Copy link
Collaborator

tlaurion commented Apr 8, 2020

@marmarek : have you been able to shed some light to the issue and discussion pointed here?

@marmarek
Copy link
Contributor

marmarek commented Apr 8, 2020

Not yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants