[RFC/PATCH] libguestfs: build Debian based appliance

[Guido Günther]

Hi Rich,
attached patches allows to build the appliance based on Debian (or any
Debian based distribution supported by debirf) by using e.g.:

./configure --with-repo=squeeze --with-mirror=http://apt:9999/debian

Please note that the third patch isn't to be applied yet, it simply
overwrites the contents of make/update.sh.in with the stuff we need for
Debian. Also when building a fixed (#509381) debirf is needed which has
just been uploded to unstable.
Cheers,
 -- Guido

[Richard W.M. Jones]

On Wed, Jun 17, 2009 at 12:11:05AM +0200, Guido Günther wrote:
>  Hi Rich,
>  attached patches allows to build the appliance based on Debian (or any
>  Debian based distribution supported by debirf) by using e.g.:
>  
>  ./configure --with-repo=squeeze --with-mirror=http://apt:9999/debian
>  
>  Please note that the third patch isn't to be applied yet, it simply
>  overwrites the contents of make/update.sh.in with the stuff we need for
>  Debian. Also when building a fixed (#509381) debirf is needed which has
>  just been uploded to unstable.
>  Cheers,
>   -- Guido 
>  >From c2fbd2f953147c4320a158878955f099af45e409 Mon Sep 17 00:00:00
> 2001
>  From: =?utf-8?q?Guido=20G=C3=BCnther?= <agx(a)sigxcpu.org&gt;
>  Date: Mon, 15 Jun 2009 20:27:52 +0200
>  Subject: [PATCH 1/3] check for Debian tools
>  
>  ---
>   configure.ac |   46 ++++++++++++++++++++++++++++------------------
>   1 files changed, 28 insertions(+), 18 deletions(-) 
First patch is fine.  I will apply it anyway.

>  >From 1b3c0224bd33c394bf1ae9144ae8c0c8bcff51e7 Mon Sep 17 00:00:00
> 2001
>  From: =?utf-8?q?Guido=20G=C3=BCnther?= <agx(a)sigxcpu.org&gt;
>  Date: Tue, 16 Jun 2009 23:47:36 +0200
>  Subject: [PATCH 2/3] add debirf files
>  
>  ---
>   appliance/debian/debirf.conf.in              |    5 ++
>   appliance/debian/modules/a0_motd             |    1 +
>   appliance/debian/modules/a0_prep-root        |    1 +
>   appliance/debian/modules/install_kernel      |   68 ++++++++++++++++++++++++++
>   appliance/debian/modules/network             |    1 +
>   appliance/debian/modules/root-bashrc         |    1 +
>   appliance/debian/modules/serial-terminal     |    1 +
>   appliance/debian/modules/y0_install-guestfsd |   56 +++++++++++++++++++++
>   appliance/debian/modules/z0_remove-aptitude  |    1 +
>   appliance/debian/modules/z0_remove-locales   |    1 +
>   appliance/debian/modules/z1_clean-root       |    1 +
>   configure.ac                                 |    2 +-
>   12 files changed, 138 insertions(+), 1 deletions(-)
>   create mode 100644 appliance/debian/debirf.conf.in
>   create mode 120000 appliance/debian/modules/a0_motd
>   create mode 120000 appliance/debian/modules/a0_prep-root
>   create mode 100755 appliance/debian/modules/install_kernel
>   create mode 120000 appliance/debian/modules/network
>   create mode 120000 appliance/debian/modules/root-bashrc
>   create mode 120000 appliance/debian/modules/serial-terminal
>   create mode 100755 appliance/debian/modules/y0_install-guestfsd
>   create mode 120000 appliance/debian/modules/z0_remove-aptitude
>   create mode 120000 appliance/debian/modules/z0_remove-locales
>   create mode 120000 appliance/debian/modules/z1_clean-root 
This patch duplicates things unnecessarily, I think.

List of kernel modules (commented out), which are now in a separate
file called kmod.whitelist{,in}:

>  +#(cd "$DEBIRF_ROOT" && find lib/modules/*/kernel
> \
>  +#  -name '*.ko' \
>  +#  -a ! -name 'virtio.ko' \
>  +#  -a ! -name 'virtio_net.ko' \
>  +#  -a ! -name 'virtio_pci.ko' \
>  +#  -a ! -name 'virtio_ring.ko' \
>  +#  -a ! -name 'ext2.ko' \
>  +#  -a ! -name 'ext4.ko' \
>  +#  -a ! -name 'crc16.ko' \
>  +#  -a ! -name 'jbd2.ko' \
>  +#  -a ! -name 'fuse.ko' \
>  +#  -a ! -name 'vfat.ko' \
>  +#  -a ! -name 'fat.ko' \
>  +#  -a ! -name 'udf.ko' \
>  +#  -a ! -name 'crc_itu_t.ko' \
>  +#  -a ! -name 'nls_utf8.ko' \
>  +#  -a ! -name 'dm-*.ko' \
>  +#  -a -exec rm "{}" \; )
>  +
>  +rm -rf "$DEBIRF_ROOT"/usr/share/doc
>  +rm -rf "$DEBIRF_ROOT"/usr/share/zoneinfo 
List of packages.  Although package names are slightly different
between Fedora and Debian, I think we should aim to unify this list as
far as possible.  How about adding a file similar to the kernel module
whitelist which lists packages, albeit with either wildcards or
#if DEBIAN ... #endif markup?

>  +debirf_exec aptitude -R -y install libaugeas0 lvm2 binutils
> dosfstools grub iproute module-init-tools ntfs-3g strace util-linux zerofree bsdmainutils
>  +debirf_exec aptitude -y remove vim-tiny dhcp3-client 
The /init script should also be moved out to a separate file.  I don't
want to have to maintain it twice, and it should be the same or very
similar for both appliances:

>  +rm -f "$DEBIRF_ROOT"/sbin/init
>  +cat > "$DEBIRF_ROOT"/sbin/init <<__EOF__
>  +#!/bin/sh
>  +export PATH=/sbin:/usr/sbin:$PATH
>  +cd /dev
>  +MAKEDEV hda hdb hdc hdd sda sdb sdc sdd sd
>  +cd /
>  +mount -t proc /proc /proc
>  +mount -t sysfs /sys /sys
>  +mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
>  +modprobe virtio_pci
>  +modprobe virtio_net
>  +modprobe dm_mod ||:
>  +/sbin/ifconfig lo 127.0.0.1
>  +/sbin/ifconfig eth0 10.0.2.10
>  +/sbin/route add default gw 10.0.2.2
>  +lvm vgscan --ignorelockingfailure
>  +lvm vgchange -ay --ignorelockingfailure
>  +exec guestfsd -f
>  +__EOF__ 
Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Guido Günther]

Hi Rich,
On Wed, Jun 17, 2009 at 12:11:05AM +0200, Guido Günther wrote:
>  Hi Rich,
>  attached patches allows to build the appliance based on Debian (or any
>  Debian based distribution supported by debirf) by using e.g.:
>  
>  ./configure --with-repo=squeeze --with-mirror=http://apt:9999/debian
>  
>  Please note that the third patch isn't to be applied yet, it simply
>  overwrites the contents of make/update.sh.in with the stuff we need for
>  Debian. Also when building a fixed (#509381) debirf is needed which has
>  just been uploded to unstable. 
Attched are three more patches to get things
further: 

The first once sets DIST=DEBIAN or DIST=REDHAT if using debootstrap or
febootstrap respectively. This allows us to set distro specific package
lists as discussed at Fudcon.

The second one checks for udev and uses that instead of doing everything
by hand. This significantly speeds up booting of the appliance since
each MAKEDEV call tages ages here and simplifies the code since we don't
need any device probing.

The third one explicitly sets the device type of attached disk to SCSI,
otherwise the tests end up as hda with my version of qemu. Since future
versions might pick virtio by default this is probaly safer anyway.

Can these be applied?
Cheers,
 -- Guido

[Richard W.M. Jones]

On Tue, Jun 30, 2009 at 12:18:30AM +0200, Guido Günther wrote:
>  Hi Rich,
>  On Wed, Jun 17, 2009 at 12:11:05AM +0200, Guido Günther wrote:
>  > Hi Rich,
>  > attached patches allows to build the appliance based on Debian (or any
>  > Debian based distribution supported by debirf) by using e.g.:
>  > 
>  > ./configure --with-repo=squeeze --with-mirror=http://apt:9999/debian
>  > 
>  > Please note that the third patch isn't to be applied yet, it simply
>  > overwrites the contents of make/update.sh.in with the stuff we need for
>  > Debian. Also when building a fixed (#509381) debirf is needed which has
>  > just been uploded to unstable.
>  Attched are three more patches to get things further: 
>  
>  The first once sets DIST=DEBIAN or DIST=REDHAT if using debootstrap or
>  febootstrap respectively. This allows us to set distro specific package
>  lists as discussed at Fudcon.
>  
>  The second one checks for udev and uses that instead of doing everything
>  by hand. This significantly speeds up booting of the appliance since
>  each MAKEDEV call tages ages here and simplifies the code since we don't
>  need any device probing.
>  
>  The third one explicitly sets the device type of attached disk to SCSI,
>  otherwise the tests end up as hda with my version of qemu. Since future
>  versions might pick virtio by default this is probaly safer anyway.
>  
>  Can these be applied? 
All three patches look good.  I'll apply them later on today.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Richard W.M. Jones]

On Tue, Jun 30, 2009 at 12:18:30AM +0200, Guido Günther wrote:
>  The first once sets DIST=DEBIAN or DIST=REDHAT if using debootstrap
> or
>  febootstrap respectively. This allows us to set distro specific package
>  lists as discussed at Fudcon. 
OK, I pushed this one as is:

http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=b4fade6392ccb29...

>  The second one checks for udev and uses that instead of doing
> everything
>  by hand. This significantly speeds up booting of the appliance since
>  each MAKEDEV call tages ages here and simplifies the code since we don't
>  need any device probing. 
I modified your patch slightly to add Fedora udev support.  As you
say, it works better than doing explicit MAKEDEVs:

http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=284797c1561e5e0...

>  The third one explicitly sets the device type of attached disk to
> SCSI,
>  otherwise the tests end up as hda with my version of qemu. Since future
>  versions might pick virtio by default this is probaly safer anyway. 
This one is a bit of trouble.  It broke Fedora support, but I think
was just because the sym53c8xx.ko module was missing from my
appliance.  I'm going to try with that.

I'm slightly doubtful about what is going on here, because the tests
are *supposed* to deal with the case where devices are named /dev/hda
etc.  See:

http://libguestfs.org/guestfs.3.html#block_device_naming

However your patch could be an improvement if it means that devices
are always named /dev/sd*, even on our older versions of RHEL.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Guido Günther]

Hi Rich,
On Tue, Jun 30, 2009 at 10:01:59AM +0100, Richard W.M. Jones wrote:
>  On Tue, Jun 30, 2009 at 12:18:30AM +0200, Guido Günther wrote:
>  > The first once sets DIST=DEBIAN or DIST=REDHAT if using debootstrap or
>  > febootstrap respectively. This allows us to set distro specific package
>  > lists as discussed at Fudcon.
>  
>  OK, I pushed this one as is:
>  
>
> http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=b4fade6392ccb29...
Thanks.

>  > The second one checks for udev and uses that instead of doing
> everything
>  > by hand. This significantly speeds up booting of the appliance since
>  > each MAKEDEV call tages ages here and simplifies the code since we don't
>  > need any device probing.
>  
>  I modified your patch slightly to add Fedora udev support.  As you
>  say, it works better than doing explicit MAKEDEVs:
>  
>
> http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=284797c1561e5e0...
Even better. Thanks.

>  > The third one explicitly sets the device type of attached disk
> to SCSI,
>  > otherwise the tests end up as hda with my version of qemu. Since future
>  > versions might pick virtio by default this is probaly safer anyway.
>  
>  This one is a bit of trouble.  It broke Fedora support, but I think
>  was just because the sym53c8xx.ko module was missing from my
>  appliance.  I'm going to try with that. 
Attached patch has what I came up with
to support most of QEMUs hardware
as used by the appliance.

>  
>  I'm slightly doubtful about what is going on here, because the tests
>  are *supposed* to deal with the case where devices are named /dev/hda
>  etc.  See:
>  
>  http://libguestfs.org/guestfs.3.html#block_device_naming
>  
>  However your patch could be an improvement if it means that devices
>  are always named /dev/sd*, even on our older versions of RHEL. 
The problem here is
that the "blockdev /dev/sda" call fails since sda is
missing completely with udev. Without having looked at this further I
assume that libguestfs internally expects the blockdev call to succeed
since it assumes /dev/sda is there due to static device node creation.
However if we switch to if=scsi this will work anyways.
Cheers,
 -- Guido

[Richard W.M. Jones]

On Tue, Jun 30, 2009 at 12:19:33PM +0200, Guido Günther wrote:
>  Hi Rich,
>  On Tue, Jun 30, 2009 at 10:01:59AM +0100, Richard W.M. Jones wrote:
>  > This one is a bit of trouble.  It broke Fedora support, but I think
>  > was just because the sym53c8xx.ko module was missing from my
>  > appliance.  I'm going to try with that.
>  Attached patch has what I came up with to support most of QEMUs hardware
>  as used by the appliance. 
[...]
>  The problem here is that the "blockdev /dev/sda" call fails
> since sda is
>  missing completely with udev. Without having looked at this further I
>  assume that libguestfs internally expects the blockdev call to succeed
>  since it assumes /dev/sda is there due to static device node creation.
>  However if we switch to if=scsi this will work anyways. 
Actually the problem was just down to the devices taking a long time
to initialize.  We would need to call/load 'scsi_wait_scan.ko' and
use 'udevadm settle'.

I think, however, we should just use virtio (virtio_blk.ko).  This is
faster, more reliable, and available everywhere we care about.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Guido Günther]

On Tue, Jun 30, 2009 at 12:31:33PM +0100, Richard W.M. Jones wrote:
>  On Tue, Jun 30, 2009 at 12:19:33PM +0200, Guido Günther wrote:
>  > Hi Rich,
>  > On Tue, Jun 30, 2009 at 10:01:59AM +0100, Richard W.M. Jones wrote:
>  > > This one is a bit of trouble.  It broke Fedora support, but I think
>  > > was just because the sym53c8xx.ko module was missing from my
>  > > appliance.  I'm going to try with that.
>  > Attached patch has what I came up with to support most of QEMUs hardware
>  > as used by the appliance.
>  [...]
>  > The problem here is that the "blockdev /dev/sda" call fails since sda is
>  > missing completely with udev. Without having looked at this further I
>  > assume that libguestfs internally expects the blockdev call to succeed
>  > since it assumes /dev/sda is there due to static device node creation.
>  > However if we switch to if=scsi this will work anyways.
>  
>  Actually the problem was just down to the devices taking a long time
>  to initialize.  We would need to call/load 'scsi_wait_scan.ko' and
>  use 'udevadm settle'.
>  
>  I think, however, we should just use virtio (virtio_blk.ko).  This is
>  faster, more reliable, and available everywhere we care about. 
Sure. I'm fine
with that. However including the other modules for
SCSI/IDE won't hurt IMHO (they don't take up much space), this can be
helpful for testing the appliance.
Cheers,
 -- Guido

[Richard W.M. Jones]

On Tue, Jun 30, 2009 at 01:37:43PM +0200, Guido Günther wrote:
>  However including the other modules for
>  SCSI/IDE won't hurt IMHO (they don't take up much space), this can be
>  helpful for testing the appliance. 
I agree - I'll apply that patch shortly.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Richard W.M. Jones]

On Tue, Jun 30, 2009 at 10:01:59AM +0100, Richard W.M. Jones wrote:
>  I'm slightly doubtful about what is going on here, because the
> tests
>  are *supposed* to deal with the case where devices are named /dev/hda
>  etc.  See:
>  
>  http://libguestfs.org/guestfs.3.html#block_device_naming 
OK, I understand what was happening here.

The device name translation stuff mentioned at the link above relied
on the (pre-udev) case where the /dev/sd* nodes would exist, but upon
opening them you'd get ENXIO.

With udev, the device nodes no longer exist, so we get ENOENT.

The simple patch below should fix that case.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora