birth puppy by hand - manual hard drive installation

[kethd]

How to give birth to puppy by hand -- doing things the hard way (16dec05)

What if the puppy install scripts don't work for you? This is one tale...

I had a working HDoption2 Puppy106. I wanted to try puppy on a Compact Flash card in an IDE adapter. The CF was already formatted bootable MS-DOS 6.22, which I wanted to keep.

I ran the Install puppy hard drive script. My first experience with option-1. We made a standard boot floppy. But most of the rest of the script failed; I had no CD to give it, so it had no access to the files that it wanted.

I did have the 107alpha ISO download. How to get the files? mkisofs is supposed to allow file extraction, but I could not get it to work, and it was clearly clunky at best. The right way to access iso innards is to mount the file as a loop filesystem. This was all new to me, but mounting loop filesystems is actually key to understanding how puppy works! This is what allows puppy to exist in modular pieces, which are just assembled dynamically at boot time into a working system. The filesystems live within various archive files, so there does not have to be any real live native filesystem anywhere. Puppy comes to life when you boot it, runs while you use it, and then goes back into limbo when you shut it down. Most of the pieces are read-only, and don't have to be saved at the end.

So, I extracted all of the files intended for burning a CD and put them all in the root DOS directory on the CF. I think you don't really need all the files, but I didn't see the harm.

When I tried to boot the CF-IDE from the boot floppy, no joy. It did try, but the lengthy script messages flashed by too fast, and things did not seem to be working right. I tweaked the one-line config.sys on the boot floppy, hoping to find the magic settings for PFILE and PHOME, but the closest I could come was booting into Puppy GUI, but with no working PUPXXX file, so no way to save settings or anything else from one session to the next. I could not find any good documentation about the PFILE and PHOME parameters, so I figured I'd just have to study the source, find out how they were being used, to understand them. I felt that if I could figure out how to make a PUPXXX file manually, maybe that would be enough to get a fully booting Puppy.

In the boot process, first the vmlinux Linux kernel is loaded. Then image.gz. This is a full mini-system image which is mounted into RAM and used. Then the script rc.sysinit runs. This is supposed to figure out where the rest of the pieces of puppy are and assemble them into a full working Puppy. It has to deal with all the possible complications of all the different ways of trying to run pup, from hd, usb, pcmcia, paper tape, cuneiform tablets, etc.

I spent days living with a still-born pup, aborting out of sysinit. A good excuse to finally break through my fear of the Linux command line, with the motivation of a real task to deal with. The tools are very limited at that point, because the bulk of pup, usr_cram.fs, is not yet mounted. So I learned how to mount that:
http://www.murga.org/%7Epuppy/viewtopic.php?t=4626

And because I was not willing to learn the vi text editor, I learned how to load/access the other simple text editor in pup, mp:
http://www.murga.org/%7Epuppy/viewtopic.php?t=4627

Now I could use bash, all of busybox, and edit text files.

But just studying rc.sysinit was not enough. Too complex. What I really needed was to be able to step through it line by line, interactive debugging. I still have no idea how to do that.

I put in echo statements, and ran it over and over, which was educational, but did not accurately simulate the environment when it first runs. To do that, you have to edit the copy that runs the first time. To do that, you have to remaster image.gz. After you unzip it, you have to mount it as a filesystem, to be able to access the files within:
http://puppylinux.org/wikka/RemasterImageGz
http://puppylinux.org/wikka/RemasterThings

I did learn how to make a PUPXXX file by hand. A key skill, so you can control the size, location, etc. Otherwise, it may happen automagically, or not at all, and you may be very confused. The auto process tries to make it the requested size (from the config.sys parameters), but if there is not enough room on the target partition it adjusts the size, to leave at least 8MB.

The standard size seems to be about 256MB. I wanted to learn how small it could be. (My CF is 128MB, and I only wanted to use half of it for pup.) It starts out with about 1.7MB of contents. I think 5MB is a reasonable minimum. You can tell right away if your PUPXXX is mounted/working: just drag a desktop icon to a new location when pup boots. It will complain immediately if it cannot store the relocation info anywhere. Then reboot to make sure -- if it is in the new location, you have a living Puppy with persistence between sessions.

This is the script I used to make PUPXXX by hand:

if [ -e /mnt/home/pup004 ]; then echo "Sorry, pup004 already exists, aborting."; exit; fi
dd if=/dev/zero of=/mnt/home/pup004 bs=1k count=5000
losetup-FULL /dev/loop1 /mnt/home/pup004
mkfs -t ext2 /dev/loop1 5000
fsck -Cpt ext2 /mnt/home/pup004
mount -t ext2 /dev/loop1 /root
cp -a /root0/* /root/
cp -a /root0/.[a-zA-Z0-9]* /root/

ls /root
umount /dev/loop1
fsck -Cpt ext2 /mnt/home/pup004
ls -l /mnt/home/pup*
sync

Resizing PUPXXX seems complicated, because there is a filesystem stored inside a file. When you change the size of the filesystem, you also need to change the size of the file, in tandem. I don't know the official ways to do this. The apparent way to do it by hand would be to make a new empty filesystem, and copy over the old contents.

This process did the trick for me, and I was able to boot into a full working pup. But it turned out the real secret was just to wait through rc.sysinit even though the messages don't make sense and it is messing around with USB. When it says it can't find a good partition, and wants USB, I just tell it hda1 again, and that helps force it to load. Does not make much sense, but that is what it takes.

And I have learned that booting with autoexec.bat rather than config.sys seems to work better. You just rename the file, and take the SHELL= out. You do have to add a working COMMAND.COM to the boot device. Making this change allows me to actually transfer the floppy boot process onto the CF-IDE itself, and have a full self-contained bootable puppy. With the ability to abort the boot process and have a plain working MS-DOS 6.22. And when I use autoexec.bat on the floppy, rc.sysinit runs better for mysterious reasons -- it is not so confused, does not mess around with USB, does not require me to retype hda1, just boots right up!

It is a great joy to give birth to a fully functioning pup, after a long struggle, and a great way to learn Linux hands-on, and have a start on being able to understand how to get pup to work in all the hundred ways one might hope for.

The next things I don't know yet:
* why sometimes losetup is used before mounting loop filesystems, sometimes not
* how to do command line macros in pup
* practical ways to debug/step-through rc.sysinit
* how to get rc.sysinit to make a complete log file, standard or optionally
* useful Gujin parameters?

In all of this, the most valuable general resource, other than google, is:
http://wiki.linuxquestions.org/

The rosetta stone to start with is:
http://www.pupweb.org/puppy/puppy-startup.htm

(All these specifics are for working out of the first partition on a Primary-Master IDE hard drive. Adjust seasoning as required -- YMMV.)

[kethd]

This is interesting/helpful:

The /var/log/messages file is the core system log file. It contains the boot messages when the system came up as well as other status messages as the system runs. Errors with IO, networking, and other general system errors are reported in this file. Other information, such as when someone becomes root, is listed here as well. If services are running, such as DHCP servers, you can watch the action in the messages file. /var/log/messages is generally your first place to
look when you are troubleshooting.

But I only find notes from the kernel there, no log output from sysinit.

These look interesting:
http://www.faqs.org/docs/Linux-HOWTO/Bo ... HOWTO.html
http://www.tldp.org/HOWTO/BootPrompt-HOWTO-3.html

But specifying init= to tiny.exe seems to have no effect.

Linux Boot Process:
http://www.cpqlinux.com/sysinit.html

Details of inittab:
http://docs.rinet.ru:8080/UNIXs/ch16.htm

[Lobster]

Very interesting - though I barely understood some parts

It seems that you have developed an understanding of Puppy and Linux quite quickly, though no doubt much more awaits us all . . .

You ask a lot of questions and incredibly manage to answer many of them yourself - benefitting the whole community. For example in your recent additions to the wiki.

Many thanks

[kethd]

http://puppylinux.org/wikka/PuppyInAnutshell
http://puppylinux.org/wikka/howPuppyWorks
http://www.goosee.com/puppy/development ... works.html