Rationalisation of init
A question:
Given "huge" kernels, is the zdrv critical to a boot?
By critical, I mean don't continue on with the boot without it.
My current version considers puppy...sfs as critical, everything else is optional.
gyro
Given "huge" kernels, is the zdrv critical to a boot?
By critical, I mean don't continue on with the boot without it.
My current version considers puppy...sfs as critical, everything else is optional.
gyro
Last edited by gyro on Tue 12 Jul 2016, 18:01, edited 1 time in total.
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
When I boot Slacko 6.3 without the zdrv it makes it to desktop, but my mouse/trackpad doesn't work, even with using the dead mouse trick, and neither my wireless or wired ethernet show up. I did manage to hit Alt-F1 to get to Pmount to mount a drive that had the zdrv in it and put it back in with terminal commands though. Interestingly, "depmod" runs when I remove the zdrv but not when I keep it, and the pcmcia part says 1 2 3 4 5 6 7 8 9 10 before continuing. Maybe this info will be useful, or not...
I have accidently booted without a zdrv, and it did boot to a desktop, but of course without any kernel modules, lots of hardware simply did not work.
I guess my question really is:
If the init script detects that there is no zdrv, should it abandon the boot or continue?
My current thinking is that it should continue, since it will most likely still boot to a desktop (although it will most likely be a crippled one).
Whereas, if the main puppy...sfs is missing the boot is abandoned.
gyro
I guess my question really is:
If the init script detects that there is no zdrv, should it abandon the boot or continue?
My current thinking is that it should continue, since it will most likely still boot to a desktop (although it will most likely be a crippled one).
Whereas, if the main puppy...sfs is missing the boot is abandoned.
gyro
puppalyzer can help you answer this question.gyro wrote:I guess my question really is:
If the init script detects that there is no zdrv, should it abandon the boot or continue?
here is a list of several puppy isos (including modern ones) and whether they contain a zdrv or not:
contains a zdrv sfs file / name of iso
NO / puppy-4.2.1-k2.6.25.16-seamonkey.iso
YES / tahr-6.0-CE_PAE.iso
NO / slacko-5.6-4G-NON-PAE.iso
NO / wary-5.5.iso
YES / Legacy OS 2.1
LTS.iso?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Flegacyoslinux%2Ffiles%2FLegacy%2520OS%25202.1%2520LTS%2520Extra%2520Packages%2F&ts=1467656308&use_mirror=heanet
YES / puppy-3.01-seamonkey.iso
NO / precise-5.7.1-retro.iso
NO / squeeze-5.X.15-SCSI.iso
YES / puppy-2.17.1-nolzma-seamonkey-fulldrivers.iso
NO / pup-431.iso
YES / tahr-6.0.5_PAE.iso
YES / tahr-6.0-CE_noPAE.iso
YES / tahr64-6.0.5.iso
YES / slacko64-6.3.2-uefi.iso
NO / slacko-5.6-PAE.iso
NO / slacko-5.4-firefox-4g.iso
YES / slacko-6.3.2-uefi.iso
NO / slacko-5.7.0-PAE.iso
NO / Lxpup_13.01.iso?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fcheckmatelxde%2Ffiles%2FLxpup-
13.04%2F&ts=1467655822&use_mirror=tenet
NO / racy-5.5.iso
NO / slacko-5.7-NO-pae.iso
YES / yara.iso
NO / slacko-5.4-opera-4g.iso
NO / lupu-520.iso
NO / slacko-5.4-opera-PAE.iso
Hi gyro
Maybe someone could put the zdrv in the main sfs as part of a manual remaster? In that case boot should continue if zdrv is not found.
2 c
Maybe someone could put the zdrv in the main sfs as part of a manual remaster? In that case boot should continue if zdrv is not found.
2 c
Puppy Linux Blog - contact me for access
I think rc.update should take care of this.
But there is something to take into account.
The initrd DISTRO_SPECS is copied to /etc on each boot... rc.shutdown should copy that file to /var/log/DISTRO_SPECS .. so rc.update can try to determine if a newer version is being booted.
Regarding testing for other pupmodes.. well, this is the difficult part.. actually the reality is discouraging.
But there is something to take into account.
The initrd DISTRO_SPECS is copied to /etc on each boot... rc.shutdown should copy that file to /var/log/DISTRO_SPECS .. so rc.update can try to determine if a newer version is being booted.
Regarding testing for other pupmodes.. well, this is the difficult part.. actually the reality is discouraging.
- Moose On The Loose
- Posts: 965
- Joined: Thu 24 Feb 2011, 14:54
I suggest the following changetechnosaurus wrote: (see above)
Code: Select all
while [ "$1" ]; do
case "$1" in
quiet)QUIET=1;;
#other cases here
*): WhineAndWhineAndWhine '"Unrecognized parameter $1 ignored" ;;
esac
shift
done
[ "$QUIET" ] || echo now doing step XX
@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
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
- Moose On The Loose
- Posts: 965
- Joined: Thu 24 Feb 2011, 14:54
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.gyro wrote:@Moose On The Loose,
I assume that you are referring to the code processing the "pfix=" boot parameter?
gyro
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?
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?
@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 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
It's supposed to do this, I will check it.jlst wrote:The script should delete "/pup_new/initrd/pup_rw" (it may be a broken symlink) before attempting to create the dir
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.
I've done so many reboots, I find it hard to believe it's just that.jlst wrote:So the question is.. how did this happen?
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