romansoft

Upgrade 6.1 to 6.2 on HP Gen8. Both baremetal & Proxmox. Serial port not working on 1.03b (proxmox).

Recommended Posts

Hi,

 

I have DSM 6.1 (1.02b loader) on HP Gen8. I'm using an usb stick (with synoboot.img burnt), which can work both on baremetal and Proxmox so I can switch between starting DSM on HP Gen8 without any virtualization layer, or starting DSM from Proxmox (running over HP Gen8). I'd recommend this environment so if your proxmox fails, you can pick up your phisical disks (I'm currently passing them thru to proxmox) and the usb stick and start directly in the server (even another new server!).

 

What's the procedure to update to DSM 6.2? I thought that new 1.03b loader would support both DSM 6.2 (and 6.1) so my idea was to burn 1.03b loader, start DSM 6.1, test new loader in that environment, and finally upgrade DSM (via GUI). But I tried it and it isn't working, so maybe I'm wrong with that, and 1.03b only support 6.2. Could somebody confirm?

 

And a second question: I was successfully using serial console on Proxmox to monitorize the booting process (qm terminal <vmid>) on 1.02b, but it seems not to work for 1.03b loader. Is this fact known? Any workaround?

 

Thank you for your help.

Share this post


Link to post
Share on other sites

For the serial connection to the VM I use this:

 

# in this example VM 101 is our guest to add serial console.

# set serial console for VM
qm set 101 -serial0 socket

# connect to VM from proxmox TTY session
socat UNIX-CONNECT:/var/run/qemu-server/101.serial0 STDIO,raw,echo=0,escape=0x0f

 

I don't know if loader 1.03b is also capable of running DSM < 6.2

Share this post


Link to post
Share on other sites

So are you confirming Proxmox's serial console works for you with 1.03b? (it didn't work for me).

 

My VM already has serial console defined (so your 1st cmd isn't necessary).

Could you run a "qm terminal 101" and tell me if that works for you? I think it should be equivalent to socat cmd.

 

For me, it doesn't work either "qm terminal" nor socat, with 1.03b (it works if I boot with 1.02b, as I already commented in my post).

 

Cheers,

-r

 

 

Share this post


Link to post
Share on other sites

Yes, I can confirm. Just tried it seconds ago. No problem. The "qm terminal 101" also gave me the same results.

 

I know I had to switch from "IDE" harddisks to "SATA" with 1.03b loader.

So for the migration I had to shutdown the DSM6.1 VM, detach the IDE HD en edit this to SATA. Then add it again and set new bootdisk.

 

Hope this helps you.

 

Share this post


Link to post
Share on other sites

My VM (Proxmox)'s disks are already SATA (physical disks being passed-thru). Boot/loader is USB-stick.

 

Could you paste your current config (or screenshot)?

 

Thx.

 

Share this post


Link to post
Share on other sites
root@proxmox2:/etc/pve/qemu-server# cat 103.conf
boot: c
bootdisk: sata0
cores: 4
memory: 512
name: DSM-test
net0: e1000=32:32:66:61:37:30,bridge=vmbr0,tag=101
numa: 0
ostype: l26
sata0: local:103/vm-103-disk-2.raw,size=50M
sata1: local:103/vm-103-disk-1.qcow2,size=8G
serial0: socket
smbios1: uuid=dec697d4-36e6-43de-a2e0-896db9f2dfe1
sockets: 1


 

Share this post


Link to post
Share on other sites

Thanks. Basically the difference with my setup is that your bootdisk is sata0 instead of usb.

 

It sounds weird that loader may not work propperly if run from usb? Or maybe is known behaviour for 1.03b?

 

Another point: simply booting 1.02b in proxmox, showed menu in serial console. But that doesn't happen with 1.03b. Shouldn't be the same?!?

 

Cheers,

-r

Share this post


Link to post
Share on other sites
Posted (edited)

I have no experience with booting from USB inside Proxmox. I think that it should not matter what bootdevice you use. You can try the 50MB Sata loader and see if that will help.

 

With my setup I can access the terminal when booting so somewhere something is different. :)

Edited by marigo

Share this post


Link to post
Share on other sites

I've been iddle some time but I'm coming back with some responses I discovered by researching this a little bit.

 

1/ In order to have a *full* serial console, you need to uncomment/comment these lines in grub.cfg:

set extra_args_3617='earlycon=uart8250,io,0x3f8,115200n8 earlyprintk loglevel=15'
#set extra_args_3617=''

Then you can observe the complete boot process with a simple "qm terminal <vmid>".

 

2/ When doing so, I discovered what was happening:

[    0.000000] NX (Execute Disable) protection: active
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.105 #23739
[    0.000000]  ffffffff814b6c18 ffffffff8187b1a1 0000000000000001 0000000000000001
[    0.000000]  00000000366b1000 000000000194f000 0000000000000bff fffffffeffbcd000
[    0.000000]  0000000100000000 0000000000000000 0000000000000000 000000000000000e
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff814b6c18>] ? dump_stack+0xc/0x15
[    0.000000]  [<ffffffff8187b1a1>] ? early_idt_handler_common+0x81/0xa8
[    0.000000]  [<ffffffff8188c20e>] ? efi_init+0x238/0x476
[    0.000000]  [<ffffffff8188c1fb>] ? efi_init+0x225/0x476
[    0.000000]  [<ffffffff8187f091>] ? setup_arch+0x43d/0xc50
[    0.000000]  [<ffffffff814b5f8b>] ? printk+0x4a/0x52
[    0.000000]  [<ffffffff8187b957>] ? start_kernel+0x7b/0x3b0
[    0.000000] RIP 0xfffffffeffbcd000

I.e., I was getting a kernel-crash at the very beginning of the kernel-loading stage.

 

I compared the crash with a normal kernel-loading, like this:

[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x1ffdf max_arch_pfn = 0x400000000

...

 

So in the first case, kernel is crashing at BIOS check phase.

 

I reviewed Proxmox VM config and I came across the root cause: 1.03b loader fails to boot when OVMF bios is selected. It works only when SeaBIOS is selected (which is Proxmox's default).

 

Why am I currently using OVMF over SeaBIOS? Because only OVMF permits to permanently define a USB device as primary boot device, and I need this in order to boot from my USB stick.

 

I've just emailed Jun with this info in order to know whether this is a known issue with 1.03b (the issue doesn't exist in 1.02b) and whether we could expect a fix.

 

I'll update this post in case I have positive feedback :)

 

Cheers,

-r

Share this post


Link to post
Share on other sites

Hey, great that you have found the issue.

I use the "default" SeaBIOS so that's why I don't had any problem. :)

 

In the meantime you can use 1.03b with a sata drive as the boot disk.

Share this post


Link to post
Share on other sites

I found a solution which permits me to boot my USB stick :)

 

Simply I created a CD image (.iso) with plop (https://www.plop.at/en/bootmanager/index.html) with the sole funtion of booting USB (similar to "chainloading" with grub2). I've attached the .iso here (just in case somebody needs it; happens that it also will work -not tested, though- even if your BIOS doesn't support USB boot at all -old BIOSes-).

 

Now simply add a CDROM device to your Proxmox VM and select this .iso as image.

 

Finally, configure: Options -> Boot order -> CDROM.

 

You are done :)

 

Whenever you start the VM, it will boot to cdrom, which in turn will jump into USB boot. Simple.

 

The only (minor) drawback I've found with this method is that Jun's loader cannot hot-update its grub config/env (for any reason I don't still get, grub cannot write to disk [*]), so you cannot "save" the default choice in Jun's loader menu. But to be honest, it doesn't hurt too much (just edit Jun's loader .img "offline" and select another default if you need it).

 

[*] You'll get an error by grub but you can ignore it. You'll also be prompted to press a key but you can ignore too (after ~5 secs, booting will resume automagically :-)). Btw, you can get rid of both error and press-key prompt by editing Jun's image and simply deleting (or renaming) grub/grubenv file ("ren grub/grubenv grub/grubenv_OFF" will do the trick). After doing so, Jun's loader (grub) won't autosave chosen menu option.

 

 

plpbt-usbboot.iso

Edited by romansoft

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now