[PATCH] sysprep: handle distro specific sysv scripts
by Olaf Hering
Currently firstboot would only work on redhat-based images.
Handle redhat-based, suse-based and debian guests, error out in case of an
unknown distro.
Update firstboot.sh:
- make sure scripts exists and can be executed
- add LSB header to avoid insserv warnings later on
- run script only if called with "start"
Update functions, pass only required options.
Signed-off-by: Olaf Hering <olaf(a)aepfle.de>
diff --git a/sysprep/firstboot.ml b/sysprep/firstboot.ml
index 97cd8a9..c5296a1 100644
--- a/sysprep/firstboot.ml
+++ b/sysprep/firstboot.ml
@@ -28,14 +28,35 @@ let firstboot_dir = "/usr/lib/virt-sysprep"
let firstboot_sh = sprintf "\
#!/bin/sh -
+### BEGIN INIT INFO
+# Provides: virt-sysprep
+# Required-Start: $null
+# Should-Start: $all
+# Required-Stop: $null
+# Should-Stop: $all
+# Default-Start: 2 3 5
+# Default-Stop: 0 1 6
+# Short-Description: Start scripts to run once at next boot
+# Description: Start scripts to run once at next boot
+# These scripts run the first time the guest boots,
+# and then are deleted. Output or errors from the scripts
+# are written to ~root/virt-sysprep-firstboot.log.
+### END INIT INFO
+
d=%s/scripts
logfile=~root/virt-sysprep-firstboot.log
-for f in $d/* ; do
- echo '=== Running' $f '===' >>$logfile
- $f >>$logfile 2>&1
- rm $f
-done
+if test \"$1\" = \"start\"
+then
+ for f in $d/* ; do
+ if test -x \"$f\"
+ then
+ echo '=== Running' $f '===' >>$logfile
+ $f >>$logfile 2>&1
+ rm -f $f
+ fi
+ done
+fi
" firstboot_dir
let firstboot_service = sprintf "\
@@ -56,7 +77,7 @@ WantedBy=default.target
let failed fs =
ksprintf (fun msg -> failwith (s_"firstboot: failed: " ^ msg)) fs
-let rec install_service g root =
+let rec install_service g distro =
g#mkdir_p firstboot_dir;
g#mkdir_p (sprintf "%s/scripts" firstboot_dir);
g#write (sprintf "%s/firstboot.sh" firstboot_dir) firstboot_sh;
@@ -64,18 +85,18 @@ let rec install_service g root =
(* systemd, else assume sysvinit *)
if g#is_dir "/etc/systemd" then
- install_systemd_service g root
+ install_systemd_service g
else
- install_sysvinit_service g root
+ install_sysvinit_service g distro
(* Install the systemd firstboot service, if not installed already. *)
-and install_systemd_service g root =
+and install_systemd_service g =
g#write (sprintf "%s/firstboot.service" firstboot_dir) firstboot_service;
g#mkdir_p "/etc/systemd/system/default.target.wants";
g#ln_sf (sprintf "%s/firstboot.service" firstboot_dir)
"/etc/systemd/system/default.target.wants"
-and install_sysvinit_service g root =
+and install_sysvinit_redhat g =
g#mkdir_p "/etc/rc.d/rc2.d";
g#mkdir_p "/etc/rc.d/rc3.d";
g#mkdir_p "/etc/rc.d/rc5.d";
@@ -86,12 +107,51 @@ and install_sysvinit_service g root =
g#ln_sf (sprintf "%s/firstboot.sh" firstboot_dir)
"/etc/rc.d/rc5.d/99virt-sysprep-firstboot"
+(* Make firstboot.sh look like a runlevel script to avoid insserv warnings. *)
+and install_sysvinit_suse g =
+ g#mkdir_p "/etc/init.d/rc2.d";
+ g#mkdir_p "/etc/init.d/rc3.d";
+ g#mkdir_p "/etc/init.d/rc5.d";
+ g#ln_sf (sprintf "%s/firstboot.sh" firstboot_dir)
+ "/etc/init.d/virt-sysprep-firstboot";
+ g#ln_sf "../virt-sysprep-firstboot"
+ "/etc/init.d/rc2.d/S99virt-sysprep-firstboot";
+ g#ln_sf "../virt-sysprep-firstboot"
+ "/etc/init.d/rc3.d/S99virt-sysprep-firstboot";
+ g#ln_sf "../virt-sysprep-firstboot"
+ "/etc/init.d/rc5.d/S99virt-sysprep-firstboot"
+
+and install_sysvinit_debian g =
+ g#mkdir_p "/etc/init.d";
+ g#mkdir_p "/etc/rc2.d";
+ g#mkdir_p "/etc/rc3.d";
+ g#mkdir_p "/etc/rc5.d";
+ g#ln_sf (sprintf "%s/firstboot.sh" firstboot_dir)
+ "/etc/init.d/virt-sysprep-firstboot";
+ g#ln_sf "/etc/init.d/virt-sysprep-firstboot"
+ "/etc/rc2.d/S99virt-sysprep-firstboot";
+ g#ln_sf "/etc/init.d/virt-sysprep-firstboot"
+ "/etc/rc3.d/S99virt-sysprep-firstboot";
+ g#ln_sf "/etc/init.d/virt-sysprep-firstboot"
+ "/etc/rc5.d/S99virt-sysprep-firstboot"
+
+and install_sysvinit_service g distro =
+ match distro with
+ | ("fedora"|"rhel"|"centos"|"scientificlinux"|"redhat-based") ->
+ install_sysvinit_redhat g
+ | ("opensuse"|"sles"|"suse-based") ->
+ install_sysvinit_suse g
+ | "debian" ->
+ install_sysvinit_debian g
+ | _ ->
+ failed "guest type %s is not supported" distro
+
let add_firstboot_script g root id content =
let typ = g#inspect_get_type root in
let distro = g#inspect_get_distro root in
match typ, distro with
| "linux", _ ->
- install_service g root;
+ install_service g distro;
let t = Int64.of_float (Unix.time ()) in
let r = string_random8 () in
let filename = sprintf "%s/scripts/%Ld-%s-%s" firstboot_dir t r id in
--
1.7.12
11 years, 1 month
err from guestfs_launch
by Skippy VonDrake
This error is with libguestfs 1.20.
Calling guestfs_launch() with tracing on:
supermin helper [00065ms] finished creating appliance
libguestfs: checksum of existing appliance:
2bd6811426e14b6fb661b4d52cebd6c21a41df1a068e8acf6a7a08e3b3bd4ada
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: [00071ms] begin building supermin appliance
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: [00071ms] run febootstrap-supermin-helper
libguestfs: command: run: febootstrap-supermin-helper
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ /usr/local/lib/guestfs/supermin.d
libguestfs: command: run: \ x86_64
libguestfs: command: run: \ /var/tmp/guestfs.lQs0RL/kernel
libguestfs: command: run: \ /var/tmp/guestfs.lQs0RL/initrd
libguestfs: command: run: \ /var/tmp/guestfs.lQs0RL/root
febootstrap-supermin-helper: unrecognized option '--copy-kernel'
febootstrap-supermin-helper: build the supermin appliance on the fly
Usage:
febootstrap-supermin-helper [-options] inputs [...] host_cpu kernel initrd
<snip>
Same code works on a different system. Both systems are Ubuntu 12.04.
However the system that works is using Linux 3.6.4-pv whereas the system
that fails is Linux 3.5.4-pv.
Do I need to upgrade the kernel?
12 years
Happy holidays
by Richard W.M. Jones
Happy holidays to all our users.
Matt is on holiday this week.
I'm on holiday until * January 16th *.
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 KVM guests.
http://libguestfs.org/virt-v2v
12 years, 1 month
febootstrap and download packages
by Evaggelos Balaskas
Something that i would like to have, is the ability to keep the
download packages in a temp directory when using febootstrap.
I understand that using ferora/archlinux (distros with a lot of
package updates every day) can increase the size of this temp
directory rapidly and at some point will have a lot of deprecate
packages.
But the daily use of febootstrap (or building libguestfs) makes your
network suffer for downloading the same packages again and again. For
build libguestfs on archlinux is an amount of 140Mb.
On my machine i've found two solutions:
a. creating a custom local repo and move it to the top of my
pacman.conf, so it would access this local repo without the need of
internet
b. hacking a febootstrap_pacman.ml to use /tmp/cachedir (or a dir on my home).
Do you believe that a parameter like "--save-temp" eg. "--save-pkgs"
could matter ?
--
Evaggelos Balaskas - Unix System Engineer
http://gr.linkedin.com/in/evaggelosbalaskas
12 years, 1 month
Supporting btrfs subvolumes during inspection
by Matthew Booth
We've currently got a bug in libguestfs which means we can't inspect
filesystems in btrfs subvolumes:
https://bugzilla.redhat.com/show_bug.cgi?id=824021
This is the default configuration if you select btrfs in F17+. The issue
is that it requires an api to fix it, as the return values of
inspect_os, inspect_get_filesystems and inspect_get_mountpoints can't
express a btrfs subvolume as they're expected to be the names of block
devices.
As a starter for 10, I propose the addition of parallel apis suffixed
_ext which return annotated device descriptions, e.g.:
block:/dev/vda2
btrfsvol:/dev/vda4,root
The string before the colon is a descriptor. The format of the string
after the colon is custom to the descriptor, and is described in the
API. A client program can ignore strings with unknown descriptors. New
descriptors can be added as required.
The old apis would return the same as the _ext versions, except they
would only return block devices. Other devices would be omitted.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
12 years, 1 month
Can't access remote URI
by Wanlong Gao
Hi Rich,
We just found that the libguestfs can't access the remote URI.
When doing guestfs__add_drive_opts(), we always add files from
local system, it's related the -c|--connect option.
As I know, we are using local kernel to lunch the min-guest,
and it's hard to attach remote disks to our local min-guest.
Our test team found this problem by using following command,
# virt-sysprep -c qemy+ssh://<host>/system -d domname
Then, for example the path of remote disk is /work/rhel.img,
but we are about to access the /work/rhel.img locally.
So, IMHO, if we are about to not support the remote URI, we
should give a error message first. But access local disks
instead of remote disks are definitely wrong here.
Maybe we also need document this.
Any thoughts?
Thanks,
Wanlong Gao
12 years, 1 month
Need DETAILED help using p2v
by Bob Buckley
This is something I want to do over my holiday vacation to continue to broaden my skills.
I am experimenting (learning) about moving a Win7 physical drive to a VM under my CSB. I'm struggling a little on the steps when using our RH documentation (perhaps it is clear if you are an RHCE but it isn't to someone trying to learn from it initially combined with Google searches) so asking if anyone has any one-off how to scripts for this scenario? The two drives (Win7 and CSB) are two different hard drives both bootable on my laptop so it should be simple but...
I have been pointed to several existing pages that are all written for the EXPERIENCED RHCE but not for the novice. Appreciate any assistance you can provide.
Thanks, Bob
Bob "B 2 " Buckley
Sr. Storage Solutions Architect,
Intelligence & National Security
719.330.9329 (Mobile), 571.421.8160 (Office)
bbuckley(a)redhat.com
12 years, 1 month
Re: [Libguestfs] inspect_os error with Win7 image
by Richard W.M. Jones
On Mon, Dec 17, 2012 at 04:46:02PM -0500, Skippy VonDrake wrote:
> > As far as we know, this means the registry is really corrupt (or
> > something odd has happened, such as it's been zero-padded).
>
> It appears that the registry did have something wrong with it.
>
> I booted the image in Xen and saw a message window pop up:
> "Registry Recovery - One of the files containing the system's
> Registry data had to be recovered by use of a log or alternate copy
> The recovery was successful."
>
> And after I shut the VM back down, guestfs was able to load
> and continue past the call to guestfs_inspect_os() with no
> problems.
>
> Is there a way I can get more data to determine exactly where
> the hivex calls are failing? Maybe then a fix could be made to
> still return the root devices even when the registry is a little
> "off".
It's possible we could add a HIVEX_OPEN_FIXUP flag or something like
that. In this case (empty hbins) it would probably be safe, but I'd
worry about trying to "fix" more egregious registry errors,
particularly since we don't fully understand the format.
> With this in mind I altered 'hivex.c', function do_hivex_open(),
> by commenting out the code around the statements:
> flags |= HIVEX_OPEN_VERBOSE;
> flags |= HIVEX_OPEN_DEBUG;
> Effectively hard-coding them. Hoping that more info would be
> generated. However that obviously wasn't enough for the
> process just seemed to "hang".
You'll also need to enable libguestfs verbose messages:
guestfs_set_verbose (g, 1);
That should dump everything to stderr, and with hivex debug you really
will get a very large amount of debugging info. If it hangs again,
let us know where (please file a bug with all the verbose output until
the hang).
> What else would need changing to get more details generated
> from guestfs_inspect_os->hivex_open?
If you were feeling very adventurous, you could run the "visualizer"
program from:
https://github.com/libguestfs/hivex/tree/master/lib/tools
That's the program I used when I was reverse-engineering the registry
format, and the source of the program has lots of useful information
about the format. However I don't think it will tell you anything
very interesting in this case.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
12 years, 1 month
Issues with GObject bindings
by Richard W.M. Jones
Matt, further to the conversation today.
When you run the tests (make -C gobject check) you'll find it now
prints the descriptive message:
"GObject bind tests skipped: Int64, OInt64 and OStringList are all broken"
That nicely sums up the first two problems.
(1) When I tested passing the full range of int64, it turns out to be
broken. There are probably two layers of brokenness, ie. Javascript
itself has broken integers as a design failure of the language, but
also I convinced myself at some point that something in GObject
truncates all integers to 32 bits. BTW also check it works on a 32
bit architecture.
(2) OStringList: IIRC I added this type to the generator but was
unable / didn't have time to add it to the GObject bindings.
(3) Stability of the API: GObject doesn't understand the
once_had_no_optargs feature of the generator, which means that
converting a no-optargs call to an optargs call (which is now
permitted) will break the GObject API. You may or may not care about
this.
(4) Coverity found a potential bug in header inclusion. It seems that
GObject headers recursively include themselves. Both Ondrej and I
tried different approaches to fixing this but were unable to make it
work.
(5) I heavily refactored the code in generator/gobject.ml. Although I
checked that the output of the generator didn't change, you might also
want to check those commits for sanity.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.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
12 years, 1 month
