All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
PV Grub 64 on Host Virtual
I've been using Host Virtual for years, but I recently tried to use my own kernel for the first time. The experience has been miserable: I can't seem to get any 64bit kernel to boot using Host Virtual's PVGRUB 64 Boot Type option.
I originally tried using a GRSecurity kernel, and made the mistake of telling Host Virtual Support about this, and now they refuse to assist me (they placed my ticket "On Hold" and told me they had already gone out of their way to help me). I specifically told them I tried a vanilla source kernel after that, and got the same results, but they are ignoring me.
Full details: I am trying to use a 64 bit Xen PV 3.14.36 kernel with or without GRSecurity, I setup my menu.lst in /boot, and when I boot with PV Grub 64 the machine instantly powers off so quickly that I cannot see anything on the console. Host Virtual support sent me a crash dump with no symbols and an error that appears to be coming from pvgrub itself, something I cannot diagnose.
Has anyone got a custom 64bit kernel to work with Host Virtual's PVGRUB 64 Boot Type and can share their configuration? Does anyone have suggestions for dealing with their support?
Thanks!
Comments
The last time I saw something like this, it had to do with /tmp being full.
Post the crash dump?
Not sure if I should edit the post or do this in a comment, but here we go:
Crash dump:
Page fault at linear address 0xfffffffffc1afcfc, rip 0x9439, regs 0xfc1adc08, sp 0xfc1adcb8, our_sp 0xfc1adbd0, code 0
Thread: main
RIP: e030:[<0000000000009439>]
RSP: e02b:00000000fc1adcb8 EFLAGS: 00010202
RAX: 0000000000000052 RBX: 00000000fc1afd1c RCX: 0000000000000000
RDX: 0000000000000001 RSI: fffffffffc1afcfc RDI: 000000000006ae38
RBP: 00000000fc1adcb8 R08: 0000000000000000 R09: 0000000000003ff0
R10: 000000000000003f R11: 00000000000689e0 R12: 00000000fc1afce8
R13: 0000000000000000 R14: 000000000096f9f5 R15: 00000000fc1aff80
base is 0xfc1adcb8 caller is 0x167dbbase is 0xfc1afde8 caller is 0xac72
base is 0xfc1afdf8 caller is 0xc00d
base is 0xfc1afe08 caller is 0xc065
base is 0xfc1afe28 caller is 0xc734
base is 0xfc1afe88 caller is 0x108f3
base is 0xfc1aff48 caller is 0x41a2
base is 0xfc1aff58 caller is 0x4458c
base is 0xfc1affe8 caller is 0x33da
fc1adca0: b8 dc 1a fc 00 00 00 00 2b e0 00 00 00 00 00 00fc1adcb0: f5 f9 96 00 00 00 00 00 e8 fd 1a fc 00 00 00 00
fc1adcc0: db 67 01 00 00 00 00 00 00 00 00 00 00 00 00 00
fc1adcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fc1adca0: b8 dc 1a fc 00 00 00 00 2b e0 00 00 00 00 00 00fc1adcb0: f5 f9 96 00 00 00 00 00 e8 fd 1a fc 00 00 00 00
fc1adcc0: db 67 01 00 00 00 00 00 00 00 00 00 00 00 00 00
fc1adcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9420: 48 8b 50 58 b8 01 00 00 00 48 85 d2 74 02 ff d29430: c9 c3 55 48 89 e5 0f b6 07 3a 06 75 20 ba 00 00
9440: 00 00 84 c0 75 0c eb 1e 48 83 c2 01 84 c0 66 90
9450: 74 14 0f b6 44 3a 01 3a 44 32 01 74 eb 3c 01 19
Pagetable walk from virt fffffffffc1afcfc, base 117b000:
L4 = 0000000000000000 (0xfffffffffffff000) [offset = 1ff]
Page fault in pagetable walk (access to invalid memory?).
The only references online to this error I found were from Amazon forums and issues with old pygrub versions and certain kernel versions from 2011. Host Virtual doesn't use pygrub though, so I don't think those Amazon issues are relevant.
Here's my df too (pseudo file systems removed):
/dev/root 20G 8.9G 12G 45% //dev/xvda5 4.0G 407M 3.6G 10% /var
/dev/xvda7 172G 514M 171G 1% /home
/dev/xvda6 4.0G 8.1M 4.0G 1% /tmp
/dev/xvda1 78M 40M 38M 52% /boot
Root is xvda3 (per Host Virtual's specs). Root, var, home, and boot are XFS. Tmp is ext2.
-Cory
I was actually able to figure this out on my own.
The problem was that I had reformatted my /boot partition to XFS (Host Virtual deploys it as ext3).
Everywhere I have read instructions on pvgrub it says that pvgrub supports XFS. Somehow Host Virtual has managed to remove support for XFS from pvgrub. And as far I found, it isn't documented anywhere at Host Virtual. Apparently, the support staff doesn't even know about it!
To fix it, I simply backed up /boot, reformatted ext3, and restored the data. The system immediately booted in PV Grub x64 mode without issue and without further modifications.
Hopefully, this post helps someone in the future.
I want to add to this, so there is a nice record of the limitations of Host Virtual's pvgrub:
The PV Grub 32 Boot Type from Host Virtual does support XFS filesystem. Only the PV Grub 64 does not.
Furthermore, both PV Grub 32 and PV Grub 64 only support GZip compression of the kernel (not any other compression types). This is also contrary to all the documentation on pvgrub that I've found (pvgrub is suppose to support all compression types).
It's also worth noting that I am using Host Virtual's New York data center. It's possible that other data centers differ in their pvgrub implementation.