Mailing List Archive

I am having the very same kind of problem using Gentoo.  About two years
ago, I was able to build a xen kernel in Gentoo and start a Dom0
instance by using UEFI command line.  At that time, GRUB2 did not
support UEFI.  For the sake of brevity, I am having the very same
problem now as depicted by Mr. Baixauli as I upgraded the kernel (to
4.19.23-gentoo) and wanted to get the system to boot up without my
manual intervention.  I've built a kernel which successfully boots for a
regular Gentoo session using Grub2, but when I try to launch the Dom0
version, I'm cut off at the initial posting with no record and having to
push the reset button.  I did make progress because I hard-wired the
location of the root drive into the kernel using the Partition ID - see
https://wiki.gentoo.org/wiki/EFI_stub_kernel

And I made some progress, the boot up gets past the "Cannot find FS...",
but then it hangs thereafter.

My current solution is: I've ordered a serial to USB connector so I can
monitor and capture the boot postings to help further identify the
problem.  I'll then be staging the emerge builds, the kernel
configuration, the kernel build log, and the boot posting with
appropriate questions either here and/or the Gentoo Forum seeking help
so all the information will be available to one considering my question.
I'm certain the problem I'm having concerns the file system differences.

I wanted to respond here just to you let you know you are not alone and
I'm hopeful once I capture the boot postings, I'll be closer to
identifying the problem and obtaining help.  I'm hoping that in the next
week I'll have a nice package to present for a plea of help.

On 2/25/2019 10:16 AM, Enrique Sainz Baixauli wrote:
> Hi!
>
> I am very new to Xen, trying to set up my laptop with Xen using the
> EFI image that comes with Ubuntu package xen-hypervisor-4.9-amd64.
>
> I have managed to boot the image by modifying efibootmgr options and
> adding a new entry there. However, when trying to boot that entry, it
> first prints out how it loads xen hypervisor, its config file, the
> Linux kernel and the initramfs, and two more lines with hex digits
> that I can't read because they disappear too fast. And then it goes
> blank. It stays blank for a few seconds and finally a white blinking
> cursor shows up in the top left corner of the screen. Then I have to
> Ctrl+Alt+Del to reboot, as I get nothing else.
>
> What I have done:
>
> 1. Install Ubuntu package xen-hypervisor-4.9-amd64.
> 2. Create a new directory "xen" under /boot/efi/EFI with the
> following files:
> 1. xen-4.9-amd.efi
> 2. vmlinuz-4.15.0-45-generic
> 3. initrd.img-4.15.0-45-generic
> 4. xen.cfg, with the following content:
>
> [global]
> default=ubuntu
>
> [ubuntu]
> options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152 loglvl=all
> kernel=vmlinuz-4.15.0-45-generic root=UUID=24bd5658-bf88-41ae-85e7-11ea902a3c50= ro vt.handoff=7 console=hvc0
> ramdisk=initrd.img-4.15.0-45-generic
> 3. Added the new entry with the command efibootmgr -c -d /dev/nvme0n1
> -L Xen -l "\EFI\xen\xen-4.9-amd64.efi"
>
> All of this following the UEFI guide at Xen wiki:
> https://wiki.xenproject.org/wiki/Xen_EFI
>
> My guess is that the config in xen.cfg is not adequate for booting
> Ubuntu. But the list of options
> (https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html) is so long I
> have no idea how to write a proper config file.
>
> Can anyone shed some light on this? Or some way to get any debug
> information from the boot process inside Xen? I am totally clueless here.
>
> Thanks!
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-users
--
Email Rider

John Laurence Poole
Salem OR 97301-4241
707-812-1323 office

>> Can anyone shed some light on this? Or some way to get any debug
>> information from the boot process inside Xen? I am totally clueless here.

I recently ended up with no-longer-bootable Xen on EFI, where it had worked well before.

The fix, for me, required applying a patch to upstream version of libefivar1,

https://github.com/rhboot/efibootmgr/commit/99b578501643377e0b1994b2a068b790d189d5ad

more detail here,

https://bugzilla.opensuse.org/show_bug.cgi?id=1122044

Don't know if the following is helpful/relevant to *your* particular situation (different versions of, well, everything), but since is IS in the "*used* to boot on EFI, until recently" category ... maybe something will help.

My relevant/current setup is,

lsb_release -rd
Description: openSUSE Leap 15.0
Release: 15.0

uname -rm
4.20.12-lp150.2.gb35c1fc-default x86_64

cat /boot/grub2/xen-4.12.0_03-lp150.628.cfg
[global]

[config.1]
options=dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcpus=4 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 reboot=acpi ucode=scan iommu=verbose

kernel=vmlinuz-4.20.12-lp150.4.gb35c1fc-default root=/dev/mapper/VG0 softlevel=xen rd.shell rd.debug=0 rd.udev.log_priority=debug rd.auto=1 dolvm lvmwait=/dev/mapper/VG0 root=/dev/mapper/VG0 rootfstype=ext4 rootflags=journal_checksum noresume nomodeset xencons=xvc console=tty0 console=hvc0 clocksource=xen scsi_mod.use_blk_mq=1 elevator=mq-deadline showopts noquiet systemd.log_target=kmsg earlyprintk=xen,keep

ramdisk=initrd-4.20.12-lp150.4.gb35c1fc-default

efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* suse-xen HD(2,GPT,9858f77d-e12d-3d71-55c5-1c471746c47b,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* UEFI: Built-in EFI Shell VenMedia(5155b11d-dc11-c587-d118-ce1d644c8053)..BO

tree /boot/efi/
/boot/efi/
??? [root 4096] EFI
? ??? [root 4096] opensuse
? ??? [root 142848] grubx64.efi
? ??? [root 685] grub.xen-files
? ??? [root 18333332] initrd-4.20.12-lp150.4.gb35c1fc-default
? ??? [root 8228280] vmlinuz-4.20.12-lp150.4.gb35c1fc-default
? ??? [root 5342] xen-4.12.0_03-lp150.628.cfg
? ??? [root 2727072] xen-4.12.0_03-lp150.628.efi
??? [root 30] startup.nsh

cat /boot/efi/startup.nsh
fs0:\EFI\opensuse\grubx64.efi

mount | grep -i efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

rpm -qa | egrep -i "xen|qemu|efi|grub|ovmf" | sort
efibootmgr-999.git.20180613.99b5785-lp150.5.11.x86_64
efivar-devel-999.git.20190107.8f80379-lp150.4.11.x86_64
grub2-2.02-lp150.62.1.x86_64
grub2-i386-pc-2.02-lp150.62.1.noarch
grub2-systemd-sleep-plugin-2.02-lp150.62.1.noarch
grub2-x86_64-efi-2.02-lp150.62.1.noarch
grub2-x86_64-xen-2.02-lp150.62.1.noarch
libefivar1-999.git.20190107.8f80379-lp150.4.11.x86_64
ovmf-2019+git1550452308.c417c1b33d06-lp150.95.1.x86_64
ovmf-tools-2019+git1550452308.c417c1b33d06-lp150.95.1.x86_64
qemu-3.1.0-lp150.502.5.x86_64
...
qemu-linux-user-3.1.0-lp150.502.1.x86_64
qemu-ovmf-x86_64-2019+git1550452308.c417c1b33d06-lp150.95.1.noarch
qemu-seabios-1.12.0-lp150.502.5.noarch
...
qemu-tools-3.1.0-lp150.502.5.x86_64
qemu-vgabios-1.12.0-lp150.502.5.noarch
qemu-x86-3.1.0-lp150.502.5.x86_64
xen-4.12.0_03-lp150.628.3.x86_64
xen-libs-4.12.0_03-lp150.628.3.x86_64
xen-tools-4.12.0_03-lp150.628.3.x86_64


Note in particular those efi *999.git* patched versions ...

_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

Thanks PGNet Dev and Mr. Poole for your answers.

So, it seems that console=vga,com1 is not enough to show the boot process
output on screen and we need a serial cable to debug, is that correct? If
so, I will wait for Mr. Poole's feedback. FWIW, I also tried console=vga
(without com1) and the screen was as blank as before.

However, I am concerned about the different versions of "everything" we
have, most importantly Xen. I am using 4.9 because that's what's being
shipped with Ubuntu, but if PGNet Dev's issue is the same as mine, the
issue exists at least in 4.9 and in 4.12. And I guess Mr. Poole is using
gentoo's stable xen package, which is 4.10.2 (
https://packages.gentoo.org/packages/app-emulation/xen).

What I mean is, has no one noticed this before or are we all doing
something wrong? Or did this issue come with a kernel update instead of xen?

Again, thanks everyone for reading and adding whatever info you may find
useful.

Cheers!

On 2/27/19 3:50 AM, Enrique Sainz Baixauli wrote:
> Thanks PGNet Dev and Mr. Poole for your answers.

Just to be clear, with 'my config', and in particular the use of the patched efi package, my system boots once again without error.

I _do_ get output on console -- to login prompt -- with video configured & verbosity defined by logging flags, in my /etc/default/grub.

E.g., currently, my last grub config used for detailed boot debugging/logging included:


GRUB_CMDLINE_LINUX="
...
rd.shell rd.debug=1 rd.udev.log_priority=debug rd.auto=1 \
...
video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 \
console=tty0 console=ttyS0,115200n81 \
showopts noquiet log_buf_len=10M print_fatal_signals=1 \
systemd.log_level=debug systemd.log_target=kmsg \
earlyprintk=vga,keep debug loglevel=8" \
...
"

GRUB_CMDLINE_LINUX_XEN_REPLACE="softlevel=xen
...
rd.shell rd.debug=1 rd.udev.log_priority=debug rd.auto=1 \
...
video=vesa:off video=efifb:1024x768 \
xencons=xvc console=tty0 console=hvc0 \
showopts noquiet log_buf_len=10M print_fatal_signals=1 \
systemd.log_level=debug systemd.log_target=kmsg \
earlyprintk=xen,keep debug loglevel=8" \
"

GRUB_CMDLINE_XEN="
...
vga=gfx-1920x1080x16 \
com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 \
log_buf_len=16M \
loglvl=all guest_loglvl=all sync_console=true sched_debug iommu=verbose apic_verbosity=verbose \
...
"

GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
GRUB_GFXMODE=2560x1440,1600x1200,1280x1024,1024x768,auto
GRUB_GFXPAYLOAD_LINUX="keep"
GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"

You can tweak logging flags to your heart's content, but to get 'complete', early logging as well, serial port is required -- and works nicely with the config above.

I'm able to login successfully to the booted machine at serial console, video console -- or SSH login.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

>
> Just to be clear, with 'my config', and in particular the use of the patched efi package, my system boots once again without error.
>
>
I had overlooked how different your config is from mine. I see your EFI
bootloader is loading grub efi file, then I guess grub loads (chainloads?)
xen hypervisor (gz image or efi file?).

When I tried anything like that, with the setup provided by the Ubuntu
update-grub script and the xen package script for grub, it tried to load
the gz image. The boot process got stuck in "Loading initial ramdisk" and
nothing else would ever happen. It wouldn't even respond to Ctrl+Alt+Del
(which my current setup, booting the efi file from the EFI bootloader
directly, does), so I had to hold the power button to reboot.

Then I tried loading the xen efi file from grub, which resulted in a magic
number mismatch. It wouldn't even try to load the kernel after that, so no
way anyway.

So... how do you get grub to load the xen hypervisor?

> So... how do you get grub to load the xen hypervisor?

Not entirely clear what you're asking ...

If you've multiple boot options, grub needs to be told which config to load -- either selected at the menu manaully, or set as its default selection.

Verify all your menuentry,

grep -i menuentry /boot/grub2/grub.cfg
...

and that the right one's selected,

grep saved_entry /boot/grub2/grubenv
saved_entry=xen-gnulinux-simple-4c0d851f-c586-1a2a-4976-488765f65863

&/or set manually with

grub2-set-default

The grub (re)install process should populate the bootloader

/boot/efi/EFI/opensuse/grubx64.efi
file /boot/efi/EFI/opensuse/grubx64.efi
/boot/efi/EFI/opensuse/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows

The efi env is pointed to the correct bootloader, e.g. after a kernel update, with the following command

efibootmgr --create --quiet \
--disk /dev/sde \
--part 2 \
--loader '\EFI\opensuse\grubx64.efi' \
--label "suse-xen"

where,

mount | grep /boot/efi | grep vfat
/dev/sde2 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,x-systemd.automount)

Note also

cat efi/startup.nsh
fs0:\EFI\opensuse\grubx64.efi

where, fs0: <=== the efi partition mount,


The script execs automatically when the EFI shell environment is opened, and loads the 'grubx64.efi',
The use of the startup.nsh was (is still?) a holdover necessary to resolve prior/recurring problems with the wonky efi loader. Simply -- for me -- it ensures that the script -- and therefore grub->xen -- loads, instead of dropping me to the EFI prompt.




_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

>
> Not entirely clear what you're asking ...
>

Ok, I will try to explain myself. As far as I have been trying, my
(Ubuntu's default) grub setup is configured to load via multiboot either
the gz or the efi files of the xen hypervisor:

menuentry 'Ubuntu GNU/Linux, with the Xen hipervisor' ... {
...
multiboot /boot/xen-4.9-amd64.gz placeholder ${xen_rm_opts}
...
}
...
menuentry 'Ubuntu GNU/Linux, with Xen 4.9-amd64.efi y Linux
4.15.0-45-generic' ... {
...
multiboot /boot/xen-4.9-amd64.efi placeholder ${xen_rm_opts}
...
}

With both these menuentries I get a frozen system right after the grub
menu. The first one gets stuck at 'Loading initial ramdisk', with the
system not responding to anything and having to hold the power button. With
the second one, the xen hypervisor refuses to load because of a magic
number mismatch and lets me push any button to go back to the grub menu.

I believe the problem is that multiboot does not support enough parameters
to load Xen, and multiboot2 should be used for that. As I can't seem to
find some kind of automated way of configuring grub in Ubuntu to use
multiboot2 I switched to the other way the wiki suggests to boot the
hypervisor: using the EFI bootloader directly: one entry to boot Xen with
the Ubuntu kernel as dom0 and another one for grub and Ubuntu without Xen:

$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0002,0000
Boot0000* Windows Boot Manager
VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...\a...............
Boot0002* Xen
HD(1,GPT,097131f3-90b4-42f9-b35e-e25f7aac17e2,0x800,0x100000)/File(\EFI\XEN\XEN.EFI)
Boot0004* ubuntu
HD(1,GPT,097131f3-90b4-42f9-b35e-e25f7aac17e2,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)

So entry 0004 is the one I am using to boot Ubuntu, while 0002 hangs with
the issue I described in my first mail: blank screen, no boot information
printed (I understand now it would be sent over a serial interface if I had
one) and ending up in a blank screen with a white blinking cursor in the
top left corner.

That's why I asked about your grub configuration to load Xen: are you using
your default distro's config? Is it multiboot or multiboot2? Does it boot
the gz image or the efi file?

Thank you very much for your answers.

> about your grub configuration to load Xen:
> are you using your default distro's config?

my distro is

lsb_release -rd
Description: openSUSE Leap 15.0
Release: 15.0

but my relevant pkgs are newer than distro release versions, each sourced from here:

Kernel, Efi
https://build.opensuse.org/project/show/home:pgnd:Kernel:stable

Xen, Qemu
https://build.opensuse.org/project/show/home:pgnd:Virtualization:Xen
https://build.opensuse.org/project/show/home:pgnd:Virtualization:qemu

Grub2
https://build.opensuse.org/package/show/home:pgnd:grub2/grub2

> Is it multiboot or multiboot2?

The grub multiboot modules are available

find /usr/share/grub2/x86_64-efi -name *multiboot*
/usr/share/grub2/x86_64-efi/multiboot.module
/usr/share/grub2/x86_64-efi/multiboot2.module
/usr/share/grub2/x86_64-efi/multiboot.mod
/usr/share/grub2/x86_64-efi/multiboot2.mod

grep multiboot /boot/grub2/x86_64-efi/command.lst
module2: multiboot2
module: multiboot
multiboot2: multiboot2
multiboot: multiboot

but, reading

https://wiki.xenproject.org/wiki/Xen_EFI

current Grub2.02, here, apparently lacks the multiboot2-enabling patch

[.Inspect the grub.cfg. Make sure that it has 'multiboot2' and 'module2' for Xen. You may need the patch titled: [PATCH] Use grub-file to figure out whether multiboot2 should be used for Xen.gz See [1]

[1] https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt

The grub2-bundled xen config,

cat /etc/grub.d/20_linux_xen

does reference `multiboot`, but NOT in the efi case,

192 if $is_efi; then
...
224 chainloader ${rel_efi_dir}/${xen_basename} ${xen_basename} ${SUSE_CMDLINE_XENEFI} $section
...
232 fi

using, instead, the chainloader.

Checking, the *generated* ('default' insofar as it's not manually modified) config does use the chainloader,

cat /boot/grub2/grub.cfg
...
### BEGIN /etc/grub.d/20_linux_xen ###
menuentry 'OpenSUSE, with Xen hypervisor' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd4,gpt2 --hint-efi=hd4,gpt2 --hint-baremetal=ahci4,gpt2 --hint='hd0,gpt2' 62B1-21F3
else
search --no-floppy --fs-uuid --set=root 62B1-21F3
fi
echo 'Loading Xen 4.12.0_03-lp150.628 with Linux 4.20.13-lp150.2.gfb7c4a5-default ...'
chainloader /efi/opensuse/xen-4.12.0_03-lp150.628.efi xen-4.12.0_03-lp150.628.efi /mapbs config.1
}
submenu 'Advanced options for OpenSUSE (with Xen hypervisor)' $menuentry_id_option 'gnulinux-advanced-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
submenu 'Xen hypervisor, version 4.12.0_03-lp150.628' $menuentry_id_option 'xen-hypervisor-4.12.0_03-lp150.628-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
menuentry 'OpenSUSE, with Xen 4.12.0_03-lp150.628 and Linux 4.20.13-lp150.2.gfb7c4a5-default' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-4.20.13-lp150.2.gfb7c4a5-default-advanced-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd4,gpt2 --hint-efi=hd4,gpt2 --hint-baremetal=ahci4,gpt2 --hint='hd0,gpt2' 62B1-21F3
else
search --no-floppy --fs-uuid --set=root 62B1-21F3
fi
echo 'Loading Xen 4.12.0_03-lp150.628 with Linux 4.20.13-lp150.2.gfb7c4a5-default ...'
chainloader /efi/opensuse/xen-4.12.0_03-lp150.628.efi xen-4.12.0_03-lp150.628.efi /mapbs config.2
}
menuentry 'OpenSUSE, with Xen 4.12.0_03-lp150.628 and Linux 4.20.12-lp150.5.g5cf91fd-default' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-4.20.12-lp150.5.g5cf91fd-default-advanced-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd4,gpt2 --hint-efi=hd4,gpt2 --hint-baremetal=ahci4,gpt2 --hint='hd0,gpt2' 62B1-21F3
else
search --no-floppy --fs-uuid --set=root 62B1-21F3
fi
echo 'Loading Xen 4.12.0_03-lp150.628 with Linux 4.20.12-lp150.5.g5cf91fd-default ...'
chainloader /efi/opensuse/xen-4.12.0_03-lp150.628.efi xen-4.12.0_03-lp150.628.efi /mapbs config.3
}
menuentry 'OpenSUSE, with Xen 4.12.0_03-lp150.628 and Linux 4.20.12-lp150.4.gb35c1fc-default' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-4.20.12-lp150.4.gb35c1fc-default-advanced-8d1e6d0f-a6d7-4bb2-8465-676586d534e' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd4,gpt2 --hint-efi=hd4,gpt2 --hint-baremetal=ahci4,gpt2 --hint='hd0,gpt2' 62B1-21F3
else
search --no-floppy --fs-uuid --set=root 62B1-21F3
fi
echo 'Loading Xen 4.12.0_03-lp150.628 with Linux 4.20.12-lp150.4.gb35c1fc-default ...'
chainloader /efi/opensuse/xen-4.12.0_03-lp150.628.efi xen-4.12.0_03-lp150.628.efi /mapbs config.4
}
}
}

### END /etc/grub.d/20_linux_xen ###
...

> Does it boot the gz image or the efi file?

from above, it chainloads the .efi

Atm, I've no idea _why_ Grub2 doesn't use multiboot2 with Xen/EFI.

There's this Redhat thread,

Bug 1486002 - grub2-mkconfig does not work if xen.gz is installed.
https://bugzilla.redhat.com/show_bug.cgi?id=1486002

which _may_ shed some light. Maybe cc @ Konrad can comment further?


_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

I set out two goals: 1) to monitor via a serial port (serial on Linux to
USB on Windows with the StarTech.com 1 Port FTDI USG to RS232 Serial
Null MOdem Adapter Cable -- puchased at Amazon), and 2) monitor xen
boot-up via serial port.

I was able to plug in and monitor using PuTTY on Windows, but when the
initramfs kicked in, nothing appeared on my serial port. I could see
Grub, the EFI shell.  So I disengaged framebuffer support in my kernel
(setting console display driver support-->framebuffer to empty) and
recompile, then I started seeing the output of the initramfs.

My regular Linux kernel line (at https://pastebin.com/W3ASmFtv for 30
days)  is this:

echo 'Loading Linux x86_64-4.19.23-gentoo ...'
        linux /kernel-genkernel-x86_64-4.19.23-gentoo root=/dev/sda4 ro
console=tty0 console=ttyS0,115200n8 showopts noquiet log_buf_len=10M
print_fatal_signals=1 earlyprintk=vga,keep debug loglevel=8
echo 'Loading initial ramdisk ...'
        initrd /initramfs-genkernel-x86_64-4.19.23-gentoo

My xen kernel line is this:


multiboot /xen.gz placeholder vga=gfx-1920x1080x16 com1=115200,8n1,pci
console=com1,vga console_timestamps console_to_ring conring_size=64
log_buf_len=16M loglvl=all guest_loglvl=all sync_console=true
sched_debug iommu=verbose apic_verbosity=verbose ${xen_rm_opts}

echo 'Loading Linux x86_64-4.19.23-gentoo ...'
        module /kernel-genkernel-x86_64-4.19.23-gentoo placeholder
root=/dev/sda4 ro softlevel=xen video=vesa:off video=efifb:1024x768
xencons=xvc console=tty0 console=hvc0   showopts noquiet log_buf_len=10M
print_fatal_signals=1 earlyprintk=xen,keep debug loglevel=8
echo 'Loading initial ramdisk ...'

        module --nounzip /initramfs-genkernel-x86_64-4.19.23-gentoo

Select portion of my /etc/default/grub (full file at
https://pastebin.com/Ctuug0xk for 30 days) are:

================== start =================

# Uncomment to disable graphical terminal (grub-pc only)
# 3/3/19 jlpoole: uncommented below; added "serial" as 2nd parameter
# per: https://wiki.archlinux.org/index.php/working_with_the_serial_console
#
GRUB_TERMINAL="console serial"
#
# 3/3/19 jlpoole: added line below because running
#    grub-mkconfig -o /boot/grub/grub.cfg
# caused:
# Warning: Requested serial terminal but GRUB_SERIAL_COMMAND is
unspecified. Default parameters will be used.
#
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no
--stop=1"
...

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
kernel
# 3/3/19 jlpoole: uncommented below
GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
# 3/3/19 jlpoole: uncommented below
GRUB_DISABLE_RECOVERY=true
...

GRUB_CMDLINE_LINUX_XEN_REPLACE="softlevel=xen \
        video=vesa:off video=efifb:1024x768 \
        xencons=xvc console=tty0 console=hvc0 \
        showopts noquiet log_buf_len=10M print_fatal_signals=1 \
        earlyprintk=xen,keep debug loglevel=8 \
       "
GRUB_GFXMODE=auto
GRUB_GFXPAYLOAD_LINUX="keep"
GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_CMDLINE_XEN=" \
        vga=gfx-1920x1080x16 \
        com1=115200,8n1,pci console=com1,vga console_timestamps
console_to_ring conring_size=64 \
        log_buf_len=16M \
        loglvl=all guest_loglvl=all sync_console=true sched_debug
iommu=verbose apic_verbosity=verbose \
       "zeta /home/jlpoole #
======================= end ======================

Observations:
-  I found that if I go into edit mode in Grub form the serial console
running on Windows 7 using PuTTY, things go screwy.  I'm using 115200
baud.  If I want to edit grub at the commencement of a boot using the
editor in grub, I have to do so with the keyboard and screen attached to
the server.
-  Under  the current setup, initramfs only shows up in the serial
console, not on the screen connected to the server
- I see some doubling up of messages on the console before the initramfs
output
- Sometimes the connection goes dead, I am using an extension cord, 10
feet?, from the server to my Windows box.
- The recent posting in this newsgroup of PGNet Dev on 2/27/2019, 5:29
AM was essential to my success, I was getting desperate, so I copied the
values from that email and voila... I had my first successful boot to
"login:"  (Thank you PGNet DEV!!!)
- using debug causes two drop-in shells where you have to type "exit" +
enter to return to normal processing
- I've posted another topic on this forum entitled "Boot Sometimes Hangs
At "masked EXTINT" (Varies)" and I'm not certain my problem is the
kernel stopping, or my serial port.  I'm pretty sure it's the kernel.
- I spent well over 20 hours to get to this point
- the documentation on some of the xen helped give me insight:
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#dbgp but
I found some explanations hard to understand (too concise?)

John

On 2/27/2019 3:50 AM, Enrique Sainz Baixauli wrote:
> Thanks PGNet Dev and Mr. Poole for your answers.
>
> So, it seems that console=vga,com1 is not enough to show the boot
> process output on screen and we need a serial cable to debug, is that
> correct? If so, I will wait for Mr. Poole's feedback. FWIW, I also
> tried console=vga (without com1) and the screen was as blank as before.
>
> However, I am concerned about the different versions of "everything"
> we have, most importantly Xen. I am using 4.9 because that's what's
> being shipped with Ubuntu, but if PGNet Dev's issue is the same as
> mine, the issue exists at least in 4.9 and in 4.12. And I guess Mr.
> Poole is using gentoo's stable xen package, which is 4.10.2
> (https://packages.gentoo.org/packages/app-emulation/xen).
>
> What I mean is, has no one noticed this before or are we all doing
> something wrong? Or did this issue come with a kernel update instead
> of xen?
>
> Again, thanks everyone for reading and adding whatever info you may
> find useful.
>
> Cheers!
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-users
--
Email Rider

John Laurence Poole
1566 Court ST NE
Salem OR 97301-4241
707-812-1323 office