Rationalisation of init

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

#46 Post by gyro »

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
Last edited by gyro on Tue 12 Jul 2016, 18:01, edited 1 time in total.

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#47 Post by starhawk »

zdrv is your drivers, gyro. Not just for your network card... ;)

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

#48 Post by Sailor Enceladus »

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...

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

#49 Post by gyro »

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

learnhow2code

#50 Post by learnhow2code »

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?
puppalyzer can help you answer this question.

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

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#51 Post by 01micko »

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
Puppy Linux Blog - contact me for access

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

#52 Post by gyro »

Hi 01micko,

I think you are agreeing with me, only the main puppy...sfs should be considered critical.

gyro

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

#53 Post by gyro »

Another question:
The "upgrade" code in the current init script, is it really needed?
Does any one know?
gyro

jlst

#54 Post by jlst »

I triggered involuntarily one day... when i replaced only the sfs files but forgot to delete the savefile, apparently it did detect a new version.

That's the only time it happened to me since 2012

gcmartin

#55 Post by gcmartin »

Yes, as I remember, when booting a newer version of a PUP from CD/DVD, I am often presented with an option to upgrade prior version session data.

Never knew if the init code was doing this.

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

#56 Post by gyro »

Yes, I know it's there, and it's triggered if it thinks the version being booted is newer than the one in the save.
But, does it do anything that is not done by "rc.update"?
If nobody knows, then I'll have to sort it out the hard way.
(I never do updrades, always start with new savefolder.)

gyro

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

#57 Post by gyro »

The current version does boot ok from hd and usb.
It contains support for pupmodes 5, 6, 7, 12, 13, and 77. Although 6, 7 and 77 are untested.

If I don't post any thing in the next week, it's because I do have a life apart from puppy.

gyro

jlst

#58 Post by jlst »

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.

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

#59 Post by Moose On The Loose »

technosaurus wrote: (see above)
I suggest the following change

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
Saying what is ignored can be helpful to the "why didn't that work" question when the problem was the seplling of the parameter

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

#60 Post by gyro »

@Moose On The Loose,

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

gyro

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

Post Reply