Surviving guide building a new ISO for Classic Pup 2.14X

[clarf]

In a Full Install Puppy, it's easy to upgrade the kernel. But build an updated ISO, that is a real challenger task.

Before Kernel Update: Classic Pup 2.14X (http://www.murga-linux.com/puppy/viewtopic.php?t=42553). kernel 2.6.18.1. Squashfs3.1 and Unionfs 20060916-2203.

Full Install Upgrade, the easiest way:

You can download the kernel sources in Barry´s /woof sources (there are kernel sources already patched for Classic Pup 2.14X here, http://bkhome.org/sources/kernel-2.6.18.8/)

Patch versions are:

• # Squashfs3.3-patch and unionfs-2.5.1.

Follow the kernel compilation process in:

http://www.murga-linux.com/puppy/viewtopic.php?t=33461

After kernel compilation and installation, vmlinuz file must be updated and /lib/modules/modules.*.new_kernel_version files should be copied.

Puppy should boot with the new kernel now.


Errors creating a new ISO with updated kernel, listing in appearing order:

1. vmlinuz: If you forget to change the vmlinuz, then updated modules could not be loaded from initrd, new kernel just can´t find the right module´s directory because the uname-r gives another kernel version.

2. PUP_214X.sfs: When starting with a new initrd there are boot errors when PUP_xxx.sfs is mounted, tested with boot paramter "pfix = rdsh" shows it is mounting multiple .SFS file versions but loop devices mount fails completely. After a quick check to kernel sources I found Barryk´s configuration file is ready to use Squashfs but as an external module (Kernel Menu - FileSystems - Others - Squashfs, option M), that means the kernel is patched to support the system squashfs file but not loaded internally in the kernel, it must be loaded using imode or modprobe inside the initrd. Then, Kernel can be reconfigured to integrate the squashfs module and a new vmlinuz version must be created, now Puppy using GRUB boots normally with the new initrd (which contains the modules updated to 2.6.18.8.) and vmlinuz, even newer SFS files from Puppy 4 or choicePup are loaded (cause of a new Squashfs3.3 patch). When the squashfs is uploaded this always appears in the dmesg, showing the new 3.3 version.

3. Now zdrv: lib/modules/2.6.18.8 contents are fully copied to zdrv_214X.sfs, as you leave the directory /lib/ firmware/ intact in the zdrv files, multiple errors occurs when Puppy starts with zdrv. To fix it the lib/modules/firmware.dep.2.6.18.1 file must be copied to the zdrv and must be rename to firmware.dep.2.6.18.8 to avoid errors.

4. Xorg: Whit a pup_214X.sfs, vmlinuz and zdrv_214X.sfs ready, Puppy Linux starts with Xvesa, but Xorg does not work. It opens a black screen with the X mouse pointer, but Windows Manager does not start. The xinit output redirected to xerrs.log shows something like:

Code: Select all

Waiting for X server to begin accepting connections.
..
..
..

xinit: Connection refused (errno 111): unable to connect to x server.

After three months of hard research I found a workaround: If I change the xinit command in xwin removing the -nolisten tcp parameter, then I can start Xorg with JWM.

I know that this "nolisten tcp" forces Xorg to create a unix socket instead TCP to connect Xorg server with local client, but Why is Xorg failing to use the unix socket?. I can see a /tmp/.X-unix directory when Xorg tries to initiate and it has full permissions.

The Adventures continues...

[clarf]

Found Xorg´s problem source (creating a unix socket) and implementing a good solution:

After I made the kernel update documentation for Puppy´s forum, I took a second look to the Xorg problem. Removing the -nolisten tcp parameter to xwin has many disadvantages, it´s a security hole and use many tcp ports that are slower than unix sockets.

I downloaded strace and did additional tests.

Code: Select all

strace -o /tmp/error.log startx

Found some errors related to unix socket, but nothing really relevant...

PF_FILE,SOCKSTREAM
family=AF_FilE, PATH=temp/X11-unix/X0
ECONNREFUSED
The server has actively refused to establish the connection.

After a small nap at work, I get enlightenment. I remembered that long time ago, I had some problems mounting ISO files from a unionfs directory, related to mount loop devices in unionfs tree, if I mount a loop devices from a common Filesystem the problem is solved.... So, I guess that the updated unionfs version used to patch the new kernel could have some bugs creating unix sockets.

When I replaced the /tmp with a symlink to point to a external partition, X11 boots normally. GREAT, this confirms my theory about a kernel/unionfs problem creating a unix socket in /tmp.

hmmmm, I could implement some solutions:

1.patch kernel again with a different unionfs versions, recompile and retests, if I use a different unionfs version I could solve this particular problem but new problems could arise and I have to waste a lot of time.

2. Use aufs, I don´t know about Puppy related problems with aufs and I must make massive modifications to init scripts.

3. Update initrd and mount /tmp as a tmpfs, using: "mount tmpfs -t tmpfs /tmp" or "mount /dev/ram -t tmpfs /tmp". It seems a better solution, /tmp as a tmpfs can speed up applications that read/write continuously in /tmp, also in Puppy Mode 5 the /tmp directory will be independent from a pup_save file decreasing the pup_save usage.

The third one was a really good solution, I just added some command lines to initrd and everything works nice now.

I limited the amount of memory used for /tmp reading the SYSTEM swapsize and total memory, using SWAP is faster for the /tmp directory even with low RAM systems.

[jemimah]

You may also have similar problems with /dev/shm (random kernel panics). At least I did during my experiments with UnionFS.

Switching to AUFS may be worth your time. At least the latest versions of UnionFS have some real showstopper problems.

With a newer kernel, you can possibly drop in a newer version of the initrd. I think recent versions of the init script are mostly backwards compatible and work with either AUFS or UnionFS.