Puppy Linux Discussion Forum

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

gyrog wrote: ↑Tue Oct 13, 2020 1:40 am 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 wrote: ↑Tue Oct 13, 2020 8:06 amProbably binary changes caused issues in Bionic. Since then all the bins have been updated and they are probably overdue for another update.

peebee wrote: ↑Fri Oct 16, 2020 8:46 am 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/

01micko wrote: ↑Sun Oct 18, 2020 7:15 am eSlacko64 is released from init-experiment

peebee wrote: ↑Fri Oct 16, 2020 8:46 am 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 wrote: ↑Fri Oct 23, 2020 12:03 pm

peebee wrote: ↑Fri Oct 16, 2020 8:46 am 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 wrote: ↑Fri Oct 23, 2020 2:30 pm You mean that f2fs modules needs to be builtin rather than a module?
The 5.4.66 config came from Porteus.....

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

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,

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

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.

bigpup wrote: ↑Tue Jun 29, 2021 2:46 pm

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.

dimkr wrote: ↑Tue Jun 29, 2021 3:58 pm

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.

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.

@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'

gyrog wrote: ↑Wed Jun 30, 2021 6:10 am

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!"

gyrog wrote: ↑Mon Oct 12, 2020 10:12 am

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.

gyrog wrote: ↑Wed Jun 30, 2021 6:10 am

@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?

bigpup wrote: ↑Mon Jul 05, 2021 2:26 pm

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

No but "zip" does.

bigpup wrote: ↑Mon Jul 05, 2021 2:26 pm

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?

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?

gyrog wrote: ↑Wed Jun 30, 2021 6:10 am

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

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