'init' script doesn't always wait appropriately - 'wait4usb' limitations

[gyrog]

The script 'wait4usb', which is called by the 'init' script to do any needed waiting, has a couple of limitations.

1. It only waits for the first USB drive.
If the partition is on a device that is not a usb device, and the device needs waiting, no waiting is done.

2. It only waits for the FIRST usb drive.
If the partition is on a usb device but it is not the fist one to be ready, there is not enough waiting done.

This issue has been mentioned on the forum, viewtopic.php?f=146&t=966.
and as an issue in woof-ce on github, http://www.mediafire.com/folder/hkwe9ykjbmvwb/init-wait.

I have a patched 'init' script that changes the way 'init' does waiing, so that it should work with any technology, not just usb,
and it waits for any specified partition (e.g. with a "pdrv=" boot parameter), to be known to "blkid".
This patched 'init' script is now available for testing on the new woof-ce 'init-experiment' branch.

I have also uploaded a file called 'init_wait-1.sfs' to http://www.mediafire.com/folder/hkwe9ykjbmvwb/init-wait, as another way of testing this 'init' script.
The 'upinit' script contained in 'init_wait-1.sfs' updates the running Puppy as follows:
It copies the current 'initrd.gz' to 'initrd-release.gz', if 'initrd-release.gz' does not exist.
It replaces the 'init' script in 'initrd.gz' with the "test" init script contained in 'init_wait-1.sfs'.

Before you start, you need to be running a fairly recent woof-ce generated Puppy, probably no more than about 1 year old.

To use 'init_wait-1.sfs':
Download the 'init_wait-1.sfs' file
Click on the downloaded file, and then click "View contents"
Click on the 'upinit' file to execute it.
When you get a "Done" message, it is ready to reboot using the "test" init script.
Before you do reboot, you might click on the 'init_wait-1.sfs' file again to unmount it.

Notes:
The location of 'init_wait-1.sfs' doesn't matter, 'upinit' always changes the 'initrd.gz' of the running Puppy.
The 'upinit' script will happily replace the 'init' script on any Puppy, but the older the Puppy the more likely that it will simply be incompatible with the current 'init'.
There is no point in running "Sfs_load" to append 'init_wait-1.sfs' into the Puppy aufs stack.

gyrog

[gyrog]

On reflection, it is quite possible that folk could be generating false negatives by testing 'init_wait-1.sfs' on their favourite Puppy,
because the Puppy is incompatible with the un-patched current standard 'init' from woof-ce.

So I've uploaded 'init_woof-1.sfs' to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
This installs the un-patched current standard 'init' from woof-ce, into your 'initrd.gz'.
If your Puppy fails t o boot with this 'init' script, then there's not much point in trying the patched 'init' in 'init_wait-1.sfs'.

My initial testing:

bionicpup32, and bionicpup64, both failed to find the 'puppy...sfs' after an install using 'init_woof-1.sfs', suggesting nothing really, just that too much has changed in the woof-ce 'initrd.gz' since they were produced.

ScPup32, ScPup64, and fossapup64, all worked after 'init_woof-1.sfs' and also worked after 'init_wait-1.sfs', suggesting that the new waiting code works.

Note: Since the new code implements a new way of "waiting" it would be helpful if testing were done on a Puppy installed on a usb device, so that it is pretty likely to exercise the "waiting" code.

Interesting though, if I transfered the 'initrd.gz' from ScPup32, that contains the patched 'init', to bionicpup32 and replaced the DISTRO_SPECS file with the bionicpup32 DISTRO_SPECS file, it all seemed to work fine.
Similarly for ScPup64 and bionicpup64.
(Maybe, there could be a single 'initrd.gz' and woof-ce simply inserts the appropriate DISTRO_SPECS file into it.)

gyrog

[01micko]

bionicpup32, and bionicpup64, both failed to find the 'puppy...sfs' after an install using 'init_woof-1.sfs', suggesting nothing really, just that too much has changed in the woof-ce 'initrd.gz' since they were produced.

ScPup32, ScPup64, and fossapup64, all worked after 'init_woof-1.sfs' and also worked after 'init_wait-1.sfs', suggesting that the new waiting code works.

Note: Since the new code implements a new way of "waiting" it would be helpful if testing were done on a Puppy installed on a usb device, so that it is pretty likely to exercise the "waiting" code.

Interesting though, if I transfered the 'initrd.gz' from ScPup32, that contains the patched 'init', to bionicpup32 and replaced the DISTRO_SPECS file with the bionicpup32 DISTRO_SPECS file, it all seemed to work fine.
Similarly for ScPup64 and bionicpup64.
(Maybe, there could be a single 'initrd.gz' and woof-ce simply inserts the appropriate DISTRO_SPECS file into it.)

gyrog

Probably binary changes caused issues in Bionic. Since then all the bins have been updated and they are probably overdue for another update.

[gyrog]

Probably binary changes caused issues in Bionic. Since then all the bins have been updated and they are probably overdue for another update.

i'm not going to bother working out why the bionicpup's are incompatible with the current woof-ce 'init' script.
I'll just accept that they are, so using them with 'init_wait-1.sfs' is not a valid test of the "patched" 'init'.

We'll have to make do with Puppies that are new enough to work with the current woof-ce 'init' script.

gyrog

[peebee]

UPupGG+D-Alpha+4 has been built using init-experiment ......
BUILD_FROM_WOOF='init-experiment;8f4c1e337;2020-10-12 19:10:19 +1000'
https://sourceforge.net/projects/zestyp ... %2B/alpha/

[gyrog]

UPupGG+D-Alpha+4 has been built using init-experiment ......
BUILD_FROM_WOOF='init-experiment;8f4c1e337;2020-10-12 19:10:19 +1000'
https://sourceforge.net/projects/zestyp ... %2B/alpha/

Thanks peebee.

Later edit:

I tried it, and here's what happened on my mahine:

I installed it to an internal HD using FrugalPup, booted successfully without any "Waiting" message, as expected.

I installed it to a usb HD using FrugalPup, booted sucessfully with "Waiting for partition [t2Lin]" message, as expected.

I burnt it to a CD_RW using PeasyDisk, booted sucessfully without and "Waiting" message, not as expected,
I expected a "Waiting for partition [iso9660]" message, (maybe my optical drive is not as slow as I thought).

gyrog

[01micko]

eSlacko64 is released from init-experiment.

Code: Select all

#One or more words that identify this distribution:
DISTRO_NAME='eSlacko64 Puppy'
#version number of this distribution:
DISTRO_VERSION=6.9.9.10
#The distro whose binary packages were used to build this distribution:
DISTRO_BINARY_COMPAT='slackware64'
#Prefix for some filenames: exs: eslacko64save.2fs, eslacko64-6.9.9.10.sfs
DISTRO_FILE_PREFIX='eslacko64'
#The version of the distro whose binary packages were used to build this distro:
DISTRO_COMPAT_VERSION='14.2'
#the kernel pet package used:
DISTRO_KERNEL_PET='Huge_Kernel'
DISTRO_XORG_AUTO='yes'
DISTRO_DB_SUBNAME='slacko6414.2'
WOOF_VERSION=9
DISTRO_TARGETARCH='x86_64'
NO_MULTIARCH_SYMLINK=1
BUILD_FROM_WOOF='init-experiment;8f4c1e337;2020-10-12 19:10:19 +1000'

[gyrog]

eSlacko64 is released from init-experiment

Thanks 01micko,

Installed this on a usb HD, booted fine with a "Waiting for partition [t2Lin]" message as expected.
Burnt the iso to a CD-RW, and boot fine, but no "Waiting" message at all.
Installed to an internal HD, booted fine with no "Waiting message".

So on my machine I get similar rewults using 01micko's "eslacklo64" iso, or peebee's "UPupGG+D" iso.

[gyrog]

Now we have some iso files to use for testing,
could some folk who do direct iso booting, please try 1 of them.

[gyrog]

UPupGG+D-Alpha+4 has been built using init-experiment ......
BUILD_FROM_WOOF='init-experiment;8f4c1e337;2020-10-12 19:10:19 +1000'
https://sourceforge.net/projects/zestyp ... %2B/alpha/

UPupGG+D can't boot on an f2fs partition.
The kernel has f2fs filesystem support as a module, the file '/lib/modules/5.4.66-pup32/kernel/fs/f2fs/f2fs.ko' exists, in 'zdrv_upupgg+d_20.10.sfs'.

So, don't bother installing with 'f2StickPup'.

Sorry, I couldn't find a forum topic dedicated to 'UPupGG+D'.

[peebee]

UPupGG+D-Alpha+4 has been built using init-experiment ......
BUILD_FROM_WOOF='init-experiment;8f4c1e337;2020-10-12 19:10:19 +1000'
https://sourceforge.net/projects/zestyp ... %2B/alpha/

UPupGG+D can't boot on an f2fs partition.
The kernel has f2fs filesystem support as a module, the file '/lib/modules/5.4.66-pup32/kernel/fs/f2fs/f2fs.ko' exists, in 'zdrv_upupgg+d_20.10.sfs'.

So, don't bother installing with 'f2StickPup'.

Sorry, I couldn't find a forum topic dedicated to 'UPupGG+D'.

Clarification....?
You mean that f2fs modules needs to be builtin rather than a module?
The 5.4.66 config came from Porteus.....

[gyrog]

You mean that f2fs modules needs to be builtin rather than a module?
The 5.4.66 config came from Porteus.....

Yes, just the f2fs module itself.
Unfortunately the kernel needs to load the f2fs module before it can read an f2fs partition, but if that module is contained in a zdrv...sfs that is stored in an f2fs partition, it's a "catch 22" situation.

To test, make a bootable usb stick with 'f2StickPup' from the iso file of the Puppy in question.
'blkid' knows about the partition, but the kernel can't read it, so 'mount' fails because there is no device.

[peebee]

@gyrog
Will be
CONFIG_F2FS_FS=y
for next 5.4 32-bit build
was previously
CONFIG_F2FS_FS=m

[gyrog]

@peebee, great.

[gyrog]

The new "waiting" code for the 'init' script has been merged into the 'testing' branch of woof-ce.

[bigpup]

One thing that is very important.
Is USB drives, being 100% sure to be found, by the boot process.
There has been tweaking of the initrd, to try and make this work 100%, for all possible computers.

The main problem, seems to be a timing issue.
Not enough time is given, for the USB drive finding, before the boot process, tries to find files, on the USB drive.
The more drives the computer has, the harder it is to find all of them, before the process continues.

The [wait4usb] TIMEOUT= time config is the key to this.
7 or 8 or 9, etc.... seems to be a good time to wait.
Some initrd's have [wait4usb] TIMEOUT=4 or lower.
Those seem to be hit or miss finding USB drives.

If a boot loader is used, that uses UUID to identify a drive, this is not a problem.
But this is not available on a live CD or USB install, because the boot loader is the one in the Puppy version iso.
This has generic boot loader menu entries,

[gyrog]

@bigpup,
The currrent 'init' does not have a 'wait4usb', it has a 'wait_for_dev' that simply sleeps for a predetermined interval.
The default is 5, it can be set by a "waitdev=" boot parameter.

But 'wait_for_dev' is only used when the "search" function fails on it's first try, before it has another go,
or when the 'isoboot' script is not provided with the UUID of the partition containing the ".iso" file,
i.e. when 'init' has no clue as to what it is waiting for.

Mostly 'init' waits for "blkid" to get some information,
usually this is for the LABEL or UUID of a partition,
but if "pmedia=cd" then it waits for an 'iso9660' partition to become known to "blkid".
So if you are booting from an actual CD/DVD, then 'init' will wait, (provided you don't confuse the issue with the presence of an irrelevent 'iso9660' partition, e.g. have a second CD/DVD with media inserted).

If booting from usb stick, and you do a frugal install, then no problem, a "pdrv=" boot parameter is possible.
(Maybe use StickPup, or f2StickPup, or if you have a uefi capable machine, just unzip a ".zip" release of Puppy.)

If booting a ".iso" file, it's the containing partition that needs to be waited for, and this depends on the software that boots the ".iso" passing the UUID of the containing partition in a boot parameter that the Puppy 'isoboot' script recognises.
The grub2 ".iso" boot entries generated by "OtherInstalls" get grub2 to do this.

[bigpup]

That post of mine got moved here.
I did not post it in this topic.

But it was good information to know, that you posted as an answer!!
Thanks!

OK.

Good to now know this modified init is now going to be the one used by Woof-CE for all future versions of Puppy.

So this is a change that will be in any Puppy versions, that use Woof-CE, as it now is?

The Puppy versions made with an older Woof-CE, will still have the problem of wait4usb timeout setting, being too low.

The issue is not being caused by Specific Puppy installers made to install Puppy.
It is trying to use the boot loader config files in the Puppy version, when other installer programs do live installs to a USB.
Those files are configured for booting from a CD.
pmedia=cd
These installers simply copy the files in the Puppy iso onto a USB drive.
They do not make a new boot loader and if they do.
They know nothing about pmedia= options.
It is a problem for all the older versions of Puppy that still use the older version of init.

[dimkr]

The Puppy versions made with an older Woof-CE, will still have the problem of wait4usb timeout setting, being too low.

This is yet another issue that demonstrates Puppy's problem of being a 'one off' distro.

IMHO, Fossapup, Slacko, etc' need an update mechanism and periodic releases (say, once a month) built using the latest woof-CE and the latest Ubuntu/Slackware packages with all the bug fixes and security fixes.

And, woof-CE needs a 'stable' branch (https://github.com/puppylinux-woof-CE/w ... ssues/2191) that only receives bug fixes and no new features, so this update mechanism won't introduce new and half baked woof-CE features.

As an experiment, I've set up automated builds of dpup OS (a Puppy fork) at https://github.com/dpupos/woof-CE/actio ... olling.yml, which uploads them to https://github.com/dpupos/woof-CE/releases and keeps only the two latest builds. The user has a menu entry that updates to the latest build. There's lots of work to do to make this production-grade, but I think the idea is right.

[Grey]

IMHO, Fossapup, Slacko, etc' need an update mechanism and periodic releases (say, once a month) built using the latest woof-CE and the latest Ubuntu/Slackware packages with all the bug fixes and security fixes.

The plan is good. In principle, updates would be enough even once every three months.
It entirely depends on the volitional decision of the developers. Many users do not really try to delve into the intricacies of new updates.

[dimkr]

The question is, why not update? If the update wastes save file space, then SFS-based updates solve this problem. If the problem is bandwidth, then we can use delta updates. If the problem is fear of new issues, then we can deal with that using a 'stable' woof-CE branch that receives only bug fixes, and use this branch to build the updated versions.

[gyrog]

@bigpup,
1. Backporting a fix such as the 'wait_for_blkid' is possible, but it would mean manually "patching" the 'init' on each Puppy, but which Puppies?
And who is motivated to do it?

2. Concerning third-party installers that don't handle Puppy well:
I complained to my doctor that there was something wrong with my body, it didn't handle fatty foods well any more.
His response, "Well, don't eat fatty foods."

Edit: I originally ommited the word 'wrong'

[Grey]

I complained to my doctor that there was something with my body, it didn't handle fatty foods well any more.
His response, "Well, don't eat fatty foods."

Another version (common in Russia)
An 80-year-old man came to the doctor.
"Doctor, you know, for some reason I have ceased to satisfy my young mistress..."
"So what do you want, my friend, you are 80 years old!"
"But my neighbor is 90 and he says that he is all right..."
"Aaaa! Just start telling everyone the same thing as your neighbor!"

[wiak]

The script 'wait4usb', which is called by the 'init' script to do any needed waiting, has a couple of limitations.

1. It only waits for the first USB drive.
If the partition is on a device that is not a usb device, and the device needs waiting, no waiting is done.

2. It only waits for the FIRST usb drive.
If the partition is on a usb device but it is not the fist one to be ready, there is not enough waiting done.

This issue has been mentioned on the forum, viewtopic.php?f=146&t=966.
and as an issue in woof-ce on github, http://www.mediafire.com/folder/hkwe9ykjbmvwb/init-wait.

I have a patched 'init' script that changes the way 'init' does waiing, so that it should work with any technology, not just usb,
and it waits for any specified partition (e.g. with a "pdrv=" boot parameter), to be known to "blkid".
This patched 'init' script is now available for testing on the new woof-ce 'init-experiment' branch.

That's good for Puppy, but I will point out that the presented solution "waiting in a loop for the specified partition" is not an original idea. Rather it was an idea contributed by old forum member seaside to WeeDogLinux and used for a year or two there already whether via specification of UUID or LABEL. So thanks overall go to seaside for this.

[bigpup]

@bigpup,
1. Backporting a fix such as the 'wait_for_blkid' is possible, but it would mean manually "patching" the 'init' on each Puppy, but which Puppies?
And who is motivated to do it?

2. Concerning third-party installers that don't handle Puppy well:
I complained to my doctor that there was something wrong with my body, it didn't handle fatty foods well any more.
His response, "Well, don't eat fatty foods."

Edit: I originally ommited the word 'wrong'

Hard to do if all the other non-Puppy OS's only provide fatty foods!

So, someone make a Puppy specific frugal installer program, that will run in Windows and other Linux OS's.
We can tell everyone to download and use it to do Puppy Linux installs.
Lick Installer does that for Windows OS.
But, I am not sure it can install to anything, but the computers internal drive or make a boot loader, on other drives.
Have not really used it.

Does Frugalpup Installer run OK in other Linux OS's?

[gyrog]

[Does Frugalpup Installer run OK in other Linux OS's?

No but "zip" does.

[wiak]

Hard to do if all the other non-Puppy OS's only provide fatty foods!

Kindly explain "all the other non-Puppy OS's only provide fatty foods!". Are you insulting all non-Puppy OS's on this forum or is your insult against all Linux distros that are not featured on this forum, or both sets?

[rockedge]

other non-Puppy OS's only provide fatty foods!

I point you to my plugin for the WeeDog build scripts that will build such a minimal system you can barely find it after it's installed. I also know of an operating system written completely in assembly code. That will blow away any other OS in small size and speed if that is the parameters.

Do you mean with "fatty foods" GUI eye candy bloat and useless features?

[perdido]

@bigpup,
1. Backporting a fix such as the 'wait_for_blkid' is possible, but it would mean manually "patching" the 'init' on each Puppy, but which Puppies?
And who is motivated to do it?

2. Concerning third-party installers that don't handle Puppy well:
I complained to my doctor that there was something wrong with my body, it didn't handle fatty foods well any more.
His response, "Well, don't eat fatty foods."

Edit: I originally ommited the word 'wrong'

The other linux OS cannot only be considered fatty foods to how puppy functions, they can be poisonous and kill a puppy by trying to mix and match install methods into a "one size fits all" installation approach. When that happens it makes more work for people such as yourself to fix and Bigpup to help troubleshoot, that is if the person that was trying puppy is even still interested in trying puppy after the installation fail and makes an account here to post a question.

The landmines of fatty foods and choker collars (and other sinister things, of course) can hopefully be minimized enough to keep puppy as an install option as there are now many OS that try to mimic the spirit of puppy linux, making it essential for puppy linux to get to a bootable install on just one try. Thanks for all the puppy innovative contributions!

May the force stay with you.

[bigpup]

other non-Puppy OS's only provide fatty foods!

This was an answer to a joke!

I complained to my doctor that there was something wrong with my body, it didn't handle fatty foods well any more.
His response, "Well, don't eat fatty foods."

But if you need an example:
About 2.3 GB of fat compared to Puppy Linux.
.

Screenshot(7).jpg (17.57 KiB) Viewed 2440 times