| View previous topic :: View next topic |
| Author |
Message |
DeadToRight
n00b
Joined: 28 Jun 2018
Posts: 22
|
 Posted: Sat Jul 21, 2018 4:11 pm Post subject: [Solved] Booting Xen - no console will be available to OS |
 |
|
So, I'm running on a dm-crypted software RAID setup. Having to run a custom initramfs seems to be hurting me.
| emerge -pv xen xen-tools wrote: | These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] app-emulation/xen-tools-4.11.0:0/4.11::gentoo USE="flask hvm ovmf pam qemu qemu-traditional screen sdl -api -custom-cflags -debug -doc -ocaml -pygrub -python -static-libs -system-qemu -system-seabios" PYTHON_TARGETS="python2_7" 0 KiB
[ebuild R ~] app-emulation/xen-4.11.0::gentoo USE="efi flask -custom-cflags -debug" 0 KiB
Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB |
When booting on GRUB (from a flash-drive):
| boot process wrote: |
Loading Xen xen . . .
WARNING: no console will be available to OS
Loading Linux 4.17.8-gentoo . . .
|
From there, the OS boots along the same lines. It provides the same output as if I were booting directly to the kernel intended as a Dom0. At least, until we hit this line in the initramfs:
| initramfs/init wrote: | | cryptsetup -T 3 <options-extraneous> open first.key keys-holder |
This line in my initramfs/init demands human-input from the console to open up a dm-crypt-ed partition/file that contains the drive keys. This is the same line for this purpose used in any of the LUKS-enabled initramfs options available.
I'm not quite sure how to resolve this - google only brings up examples where someone:
a) "removed their need for the console"
b) were simply told "That's not how we boot Citrix Xenserver!"
c) was met with *crickets*
d) was told to ssh into their box during the init procedure to address this.
e) open up another console to see if you can input there!
None of these satisfactorily addressed the issue. This wifi-only box needs to be booted to attach to a network to ssh in. Spawning another console didn't let me input a password to the process spawned on the first (and I'm nervous about doing that in an initrd...)
Any ideas? I'm at a loss.
Last edited by DeadToRight on Mon Jul 23, 2018 7:56 pm; edited 1 time in total |
|
| Back to top |
|
 |
DeadToRight
n00b
Joined: 28 Jun 2018
Posts: 22
|
| Posted: Sat Jul 21, 2018 8:57 pm Post subject: |
|
|
Deeper googling presented a few other options.
The bios is already up to date, so that's... one more suggestion down.
Another pass at the various GRUB_CMDLINE_XEN= and related options for use in /etc/default/grub may be worthwhile.
| Quote: | | grep --color -E "vmx|svm" /proc/cpuinfo |
shows svm and svm_lock in the cpu's capabilities for all cores. Double-checking seemed worthwhile.
It may potentially be an incompatibility with UEFI.
Well... since the bootloader is on a flash drive and I've got another one spare? I guess I'm gonna see if I can revert to the old bios-boot method on a different usb key, rather than a UEFI method on the current flash drive. Hopefully using GPT partitions won't present too much of a challenge.
Will doing so negate any usefulness to a motherboard's TPM? I can worry about that later, but it'd be good to know about in advance.
GRUB_PLATFORMS="efi-64 multiboot pc xen" so there shouldn't be any need to completely rebuild grub with the right grub-install options.
The goal is to take advantage of PVH, so Direct Kernel Boot will also be necessary. Might need to rebuild xen/-tools for that. I'll double check if I need the python useflags. https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Direct-Kernel-Boot
This post may get better help from someone else,... or might just be mental project-hibernation swap-space. Either way we'll see.
Will report back when there is more to report. Meatspace responsibilities arise. |
|
| Back to top |
|
|
DeadToRight
n00b
Joined: 28 Jun 2018
Posts: 22
|
| Posted: Mon Jul 23, 2018 7:56 pm Post subject: |
|
|
When none of this solved the issue? I got to looking at other grub.cfg's posted elsewhere. That gave me the solution. As my system lacks a full fstab, grub was rather confused.
Adding the pieces "console=tty" and then "vt.handoff=3" to the "module" line which loads the dom0 kernel gave me the normal behavior I desire.
| grub.cfg wrote: |
multiboot /xen.gz placeholder dom0_mem=1024M,max:4096M
echo 'Loading Linux 4.17.9-gentoo ...'
module /vmlinuz-4.17.9-gentoo placeholder ro softlevel=xen console=tty quiet vt.handoff=3
|
Aaaand we BOOT! As my custom initramfs directly handles mounting the drives without input from Grub, any "root=" or "crypt_root=" or "crypt_device" is strictly unnecessary, but your mileage may vary, you probably don't want to delete those.
for commandline systems, vt.handoff=3
for direct-to-gui boot (make sure you've got a DE's login DM installed!), vt.handoff=7
now... lets put that into /etc/default/grub so that we don't ever have to manually do anything about it again.
| /etc/default/grub wrote: | | GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="softlevel=xen console=tty quiet vt.handoff=3" |
I wonder what the 'placeholder' is for in my grub.cfg right behind xen.gz? I guess I'll have to dig further into the docs.
Now, to dig back into the docs to find how I get the dom0 to run a 'startx' without quitting. memory out of range error. I know I've seen it somewhere in the docs... |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 483
Location: Salem, OR
|
| Posted: Sat Feb 23, 2019 11:39 pm Post subject: |
|
|
I've run into the same problem: I receive a "no console will be available" message and the kernel loading goes into state of nothingness; I have to push the reset button to force a reboot.
I'm on UEFI running Xen and found that the grub configuration file /etc/grub.d/20_linux_xen has an if clause (nested in a sed line) at line 118:
| Code: | sed "s/^/$submenu_indentation/" << EOF
echo '$(echo "$xmessage" | grub_quote)'
if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
multiboot ${rel_xen_dirname}/${xen_basename} placeholder ${xen_args} \${xen_rm_opts}
echo '$(echo "$lmessage" | grub_quote)'
module ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
EOF
|
I inserted this line to determine which portion of the "if" clause was being triggered:
| Code: | | echo '$(echo "grub_platform = $grub_platform")' |
On my start-up the value of $grub_platform is posted as "efi", so the "else" clause was being activated. I also inserted code in the "else" clause making the value of xen_rm_opts empty just like the "if" clause to determine if the omission of the values "no-real-mode edd=off" caused the "no console..." message to go away. It did not, the warning message of "no console" continues. Looks like the "no console" is coming from within the kernel. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 483
Location: Salem, OR
|
| Posted: Sat Feb 23, 2019 11:57 pm Post subject: |
|
|
| Quote: | | Looks like the "no console" is coming from within the kernel. |
The above is inaccurate. In reviewing my notes, I determined that the posting
| Quote: | | WARNING: no console will be available to OS |
comes from the execution of this line in my /boot/grub/grub.conf:
| Code: | | multiboot /xen-4.gz placeholder ${xen_rm_opts} |
|
|
| Back to top |
|
|
|
Portage & Programming
