Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

[Zaphod Beeblebrox]

I'm converting some Xen/Debian/Windows domain servers to
FreeBSD/Bhyve/Samba domain servers. Windows is still required for a couple
of applications, but I've recently had enough success with Samba4 to try
this. Not the problem.

The machines have two disks (was RAID-1 before, will be RAID-1 after) and
I've run the FreeBSD install on one disk leaving the other alone. I'd like
to copy off some of what's on the other disk, so I set about trying to read
it.

BHYVE ATTEMPT

Believe-it-or-not, I tried bhyve first. Being the more complex solution,
of course. I tried booting the other disk in bhyve. I chalked that
failure up to it still being a Xen config... wasn't sure how that would
boot for fail under bhyve... so I grabbed a debian live CD from the net and
tried to boot it.

Now, I'm following the directions from
https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html ...

And the error both times was failing to find init. Both booting the CD
_and_ booting the disk.

I can't seem to find any further documentation on my problem. Linux boots
to it's initrd filesystem state and fails to leave it because it (claims
it) can't find /sbin/init (even though in the CD case, it's there)

GEOM ATTEMPT

After this fail, I decided I didn't really _need_ to run linux here and I
discovered 'geom_linux_lvm.ko' ... cool. But fail, too. Doesn't emit any
messages. I even enabled the debug messages for it.

The linux disk is partitioned thusly:

=> 63 1953525105 ada1 MBR (932G)
63 1985 - free - (993K)
2048 1953523120 1 linux-data [active] (932G)
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Zaphod Beeblebrox]

> Are you using zvols to back the VMs? Make sure they are in 'volmode=dev'
> not 'geom' (the default), or GEOM will lock the device when it detects a
> partition table being written to the zvol (from the installer inside the
> VM)
>
> Note that this setting requires you to export/import the pool or reboot
> to apply.
>

No, no. The whole point here is that I was booting the raw disk. "ada1"
as it were.

[Zaphod Beeblebrox]

On Fri, Sep 16, 2016 at 1:06 AM, Allan Jude <alla...@freebsd.org> wrote:

> On 2016-09-16 01:04, Zaphod Beeblebrox wrote:
> >
> >
> >
> > Are you using zvols to back the VMs? Make sure they are in
> 'volmode=dev'
> > not 'geom' (the default), or GEOM will lock the device when it
> detects a
> > partition table being written to the zvol (from the installer inside
> > the VM)
> >
> > Note that this setting requires you to export/import the pool or
> reboot
> > to apply.
> >
> >
> > No, no. The whole point here is that I was booting the raw disk.
> > "ada1" as it were.
> >
>

> You might try the dangerous 'shoot yourself in the foot mode' for geom:
>
> man 4 geom:
> 0x10 (allow foot shooting)
> Allow writing to Rank 1 providers. This would, for example,
> allow the super-user to overwrite the MBR on the root disk or
> write random sectors elsewhere to a mounted disk. The
> implications are obvious.
>
>
> sysctl kern.geom.debugflags=16
>
> I get where you're going here, but it doesn't apply because at this point
> I'm not even booting from ada1.

[Andrey V. Elsukov]

On 15.09.2016 08:10, Zaphod Beeblebrox wrote:
> After this fail, I decided I didn't really _need_ to run linux here and I
> discovered 'geom_linux_lvm.ko' ... cool. But fail, too. Doesn't emit any
> messages. I even enabled the debug messages for it.
>
> The linux disk is partitioned thusly:
>
> => 63 1953525105 ada1 MBR (932G)
> 63 1985 - free - (993K)
> 2048 1953523120 1 linux-data [active] (932G)

Probably it isn't LVM or some modern version, which isn't supported by
module. With enable kern.geom.linux_lvm.debug=1 module will complain
only if it will find magic string "LABELONE" in the metadata.
You can check what is stored in the metadata with the following command:
# dd if=/dev/ada1s1 count=1 | hexdump -vC

--
WBR, Andrey V. Elsukov