Rationalisation of init

News, happenings
Message
Author
gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#61 Post by gyro »

@jlst,

I think there are 2 process here:
1) Upgrade save from one puppy version to another, e.g. tahrpup 6.0.2 to tabrpup 6.0.5. Trying to ensure that any new stuff in puppy...sfs is not hidden by old stuff in the save layer.
2) Update system files if a different set of sfs files are included in the stack, i.e. update menu, update fonts, etc....

Maybe rc.update is more about 2) rahter than 1), and the "init" script is supposed to do 1).

gyro

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#62 Post by Moose On The Loose »

gyro wrote:@Moose On The Loose,

I assume that you are referring to the code processing the "pfix=" boot parameter?

gyro
This case was specific but I was hoping to make a broader point that telling the user something they did was ignored because it didn't make sense should be a common practice. It could also apply to other configuration points like perhaps the video driver not supporting a requested feature.

jlst

#63 Post by jlst »

Yesterday i was testing the new init with the current initrd-tree and static progs and code from rationalise

Added fdrv, ydrv and adrv to push the limits.
First book... ok.
Installed devx, reboot ok.
Second boot.. ok

Reboot.. oh.. it doesn't reboot, it also tries to unmount /pup_rw so I was going to test possible fixes... but it was 1am already (almost 2am).

This is what I know:
executing mount, it showed /pup_rw while all others were "/initrd/pup_*"

/initrd/pup_rw was a broken symlink, so that may explain something.

also checking the savefile, in /initrd/tmp/bootinit.log i see this:

mkdir: can't create directory '/pup_new/initrd/pup_rw': No such file or directory
mount: mounting /pup_rw on /pup_new/initrd/pup_rw failed: No such file or directory

--

The script should delete "/pup_new/initrd/pup_rw" (it may be a broken symlink) before attempting to create the dir

So the question is.. how did this happen?

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#64 Post by gyro »

@Moose On The Loose,

I tend to agree with the principle, but there are limits to how far you can go.
e.g. With boot parameters of the form "param=value", then the code should be able to give a warning if the "value" is not acceptable, but since the "param" is picked-up by name, unacceptable "paramm=" is never decteded.
The new init code tries to log unacceptable "value" to "bootinit.log".
On the other hand, having a catch-all at the end of the "pfix=" code that logs a message, looks like a good idea.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#65 Post by gyro »

jlst wrote:The script should delete "/pup_new/initrd/pup_rw" (it may be a broken symlink) before attempting to create the dir
It's supposed to do this, I will check it.
Although rc.shutdown also used to delete the symlink.
When I've seen a problem like this it was caused by changing from pupmode=13 to pupmode=12, or from savefolder to savefile.
jlst wrote:So the question is.. how did this happen?
I've done so many reboots, I find it hard to believe it's just that.
But while I've used many adrv etc..., I've never introduced an extra sfs like the devx. So it's back to even more testing.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#66 Post by gyro »

@jlst,

I've applied a patch that should fix the left-over symbolic link problem.

gyro

jlst

#67 Post by jlst »

Yes that fixes the issue, but it looks like the devx is not loaded at bootup, running 'sfs_load start' in a terminal window loads the devx and updates stuff.

it looks like the new init is still missing code to load the extra sfs

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#68 Post by gyro »

jlst wrote:it looks like the new init is still missing code to load the extra sfs
Yes, and I have no intention of adding it.
Extra sfs's are left to sfs-load.
When I loaded the devx with sfs-load, every boot produced a "next boot will be faster" message, and the menus were not updated until I did a manual "fixmenus". So more testing of what's happening with the BOOTCONFIG file for me.

I would really like to see a complete separation of the system sfs's handled by init, and the extra sfs's handled by sfs-load. This includes sfs-load not touching any sfs's mentioned in DISTRO_SPECS or PUPSTATE, and not accessing BOOTCONFIG at all, i.e storing it's list of extra sfs's somewhere else.

Oh, thanks for testing.

gyro

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#69 Post by Moose On The Loose »

gyro wrote:@Moose On The Loose,

I tend to agree with the principle, but there are limits to how far you can go.
e.g. With boot parameters of the form "param=value", then the code should be able to give a warning if the "value" is not acceptable, but since the "param" is picked-up by name, unacceptable "paramm=" is never decteded.
The new init code tries to log unacceptable "value" to "bootinit.log".
On the other hand, having a catch-all at the end of the "pfix=" code that logs a message, looks like a good idea.

gyro
I think that all parameters in the "xxxx=yyyy" form end up as environment strings. At least the log could have a dump of all of them. This way there is a chance the person may spot the problem.

jlst

#70 Post by jlst »

Indeed. You're right gyro. sfs_load should be part of the system, so i'll move it to where it belongs, in rootfs-skeleton/usr/sbin, that's where you can add patches

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#71 Post by gyro »

Moose On The Loose wrote:I think that all parameters in the "xxxx=yyyy" form end up as environment strings. At least the log could have a dump of all of them. This way there is a chance the person may spot the problem.
I don't know if they do become enviroment strings.
But you can always see what boot parameters were used with the command:

Code: Select all

cat /proc/cmdline
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#72 Post by gyro »

jlst wrote:Indeed. You're right gyro. sfs_load should be part of the system, so i'll move it to where it belongs, in rootfs-skeleton/usr/sbin, that's where you can add patches
I thought I was just arguing for the separation of responsibility for different sfs files between init and sfs_load, not commenting on it's location.
The current sfs_load tries to fudge this separation by rewriting BOOTCONFIG with only the system sfs files, during shutdown.

I've found my problem with sfs_load, it doesn't play well when you specify adrv... etc with a non-standard filename. But it does, if you use only the names as per DISTRO_SPECS. It needs to ignore the actual filenames as per PUPSTATE, in the same way it does the standard ones as per DISTRO_SPECS.
I was specifying pcmanfm32.sfs as my adrv, and show.sfs as my ydrv.

I'm not likely to be producing patches to sfs_load in the near future.
Although writing an sfs-install utility to replace sfs_load is on my long term bucket list.

gyro

jlst

#73 Post by jlst »

Ok, meanwhile i'll be paving the way with the current init and sfs_load.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#74 Post by gyro »

One other thing that probably should be included is swapfile support.

gyro

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#75 Post by Sailor Enceladus »

edit: Nevermind, found the answers.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#76 Post by amigo »

When passing boot parameters, anything not recognized by the kernel itself is passed unchanged. The same happens with the 'init' program --the real one I mean, not the puppy init script. It also ignores anything it doesn't recognize. The params are not set into the environment but are available from /proc/cmdline.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#77 Post by gyro »

The puppy init script picks up boot parameters by name.
So if you don't get the parameter name correct, then init script will never know about it.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#78 Post by gyro »

One more question:
I understand that the latest losetup does not support all the crypto stuff in the current init.
If that is so, do I take this oportunity to introduce new crypto stuff e.g. ecryptfs?
Or do I simply port the crypto stuff from the current init?

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#79 Post by gyro »

Some folk have noticed that sometimes /initrd/tmp/bootinit.log contains messages from losetup complaining about some sfs's being of incorrect length.
I can confirm that if the 32 byte IDSTRING is removed from the end of these sfs files, losetup no longer complains.

Note: The new init does no use these IDSTRING's anyway.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#80 Post by gyro »

The new init is not a clone of the old init.

Concepts:

The init script should as simple as possible, basically build an aufs stack and get out of there.
So, search for files only if it can't be avoided, and stop as soon as we've found it.
Only wait for usb storage, if it's actually needed.

Move complexitiy out of init to places where the full system is available.
So, processing of extra sfs's is gone, left to sfs_load.

For the sfs files, we know the name of the file we are looking for and the directory we are lookinng in,
so their presence can be established with a simple [ -f ] test.

Build the stack one file at a time, so if there's a problem with one of them we just continue without it.
Current testing is just for being non-zero size, [ -s ] test.
Extra integerity testing could easily be included if the necessary utility was included in initrd.gz.
Of course if it's the main puppy...sfs, we abandon the boot.

A normal frugal install consists of a single directory containing all the necesary files.
So, find the directory that contains puppy...sfs by name, and use the files in it. Don't search for vmlinuz or use DISTRO_IDSTRING.

Any other setup is an exception, any exceptions should be specified with a boot parameter.
(Support for SAVEMARK, initmodules.txt, and underdog.inx files, should ideally be removed.)

Provide extremely flexible boot parameter specification facilities so that virtually any exception can be covered.

Since boot parameters might be considered a bit exotic for some users. Provide an alternate that can be supported from a utility in the running system.
So, include "/BOOT_SPECS" file contained in initrd.gz. The file contains variable definitions, these can be used to override the variables that would otherwise be set by boot parameters.
Could include SAVEPART, PIMOD, or UNDERDOG variables. Of course any init variable could be set. In testing I use it to set TZ to my time zone.
Still needs a utility for the running system to edit a copy of the file and then merge it into initrd.gz. We already have the software technology to do this.
Ideally this could be complex enough to present the user with a series of checkboxes for pfix parameters, or a file selector to generate a PSAVE variable.

Yes, this won't help anyone booting from a cd, but maybe that's on the decline and booting from a writeable device like a usbstick or usbhd is becomming the external boot device of choice.
Although it might be possible to do something with an "open" cd, along similar lines to the "copy folders", I'm not inclined to spend the effort there.


What it does support:

Message translation for non-english puppies using a locale file of messages.
Booting in pupmode 5,6,7,12,13,77
Support for specifying partitions as a name, label, or uuid.
Logs if a specified file is not found.
Save layer upgrading
Savefolder
Savefile and savefile resizing
Encrypted savefile, but this should possibly be removed because current losetup does not support it.

gyro

Post Reply