Re: [Libguestfs] [PATCH libnbd 0/2] Two patches to make libnbd work on FreeBSD.

On Thu, Jul 04, 2019 at 09:14:13AM +0100, Richard W.M. Jones wrote: >On Thu, Jul 04, 2019 at 09:45:26AM +0200, Martin Kletzander wrote: >>On Wed, Jul 03, 2019 at 05:17:42PM +0100, Richard W.M. Jones wrote: >>>Two simple patches which make libnbd compile on FreeBSD. >>> >>>Are we OK to copy common/include/byte-swapping.h from nbdkit? There >>>is no license issue that I know of. Should we put it in lib/ or >>>create a common/ directory? The header file is actually also needed >>>by the tests (follow up patch for that) so putting it in common/ might >>>make more sense. >>> >>>Some notes if you want to compile on FreeBSD: >>> >>>- OCaml is too old to run the generator, so you can't easily build >>> from git. Tarball builds should work, or you can copy the >>> generated files across from a Linux machine. >>> >> >>Are you sure? I checked repology.org and it says the FreeBSD Ports have 4.05.0, >>which I managed to make work by a simple patch some time ago. I'm setting up a >>FreeBSD machine to try it out. > >Probably because I'm not running the latest FreeBSD. I think I was >using 11.2. > The Ports should be the same across releases. But maybe it was not updated? Anyway, I tried finding that in freebsd-11.1 (because that is the one available from virt-builder) and we found two issues: - The template suggests there is /dev/sda5, which it definitely looks like it from virt-rescue, but all following operations (parted, sgdisk, etc.) fail because the GPT is invalid, so they load the MBR which only has /dev/sda1 (the MRB extended partition on which /dev/sda5 and /dev/sda6 live), but they do not see any other partitions and fail. I thought I could fix it locally by recreating the table based on what the kernel found (no idea how, but it knows about /dev/sda5 and /dev/sda6). The partition types were unknown to me, but I somehow managed to make it so that it does not report invalid GPT. - The second issue is that the libguestfs-appliance-1.40.1 which I am using (prebuilt upstream) does not have a kernel module for UFS, so it cannot even inspect the filesystem. Pino told me to report both of these to you, hence the above. If you want me to write them down in a bug report somewhere, let me know.