libguestfs.git/appliance/init, branch oldlinux

EPEL 5: Add "null vmchannel" back for qemu without virtio-serial support.

2012-06-27T15:36:16+00:00

virtio-scsi: Increase udev timeout.

2012-06-14T13:22:07+00:00

In Koji, when you've got 200+ disks, udev times out before all the
udev events have been processed.

appliance: 'udevd' has been renamed, since it joined systemd.

2012-05-28T15:09:40+00:00

appliance: Remove some unnecessary errors.

2012-04-25T21:58:25+00:00

virt-rescue prints errors such as:

  rm: cannot remove `/proc': Is a directory
  mkdir: cannot create directory `/proc': File exists
  rm: cannot remove `/sys': Is a directory
  mkdir: cannot create directory `/sys': File exists

People have reported these errors (which are nothing to worry about)
as bugs in the past, so avoid them where possible.

appliance: Enhance --enable-valgrind-daemon with a suppressions file.

2012-03-14T16:13:40+00:00

This lets us suppress errors in system libraries.

Test fails in arch linux

2012-03-01T19:47:34+00:00

--20cf303ea4a84a7a7c04ba331375
Content-Type: text/plain; charset=ISO-8859-1

Hello Richard,

I found what the problem was and the udev symlinks where not created. The
init script in the appliance uses a full paths for udevadm (/sbin/udevadm)
which in my case was wrong. In Arch Linux udevadm is hosted under /usr/bin,
not /sbin. When I fixed this, libguestfs was able to communicate with the
appliance VM.

Since PATH variable is defined and exported in init, there is no need in
using full paths for external programs. As far as I've seen this affects
all the git branches in libguestfs's repository. Please find attached a
patch for the master branch.

Nikos Skalkotos,
Athens, Greece

On 24 February 2012 10:25, Richard W.M. Jones  wrote:

> On Thu, Feb 23, 2012 at 08:50:12PM +0200, Nikos Skalkotos wrote:
> [...]
>
> I don't know specifically why it fails with ArchLinux, but the problem
> is caused by the /dev/virtio-ports/* symlinks not getting created by
> udev.
>
> /dev/vport0p1 exists:
>
> > crw------- 1 root root 252,   1 Feb 23 18:17 vport0p1
>
> but udev doesn't make the corresponding /dev/virtio-ports symlink:
>
> > /dev/virtio-ports/org.libguestfs.channel.0: No such file or directory
>
> The symlink is supposed to be created by this udev rule:
>
> /lib/udev/rules.d/50-udev-default.rules:KERNEL=="vport*",
> ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"
>
> So I'd start by looking to see if that rule exists in the udev rules
> that Arch is using.  Secondly if it does exist, is the corresponding
> *.rules being copied into the appliance?  (Check appliance/supermin.d/
> hostfiles)
>
> In an old Ubuntu that has udev that predates having this rule, we add
> the following patch:
>
>
> http://libguestfs.org/download/binaries/ubuntu1004-packages/0002-ubuntu-10.04-Use-dev-vport0p1.patch
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into Xen guests.
> http://et.redhat.com/~rjones/virt-p2v
>

Hello Richard,

I found what the problem was and the udev symlinks where not created. The init script in the appliance uses a full paths for udevadm (/sbin/udevadm) which in my case was wrong. In Arch Linux udevadm is hosted under /usr/bin, not /sbin. When I fixed this, libguestfs was able to communicate with the appliance VM.

Since PATH variable is defined and exported in init, there is no need in using full paths for external programs. As far as I've seen this affects all the git branches in libguestfs's repository. Please find attached a patch for the master branch.

Nikos Skalkotos,
Athens, Greece

On 24 February 2012 10:25, Richard W.M. Jones <rjones@redhat.com> wrote:

On Thu, Feb 23, 2012 at 08:50:12PM +0200, Nikos Skalkotos wrote:

[...]

I don't know specifically why it fails with ArchLinux, but the problem

is caused by the /dev/virtio-ports/* symlinks not getting created by

udev.

/dev/vport0p1 exists:

> crw------- 1 root root 252,   1 Feb 23 18:17 vport0p1

but udev doesn't make the corresponding /dev/virtio-ports symlink:

> /dev/virtio-ports/org.libguestfs.channel.0: No such file or directory

The symlink is supposed to be created by this udev rule:

/lib/udev/rules.d/50-udev-default.rules:KERNEL=="vport*", ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"

So I'd start by looking to see if that rule exists in the udev rules

that Arch is using.  Secondly if it does exist, is the corresponding

*.rules being copied into the appliance?  (Check appliance/supermin.d/

hostfiles)

In an old Ubuntu that has udev that predates having this rule, we add

the following patch:

http://libguestfs.org/download/binaries/ubuntu1004-packages/0002-ubuntu-10.04-Use-dev-vport0p1.patch

Rich.

--

Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones

virt-p2v converts physical machines to virtual machines.  Boot with a

live CD or over the network (PXE) and turn machines into Xen guests.

http://et.redhat.com/~rjones/virt-p2v

appliance: udev >= 176 now requires /dev to be a devtmpfs.

2012-01-27T15:36:31+00:00

See this udev commit:
https://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=220893b3cbdbf8932f95c44811b169a8f0d33939

appliance: Switch to using 'iproute' ('ip' command) from 'net-tools' (RHBZ#784647).

2012-01-25T19:15:41+00:00

Change 'ifconfig' and 'netstat' commands to use 'ip' instead.

'iproute' was already included in the appliance, so this reduces the
size of the appliance accordingly.

Enable running the daemon under valgrind.

2012-01-24T15:56:14+00:00

This commit allows you to run the daemon under valgrind.  You have to
enable it at configure time:

  ./configure --enable-valgrind-daemon

This should *not* be done for production builds.

When this feature is enabled, valgrind is added to the appliance and
the daemon is run under valgrind.  Log messages from valgrind are
passed back over a virtio-serial channel into a file called
'valgrind.log.$PID' in the top build directory.

Running 'make check', 'make extra-tests' etc causes many
valgrind.log.* files to be created which must be examined by hand.

New API: list-md-devices.

2011-11-11T22:52:31+00:00

Return a list of Linux MD devices detected in the guest.

This API complements list_devices, list_partitions, list_lvs and
list_dm_devices.