Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 21 Oct 2019, 06:03
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Process Substitution & The pup initr0/init
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [1 Post]  
Author Message
s243a

Joined: 02 Sep 2014
Posts: 2133

PostPosted: Sun 23 Jun 2019, 16:16    Post subject:  Process Substitution & The pup initr0/init  

Debugging the puppy init can sometimes be challenging because one might lack the needed error reporting. I've made some mods to the puppy init to help with this process:

http://murga-linux.com/puppy/viewtopic.php?p=1029440&search_id=1274928756#1029440

- The two things that I did was to report errors sooner (i.e. before devtmpfs is populated)
- Add legacy device files in the /dev2 folder.

The legacy device files provide a way of reporting errors if for some reason devtmpfs fails and also allow for error reporting prior to devtmpfs being populated.

I recently discovered an error that I have in my /initrd0/init script where the symlink /initrd/pup_ro1 is not being properly created and this is effecting mistfire's puppy package manager.

gyrog tells me that:
Quote:

That symlink is there for old utilites that have /initrd/pup_ro1 hardcoded, rather than being coded the better way.

https://github.com/puppylinux-woof-CE/woof-CE/issues/1469#issuecomment-504771021

so therefore rather than trouble shooting my init script I can patch mistfire's package manager to use the newer philosophy. However, at some point, I'll want to troubleshoot the init script.

**Note that aside from the above modifications; I recently, got my init script from the main branch in woof-CE. As a consequence I"m not sure if the issue is due to woof-CE or my mods.

Anyway, my current error reporting is done with the following line on top of the script:
Code:

exec 1>/dev2/console 2>&1 #s243a

/woof-next/initrd-progs/0initrd/init#L63

The problem with this is that it doesn't send anything to a log file. I'm very weak in my understanding on process substitution. The following thread though might help some with this understanding:
Command to copy a directory to console and save files?


Often when I'm trying to trace output of a script I do the following:
Code:

exec &> >(tee $LOGFILE)


but this is a bashism. What would be the ash equivalent and does the puppy initrd even have the tee command? I'm actually tempted to change the interpreter of the puppy init to bash because for modern computer bash isn't really that large but at the same time it isn't that small either. While adding bash doesn't add that much size, adding a lot of applications of similar size can add up.

One also has to think about the dependencies. Adding a static version of bash might be larger than adding a version which can share libraries with other tools, but the latter approach is only a savings if many tools utilize these shared libraries.

Tinycore takes this shared libarary approach and the core of tinycore is certainly small enough to add to my initrd and I don't think that it would slow down the boot times that much. I can use woof-next to build for instance Tinycore+bash+(puppy initrd0/init sfuff).

Also it really won't waste any space since by doing a switch_root we can remove everything that we don't want:
Quote:

- When switching another root device, initrd would pivot_root and then
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
rootfs, nor unmount it. Instead delete everything out of rootfs to
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
with the new root (cd /newmount; mount --move . /; chroot .), attach
stdin/stdout/stderr to the new /dev/console, and exec the new init.

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Also having a more cable initrd might make it easier to do things like put the save file/folder on the network. Perhaps such an initrd could support multiple boot options where one has the option of either running in inird like tinycore or doing a switch_root like a traditional puppy.

Anyway, that all said there doesn't need to be just one initrd for a given release. One could have an initrd that depends on bash and one that doesn't. One could have an initrd for normal use and one that is designed for debugging. One could even have an initrd that is designed for a network boot.

The only requirement that puppy has is the initrd needs at some point to get the DISTRO_SPECS. Puppy embeds the DISTRO_SPECS in the inidrd. However, a boot option could even be given that says where to find said distro specs, which could be in a: file, sfs, archive (eg. tar) or even in an encrypted drive/folder or file.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 1 of 1 [1 Post]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0275s ][ Queries: 11 (0.0023s) ][ GZIP on ]