4.1 UniPup alpha1

This is really version "403" but built with the UniPup scripts. As I already announced, it is like Slitaz in that it runs in the initial ramdisk. However, I tackled the problem of the footprint in RAM. When the 'initrd.gz' loads into RAM, I have got most of the files compressed in the initial ramdisk, one way or another. Some executables are UPXed, but as most of the files are in /usr, I have turned /usr into 'usr_403.sfs' and it gets mounted on /usr (as a layered f.s., with tmpfs on top).

This is kind of a return to the Puppy1 days, but I aimed at having the entire '/' writable. That is, a package can be installed and not be restricted to being installed into /root like it was in Puppy1.

The key to the whole thing is the main boot script, /etc/rc.d/rc.sysinit, and I must pat myself on the back. It is very simple and carefully designed to boot as fast as possible without 'sleep' padding. It has pauses where it waits for slow hardware to become available, based on my experiences in this area. There is also a workaround for a kernel "bug" with not generating uevents when it "should have", that I reported on this blog awhile back.
Jesse, you will see your 'elspci' there, a most important component. I left out probing for serial devices, as that has always been troublesome, and slows down bootup -- instead, there can be simple user selection of serial devices, mouse or modem. In the case of modem, a "probe" in PupDial should do the trick.

Bootup is reasonably fast. On my 2GHz Celeron CPU desktop PC, the live-CD boots in 36 seconds on second boot. On the first boot, there are the keyboard/video questions, but also 'usr_403.sfs' is not copied to RAM. Oh yes, this handles 'usr_403.sfs' being inside initrd.gz ("humongous" pup) or anywhere outside -- it can be anywhere, on any partition, and Puppy will find it at bootup. I have built the first demo live-CD iso with it outside. If outside, it is never loaded into RAM, which means on first boot things will be a bit sluggish as it is on the CD -- but after a pup_save file is created usr_403.sfs is copied to same place as the pup_save, thus freeing up the CD.

Now, I've done something interesting with session saving. You will need to examine /etc/rc.d/rc.shutdown, again a very small and simple script. All it does is turn all new files into a tarball, 'pup_save.tar.gz'. At bootup, a record of files in the initrd.gz is made, so they are excluded when the session is saved. I thought, why have a savefile that is a ext2 or ext3 filesystem and thus needs to be resized? Just have a tarball, that grows as needed. This suits the Flash memory environment where writes to memory have to be minimised. Oh yeah, it's also compressed.

I have uploaded the first demo, 4.1 'UniPup' alpha1. This has the saving as described above, but what I plan to do next is to save usr-installed packages into initrd.gz and usr_403.sfs -- if they are in a writable partition.

For anyone who would like to play with it, get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/unipup-alpha1/

I welcome ideas, but not bug reports. It has bugs, I'm working on them. Unless you find something that is a real show-stopper, then let me know.
I have run it from CD and Flash pen drive, so it will probably work fine as a frugal install. If you want to try the humongous variant, then you would have to open up initrd.gz (it is a gzipped cpio archive) and put usr_403.sfs inside it -- this approx doubles the boot time of course.

One other thing. This UniPup is built with my 'pup_event_backend_d' script, and there is still the problem of the inotify messaging to the 'pup_event_frontend_d' breaking if X is restarted. I will work on that, also will release a build based on the 'udev' package -- I have built automatic support for either into rc.sysinit.

Yet one more note, I'm still on the 2.6.25.9 kernel, and vmlinuz and initrd.gz are only gzipped -- no LZMA yet.

Ahem, appending yet another note. For those interested in the technical side, there is no /init script. /init is a symlink to /bin/busybox, so the first script that executes is /etc/rc.d/rc.sysinit.

---

Comments

Unipup
Username: kirk
I'm posting this from Unipup on a frugal install. Very interesting. A few (maybe errant) observations: It Looks like the R/W space is limited to the RAM disk. Could be problematic. A swap file might help. A lockup or power outage and all changes are lost. Saving and restoring to a compressed tar-ball may be time consuming with a lot of files. I like the idea of running from the initrd, faster boots, less complication, no switch_root. I would miss the unionfs/aufs layers of Puppy 2/3/4. Perhaps a return to Puppy 1's system of one directory unioned with symlinks to the other root directories would be best. Maybe this should be Puppy 5alpha1 if this is the future direction.

Re: future direction
Username: BarryK
"No, I'm not thinking of it as the future direction, just as a parallel project. It's part of Unleashed, so not a separate project even. Just a different choice when building the live-CD. As far as I can see, UniPup in its current form is useful for Network booting, for diskless thin stations and for booting from Flash memory. I don't think it is suitable (in current form) to replace the "normal" Puppy. But, it will be interesting to identify what the limitations are and see if they can be resolved, to make it more generic. I might as well mention a plan in the back of my mind, regarding the tarball save file. It does open the possibility of easy "rollback", like we have in the multisession DVD where earlier sessions can be blacklisted. We could do this by having a rolling system of two or more tarball save files. Each will only have the latest files, so there is not much time required for doing a new save.

amazing
Username: urban soul
"quote:"At bootup, a record of files in the initrd.gz is made" ... is this the end of unionfs?

3 user files (2 customizable)
Username: Raffy
"This would open up the use of 3 user files: 1. initrd.gz - user can choose to customize initrd.gz for his/her hardware (useful for network-booting and also makes booting very fast); 2. usr_xxx.sfs - user can customize the software part of the system; 3. pup_save.tar.gz - Puppy does a save to this file IF any file has been saved to the user's home directory (skip saving if no file was saved). Of course, encryption can also be done for the pup_save.

Re: save-file
Username: BarryK
"kirk, That's a very interesting suggestion. I was wondering just what could be symlinked into usr_xxx.sfs -- /lib cannot be, as 'depmod' does not follow symlinks -- that is a feature of depmod that has annoyed me and there is no override. depmod does have a '-b' option which can have an alternative path, but it has to be a top-level directory which has /lib in it. So, I think /lib cannot be symlinked and would have to got to the tarball.

re: re: save-file
Username: kirk
"If you put /lib into /usr/.linked/lib and do depmod -b /usr/.linked, that works. You could put /root /opt etc. into /usr/.linked just to keep it neat. But I'm not sure when /lib needs to be availble for automagic module loading. Now you probably know the answer to that. I would hate to slow down the boot if the hardware would need to be re-probed. Unipup boots twice as fast as alpha3 and I don't load the sfs file to ram. My wife doesn't use Puppy because she says it boots to slow. She's compairing it to XP un-hibernating. On my laptop XP un-hibernates in 12-13 seconds (512MB). Frugal Unipup boots in 15 seconds. I noticed there are some modules that you are loading at every boot. You might want to just include them in the kernel the next time you build it.

Wow
Username: Prit1
"Barry, I am amazed at how fast this Unipup boots on my laptop. I think I will use this to show off Puppy. Thanks a lot, Prit

Alternate Download Links
Username: Prit1
"Here is an alternate download link incase you have problems with Ibiblio. I had to try 15 times to get a succesful download from ibiblio and it was pitiably slow. http://puppylinux.ca/puppyfiles/test/unipup-alpha1/

Tags: puppy