Firmware loading at bootup, zdrv now unionfs layer

I don't recall if I already mentioned this. Kirk reported that the firmware did not load at bootup, only if module loaded later. That is now fixed.

Heh heh, I have come around in a circle. It was nice having the zdrv mounting directly on /lib/modules, but I thought for ages how to handle extra modules that someone might want to install. Couldn't really think of anything elegant. The whole idea of using the Unionfs layered f.s. is to get Puppy to look like a normal Linux system, and that should also be for /lib/modules I have gone back to the original idea of mounting the 'zdrv' file as a Unionfs layer. There are some restrictions doing this, but it is a good compromise.

A clarification, kirk asked about modules all being in the initramfs, so why worry about a zdrv? It is a build choice in Unleashed. Basically, you can choose either to put all the modules into the initrd, or to build a separate 'zdrv' file.

The first choice, as used in 4.1alpha1, is very simple. All modules are present in the initrd, they get moved over to the main f.s. (and deleted only if free space gets low, which happens automatically in the background). It's nice I reckon. The downside is longer boot time, not much more booting from CD, USB2 or hd, but for USB1 there was feedback that it jumped from 1 minute to 8 minutes! Then there's Zip, where it becomes over 20 minutes!

So, Puppy can be built with a separate 'zdrv' file, as we have done with previous puppies. With this choice, I was looking for a way to have the modules "always present" is is the case with the first choice.

There is a possibility of blending the two. That is, build Puppy live-CD with the first choice, but if someone uses the Universal Installer to install to USB1, then extract the 'zdrv' from the initrd as a separate file. That might work well.

Posted on 30 May 2008, 10:17


Posted on 30 May 2008, 11:11 by kirk
Have you thought about increasing the number of sfs files allowed? Seems I read somewhere that Unionfs2 has less overhead.

Posted on 30 May 2008, 13:33 by ANOSage
System Rescue has just switched from Unionfs to Aufs.

Posted on 30 May 2008, 15:22 by dogone
Unionfs considerations
Here's an interesting exchange debating the gooodness of Unionfs vs Aufs and sound practices in general.

Posted on 30 May 2008, 15:41 by ANOSage
The fs
The contribution of TomasM is especially pertinent.

Posted on 30 May 2008, 20:18 by pakt
JFFS2 vs Squashfs
Barry, could you use the JFFS2 read/write compressed file system instead of Squashfs for zdrv? With this fs, it seems extra modules could easily be written to it.

Posted on 30 May 2008, 20:25 by kirk
The fs
The contribution of TomasM is also wrong, he states that "The inclusion won't make unionfs code better." Unionfs was included in -mm and since then has been nearly re-written. As far as Unionfs vs AUFS I don't know which is better at this point.

Posted on 31 May 2008, 2:13 by dffrey
LWN firmware article
above link to this weeks LWN article on firmware loading from kernel may be of interest

Posted on 31 May 2008, 2:43 by jcoder24
aufs vs unionfs
If I add a sfs module after puppy has booted with uinonfs the system freezes and requires a power cycle to get it going again.

If I do the same thing with aufs, the system continues working. For this reason, every puppy I boot is booted with layerfs=aufs.

Posted on 31 May 2008, 16:57 by BarryK
that lwn article requires a subscription to read.

Regarding comparison of Unionfs and Aufs, yes you have to be careful what is being compared. Puppy4 is using Unionfs version 2.3.3. Some of those discussions may be referring to the Unionfs v1.x series.

Note, I have not compiled the aufs module for Puppy4.

Posted on 31 May 2008, 17:06 by BarryK
Re: SystemRescue
there is no mention in their news page or forum about moving to aufs:

Posted on 31 May 2008, 18:32 by coolpup
Re: SystemRescueCd

Posted on 31 May 2008, 18:50 by ANOSage
there is no mention in their news page or forum about moving to aufs
I read it on DW, dated 2008-05-27 in their notation.
i.e. v1.0.3. Of course, aufs is only 'another'ufs !
Seems to be a problem communicating with its Japanese originator.

Posted on 31 May 2008, 19:16 by coolpup
re article
I have just visited:

"Using the firmware loader for static data", Jake Edge.

The article is available to me, and the first paragraph states:
"The following subscription-only content has been made available to you by an LWN subscriber".

If it is still not available to you, I have uploaded a copy of the web page to these two servers here: