(old)Puppy Linux Discussion Forum

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

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

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

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

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

Hi 01micko,

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

gyro

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

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

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.

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

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

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.

technosaurus wrote: (see above)

I suggest the following change
Saying what is ignored can be helpful to the "why didn't that work" question when the problem was the seplling of the parameter

@Moose On The Loose,

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

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

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.

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?

@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

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