3:24 a.m.
On Thu, Aug 27, 2020 at 11:08 AM Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Thu, Aug 27, 2020 at 10:50:12AM +0300, Sam Eiderman wrote:
> Hi,
>
> I'm using libguestfs 1.42,
>
> When I run the following python3 commands on a rhel7.8:
>
> print(g.ls('/sys'))
> []
This lists the files in /sys in the filesystem, which in most disk
images is likely to be an empty directory.
> print(g.sh('ls /sys'))
> block
> bus
> class
> dev
> devices
> firmware
> fs
> hypervisor
> kernel
> module
> power
sh bind-mounts /sys from the appliance into the filesystem temporarily
in order to make it possible to run some commands:
https://github.com/libguestfs/libguestfs/blob/fce82fe55a2b64a1a7e494858aa...
However this /sys has nothing to do with /sys as it may appear in the
guest when it is running. Libguestfs edits filesystems, it doesn't
run the guest.
Yes, I understand that, I am just surprised to know that we bind /sys
for g.sh() commands.
However, "g.command([self.mkconfig, '-o', self.config])" shouldn't
have the appliances /sys available (I looked briefly in command.c and
I don't see the same bind-mount code), or maybe I'm missing something.
> It seems that g.ls('/sys') is chrooted correctly.
> But g.sh('ls /sys') isn't.
>
> I came across this behavior when I used g.command(['grub2-mkconfig',
'-o',
> '....']) on rhel7.8 and it didn't produce the correct
linuxefi/initrdefi
> entries in grub, since in rhel7.8 the uefi detection algorithm is checking
> in bash '[ -d /sys/firmware/efi ]'.
>
https://src.fedoraproject.org/rpms/grub2/blob/71e0fb4ea646071ec86e4a65bb2...
It's pretty unlikely that running grub can work. The libguestfs
appliance is sufficiently different from how the guest boots that
things like BIOS mappings are not related, and libguestfs doesn't use
EFI at all.
There's unfortunately no good way to run grub. syslinux/extlinux is
the only option since it is designed to make modifications to offline
filesystems, and grub is not.
Rich.
Well, at the moment in my code in and in virt-v2v, that's what we do:
https://github.com/libguestfs/virt-v2v/blob/master/v2v/linux_bootloaders....
I thought I could use my g.mkdir_p('/sys/firmware/efi') hack, but
since it didn't work, I'm now resort to explicitly handling this
failure after running the mkconfig command:
def _fix_grub2_config_efi(self, g):
# On rhel7.8 the grub config is set to non efi commands due to
# a weak uefi detection algorithm which doesn't work from a chrooted
# environment (checks for [ -d /sys/firmware/efi ])
if (self.root.family, self.boot_type) != (LinuxFamily.RHEL,
BootType.UEFI):
return
grub_config = g.read_file(self.config).decode('utf-8')
write = False
for old, new in [('linux16', 'linuxefi'),
('initrd16', 'initrdefi')]:
if f'\t{old} ' in grub_config:
debug(f'Replacing {old} with {new} in {self.config}')
grub_config = grub_config.replace(f'\t{old} ', f'\t{new}
')
write = True
if write:
g.write(self.config, grub_config.encode('utf-8'))
The problem is easily reproduced by using the 7.8 iso available now
from rhel, installed on VMware as UEFI.
Should probably be reproduced in virt-v2v too.
The problematic file is 10_linux which belongs to:
grub2-tools-2.02-0.81.el8.x86_64
Sam
> I thought I could simply g.mkdir_p('/sys/firmware/efi')
- but that created
> a fake dir in my chrooted environment, where grub2-mkconfig somehow was
> inspecting the real /sys as demonstrated in the above 'ls' example.
>
> Any ideas on why sh jailbreaks the chroot? is /sys set through some
> environment variable?
>
> Thanks!
> _______________________________________________
> Libguestfs mailing list
> Libguestfs(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v