On Mon, Oct 24, 2016 at 08:50:01PM -0400, n...@bigfoot.com wrote:
> On 24-10-2016 13:02, Roger Pau Monné wrote:
> > On Sat, Oct 22, 2016 at 04:14:33PM -0400, n...@bigfoot.com wrote:
> >> Running a FreeBSD 11.0-RELEASE HVM guest, using ufs, on Xen 4.4 (debian
> >> jessie) on LVM with drbd 8.4. The FreeBSD guest boots fine from LVM
> >> using 'disk' /dev/<vg>/<volume> in domU config.
> >> I have a number of Linux guests running on drbd (8.4). Booting FreeBSD
> >> from the drbd device associated with drbd (with 'disk' /dev/drbdx)
> >> fails. I know I can't use drbd:<resource> with HVM guest.
> >> Trying to mount root from ufs:/dev/xbd0p2 [rw]...
> >> mountroot: waiting for device /dev/xbd0p2...
> >> Mounting from ufs:/dev/xbd0p2 failed with error 19.
> > Ops, hit send to soon. Can you also paste the output of `xenstore-ls -fp`
> > executed from Dom0 when the guest is in this state?
> > Thanks, Roger.
> Thanks for replying.
> Sorry for the long post.
> There is one Linux PV guest on this host, not on drbd, but there are
> configured drbd devices on this host that belong to linux PV guests on
> another host also running debian jessie. They boot from drbd without
> To collect more data I created a fresh FreeBSD HVM guest on the same
> host. Interestingly, this guest does boot from drbd. You'll find it as
> domain 16 (vps13) in the attached output of xenstore-ls.
> The HVM guest that fails to mount root is domain 17 (vps10).
> The error message is:
> Trying to mount root from ufs:/dev/xbd0p2 [rw]...
> GEOM: xbd0: corrupt or invalid GPT detected.
> GEOM: xbd0: GPT rejected -- may not be recoverable.
> I should mention that there seems to be a conflict with the second GEOM
> GPT table in FreeBSD and the drbd metadata both writing to the end of
> the partition (we are using internal metadata). After creating metadata
> (drbdadm create-md) the kernel complains about the secondary GPT table,
> but that does not prevent it from mounting the fs.
> Inside the domu this can be resolved by issuing 'gpart recover', but
> this in turn seems to destroy the drbd metadata, which is apparent by
> the need to re-create md and re-sync at the next boot.
> Perhaps we should use external metadata in this case.
I have no idea how drbd works, but it certainly shouldn't store internal
metadata in the device presented to the guest, or else havoc is going to
happen for sure. I would suggest that you try this "external metadata" mode.
> As an aside, for your information, we tried to run the FreeBSD 11.0
> guest in PVH mode as well, having followed the instructions on
> The guest failed to start with xl reporting en error:
> xc: error: elf_xen_addr_calc_check: ERROR: ELF start or entries are out
> of bounds.: Invalid kernel
> Output of readelf -l /xenkernels/freebsd/kernel-11.0-RELEASE:
> Elf file type is EXEC (Executable file)
> Entry point 0xffffffff802ff000
> There are 6 program headers, starting at offset 64
That's expected, Xen 4.4 has some PVH support, but that's not enough, IIRC
you should use Xen 4.6 or newer.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"