-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
KGPE-D16 : Do we want a headless system until dom0 kernel boots? #368
Comments
This |
Is the only difference the kernel command line? a) it seems that keeping the kernel command line in the bzImage is a bad plan long term |
It's a combination of the coreboot/heads kernel command line as well as the target kernel command line additions to set both consoles to have the correct init stdin/stdout: |
@osresearch @flammit : Actually, following "LUKSerror: luks device has no key/passphrase encountered bug from QubesOS text-based installer, it is currently impossible to create a LUKS container on a headless computer from QubesOS installation if not hacking your way and providing a TBD kickstart recipe. Note the the second phase install would also not be covered and would required the user to finish installation through manual I propose to make the default kgpe-d16 board configuration dual output to both serial console and local tty. |
Having issues having dual console to boot QubesOS graphical installation. The installer complains about hvc1 not being accessible but fires up in FB mode, as opposed to the text only installer. Unfortunately, I have no time for that and needed my server to reinstall QubesOS right away so I splitted up the configuration in precedent WiP PR and used kgpe-d16_workstation to reinstall QubesOS, and flashed back the kgpe-d16.config resulting rom to manage it remotely through OpenBMC. As a result, now, I cannot run Will try to play around Xen console recommendations later on when I'll come visit back my server physically. EDIT: Actually it was my error. Launching Installing QubesOS on headless system is still not possible. |
Actually it was my error. Launching The recovery shell was not working on my kgpe-d16 last time I tried. EDIT: If someone has an idea to be able to launch that Qubes Graphical installation remotely... |
Haven't tried it myself, but would this work for what you are doing?
|
@awokd: Awesome. Haven't thought of doing that. Thanks. So headless it will stay! |
@marmarek: QubesOS installation falling back into text mode only should ask the user if he wants to continue through VNC. Want me to open a ticket for that? |
@tlaurion Qubes installer have disabled network on purpose - to allow safe installation, even if computer is plugged into hostile network, so this definitely should not automatically fallback into VNC install. But indeed, with a confirmation, it would be much easier than with kickstart. |
Well. Since we connect to the KGPE-D16 through OpenBMC by ssh and from there, access to host terminal by When arriving at the installer, we need to type CTRL-ALT-TAB to switch to shell there, then launch |
Assuming most people will be using a secondary GPU if using Qubes on this board. If we include the required drivers for the GPU (i.e. nouveau for Nvidia cards) in the kernel, and set the jumper to disable the onboard GPU on the motherboard, Linux will only see this secondary video card and so will the installer. I used this method to install Qubes recently on the board with coreboot. Qubes installer initialised the secondary GPU fine and as the primary display. The only thing the installer complained about was that there was no IOMMU (even though enabled in coreboot). Appending 'iommu=force' to Xen's command line rectified this. |
@Tonux599 we would then talk about a third board config. Headless, aspeed and nouveau. |
@tlaurion Not necessarily, as has been mentioned before we could have two configs.
If the jumper is at default, the Aspeed GPU is initialised by Linux as the primary display. If the jumper is set at disable, Linux doesn't even see the Aspeed GPU and as such any secondary GPU is initialised as the primary display. Qubes installer (and booting into Qubes) runs great with the internal GPU disabled. |
@Tonux599 my point here is that you use nouveau, I use radeon... This is a server board having ASPEED by default, which can be configured to be used (ugly) but as is, without external additinal hardware. Kernel modules are not heavy and can be added in a workstation config and should be use case based. If you have PR, please propose. Else I will work on this this week cause I want to use this board, but again, use case of mine would be server+radeon for local display + Libremkey_notpm. I'm more challenging the good way to do this then anything else. In present thinking, I think i'll have to create kgpe_d16-bmc-radeon-libremkey_notpm, which will have console output to both bmc and tty0, linux drivers for radeon/aspeed, while not depending on network-recovery script but launching generic-init and having code to measure rom and validate through libremkey. This use case will permits disk unlocking via console/radeon while validating rom integrity without a TPM. |
https://github.com/osresearch/heads/blob/e62362ddcc6b0ea295b138c91c0b99805714ea13/boards/kgpe-d16/kgpe-d16.config#L27
That line could also add standard terminal by adding
console=tty0
@flammit What do you think?
For some reason, reflashing OpenBMC disabled it. Will dig into it, but meanwhile, I needed this.
The text was updated successfully, but these errors were encountered: