similar to: [PATCH supermin] init: Delete initramfs files before chrooting into the appliance.

v1 -> v2: - If we split out the init program into a separate init/ directory, that makes it much easier to build against an alternate libc. I tried to build against uClibc, but uClibc requires an entire build chain, which looked like it was going to be a massive ballache. Rich.

This patch is the minimum possible to add virtio-scsi support to febootstrap. Problem: SCSI devices are detected asynchronously after the Linux kernel module is loaded. The usual solutions to this involve scsi_wait_scan (deprecated apparently) or udev. However febootstrap doesn't use udev, and adding it is a ton of work with a very uncertain outcome. So the minimum possible change is to

v1 -> v2: - I fixed the end condition of the loop in parse_root_uuid. - Retested. Didn't change the busy wait loop into a function or macro, as per discussion on IRC. Rich.

Various patches to make supermin quieter. By outputting fewer messages on the fast path, we use the slow emulated UART less, and this improves boot times. Also remove some kernel modules that we cannot or should not be using, which also improves boot times. Rich.

Instead of specifying a device name (eg. root=/dev/sdb), this permits specifying an ext4 volume UUID (root=UUID=12345678-...). This allows the appliance to be robust against the non-determinism of SCSI device enumeration. --- init/init.c | 226 +++++++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 192 insertions(+), 34 deletions(-) diff --git a/init/init.c b/init/init.c

--- init/init.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/init/init.c b/init/init.c index 25d6bc6..38392c4 100644 --- a/init/init.c +++ b/init/init.c @@ -94,6 +94,15 @@ main () print_uptime (); fprintf (stderr, "supermin: ext2 mini initrd starting up: " PACKAGE_VERSION +#if defined(__dietlibc__) + " dietlibc" +#elif

When building the mini initrd, previously we copied the modules into the initrd as-is, so for example if the module was xz-compressed, we copied the foo.ko.xz file to the initrd. This requires that the mini init binary is linked to zlib & lzma, so that it knows how to uncompress these modules when insmoding them at boot time. Also since the init is statically linked, it required _static_

Allow an alternate libc, such as dietlibc, to be used for the init binary in the supermin appliance. Rich.

Joseph, Please try my modified versions of these patches. These are compile-tested on Fedora and they don't break any existing functionality, but I don't have either urpmi nor a statically-linked xz so I cannot fully test them. I have also fixed detection of zlib (2/3). Rich.

This allows the Linux kernel command line to be specified on the program command line. --- daemon/guestfsd.c | 22 ++++++++++++++++++---- daemon/guestfsd.pod | 6 ++++++ 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c index eef24d5..190ade2 100644 --- a/daemon/guestfsd.c +++ b/daemon/guestfsd.c @@ -130,7 +130,7 @@ static void usage (void)

On Wednesday 17 February 2016 14:22:34 Richard W.M. Jones wrote: > --- > init/init.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/init/init.c b/init/init.c > index 25d6bc6..38392c4 100644 > --- a/init/init.c > +++ b/init/init.c > @@ -94,6 +94,15 @@ main () > print_uptime (); > fprintf (stderr, "supermin: ext2 mini initrd starting

--- .gitignore | 6 +- .gitmodules | 3 - HACKING | 41 +++ Makefile.am | 6 +- README | 7 +- TODO | 61 +--- autobuild.sh | 65 ---- autogen.sh | 12 - configure.ac | 27

Unlink files, symlinks, FIFOs, devices etc. (except directories) before writing them when extracting CPIOs. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non-link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first version of file foo is larger

--- init/init.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/init/init.c b/init/init.c index 473a5c5..a6279b8 100644 --- a/init/init.c +++ b/init/init.c @@ -101,13 +101,19 @@ main () char *root, *path; size_t len; int dax = 0; - uint64_t delay_ns = 250000; + uint64_t delay_ns; int virtio_message = 0; - struct timespec t; int major,

--- helper/init.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/helper/init.c b/helper/init.c index 0ca3135..2b5dacf 100644 --- a/helper/init.c +++ b/helper/init.c @@ -163,8 +163,10 @@ main () chdir ("/"); - /* Run /init from ext2 filesystem. */ + mount_proc (); print_uptime (); + + /* Run /init from ext2 filesystem. */ execl

No functional change, just change the style to the one used by libguestfs. --- init/init.c | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/init/init.c b/init/init.c index e3d1107..473a5c5 100644 --- a/init/init.c +++ b/init/init.c @@ -96,6 +96,18 @@ static char line[1024]; int main () { + FILE *fp; + size_t n; + char *root,

Require the root= parameter is passed to specify which root (apppliance) to mount. Libguestfs has done this since 2012. The other two patches are small code refactorings in the init program. Rich.

The following patch unlinks (deletes) files, symlinks, FIFOs, devices etc before writing them when extracting CPIOs. It doesn't delete directories. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2)

udevadm is included in all reasonable recent distributions. This avoids 'command not found' errors in verbose mode. Signed-off-by: Olaf Hering <olaf at aepfle.de> diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c index e6d5fde..0db56e4 100644 --- a/daemon/guestfsd.c +++ b/daemon/guestfsd.c @@ -54,7 +54,6 @@ #include "daemon.h" GUESTFSD_EXT_CMD(str_udevadm, udevadm);

Hey Guys, I have some questions?regarding?a new home server I am going to build in the hopefully very near future (ASAP, I just need to finish planning everything and this is the penultimate?hurdle), I will be creating a software RAID... Lets say I have three drives "knocking" around which are all 1TB SATA II drives but each made by a different manufacturer. I am going to guess that