The strange case of init script in initrd.gz

Please post any bugs you have found
Message
Author
mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

The strange case of init script in initrd.gz

#1 Post by mistfire »

Hello

I will tell you the strange case of init script in initrd.gz. My USB pendrive has puppy files (Slacko 6.3.2) inside /boot folder using syslinux as a bootloader (FAT32 filesystem is used). At first when booting from USB puppy works fine even there is no main SFS file in the hard disk.

However after subsequent boot, suddenly the init script of slacko cannot find the main SFS file even it is exists. I try to other computer, the same error is shown. However if I boot older puppies (Puppy Linux 4.0 and Puppy 4.3.1) it finds the their main SFS file on my pendrive and load it on RAM. While the newer slacko 6.3.2 cant find its puppy SFS file from my pendrive unless if the slacko main SFS file is put on the hard drive partition.

I used the latest woof-ce init script. It shows the same error according to the last bootlog created by woof-ce init main SFS in sda1 is missing. It does not jump to my pendrive and search for main SFS file.

What is the problem within the init script?

jlst

#2 Post by jlst »

I'm not sure about the problem, the init script had a major rewrite, a few months ago.

And you can't use the latest initrd init script from woofce for old releases unless you built the whole iso using the woofce build scripts.

It's changing and is practically incompatible with older puppies. I'm about to add support for luks-encrypted savefiles.

mcradventures
Posts: 10
Joined: Wed 25 Jan 2017, 08:09

#3 Post by mcradventures »

It sounds like a problem I read about in another post (sorry, can't remember where it's at). If it is, try booting again a few times. I usually have to boot my Slacko 2-3 times before it finds the main sfs file. It's a bug, but that's the only workaround I've found. At first when I noticed it I thought it was a misconfiguration with the bootloader but later found out it wasn't.

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#4 Post by drunkjedi »

I have tahr64 on usb drive booting with syslinux.
Savefolder is on sda7, ext4, on top not in a subdirectory.

If I put no boot parameter in append line, it fails to find the savefolder.
Even the Boot parameters wiki page says it's best not to add pmedia option and puppy will find the files automatically.
It only finds the savefolder when I put pmedia=satacd.
I have to fool puppy that it boots from a CD.

I would very much like to boot puppy from USB but load savefile, main sfs and adrive, ydrive or zdrive from where I put them on hdd.

I can do this easily in fatdog with boot parameters 'savefile=location', 'basesfs=location', 'extrasfs=location'.

So my fatdog doesn't waste time searching for files and boots faster as it loads those files from hdd.

I searched for similar boot options for a puppy, didn't find them yet.

Could anyone with the knowledge guide me?

jlst

#5 Post by jlst »

drunkjedi wrote: I can do this easily in fatdog with boot parameters 'savefile=location', 'basesfs=location', 'extrasfs=location'.

So my fatdog doesn't waste time searching for files and boots faster as it loads those files from hdd.

I searched for similar boot options for a puppy, didn't find them yet.
In https://raw.githubusercontent.com/puppy ... README.txt

see Boot parameters:
psave=
pupsfs=
zdrv=
fdrv=
adrv=
ydrv=

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#6 Post by mistfire »

@jlst I used the rewritten init script on slacko 6.3.2 initrd.gz, I extract the initrd.gz apply the rewritten init script, put some missing scripts needed by new init script, and return it back to initrd.gz.

The scenario was just boot slacko 6.3.2 without any parameters. But based on bootlog created by new initrd it always stops at sda1 on searching main SFS file it does not jump to other drive to search main SFS if it not exists on sda1.

@drunkjedi I already tried pmedia parameter but still it cant find the main SFS file even it exists.

jlst

#7 Post by jlst »

mistfire wrote:@jlst I used the rewritten init script on slacko 6.3.2 initrd.gz, I extract the initrd.gz apply the rewritten init script, put some missing scripts needed by new init script, and return it back to initrd.gz.
It's the other way round. You must use a recent woofce initrd.gz.

The init script is tested with all the new compiled static binaries... they are all the latest releases (except grep). I compile and release new static binaries when an update is available.

The only thing you have to replace is the DISTRO_SPECS file... the latest release (posted by Sailor Enceladus, peebee) comes with a initrd.gz with busybox 1.26.2

Beyond that, i can't help. People are supposed to follow the "main" development team, giving suggestions on what to do, and testing the latest releases.

This a fairly recent release by Sailor Enceladus:
https://my.pcloud.com/publink/show?code ... FHxVMKn2dy

You might want to try to make it smaller... of course it's possible to build slackos with older slackware versions. I'll see if someone is willing build one of those...

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#8 Post by drunkjedi »

jlst wrote:In https://raw.githubusercontent.com/puppy ... README.txt

see Boot parameters:
psave=
pupsfs=
zdrv=
fdrv=
adrv=
ydrv=
Thanks mate.
I am at work now, I will try them tomorrow.
I will remove that pmedia option and try with these options.

Thanks for the link too. The wiki I found didn't have this much details.
Thanks again.

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#9 Post by Marv »

@jlist I have a quick question on the new init, maybe a better place to post but you are here... When passing fsck as a kernel parameter, even though the OS is set to use a utc hardware clock and that hardware clock is correctly set, the fsck always reports the last savefile mount was in the future etc. date and hwclock agree run in the system agree. Running fsck on the savefiles from within the system doesn't give that error. Putting a BOOT_SPECS file in the initrd.gz with TZ='XXX-6' in it (my TZ) doesn't change things at all. At first glance, it seems that the TZ/hwclock set occurs at line 896 in init while the fsck occurs earlier around line 130. Could it be that at the time fsck is invoked the timezone hasn't been applied while later and when unmounting a savefile it has? Sorry if this is dumb but no-one better to point me right than you. I was modifying my ignore=usb utility to work with the new init so I took a look.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

jlst

#10 Post by jlst »

Marv wrote:@jlist I have a quick question on the new init, maybe a better place to post but you are here... When passing fsck as a kernel parameter, even though the OS is set to use a utc hardware clock and that hardware clock is correctly set, the fsck always reports the last savefile mount was in the future etc. date and hwclock agree run in the system agree. Running fsck on the savefiles from within the system doesn't give that error. Putting a BOOT_SPECS file in the initrd.gz with TZ='XXX-6' in it (my TZ) doesn't change things at all. At first glance, it seems that the TZ/hwclock set occurs at line 896 in init while the fsck occurs earlier around line 130. Could it be that at the time fsck is invoked the timezone hasn't been applied while later and when unmounting a savefile it has? Sorry if this is dumb but no-one better to point me right than you. I was modifying my ignore=usb utility to work with the new init so I took a look.
Actually the hwclock set occurs early. All the code before MAIN consists of functions that will be used later.

This is the code:

Code: Select all

[ "$TZ" ] || TZ='XXX-20'
export TZ
hwclock -l -s
I'm not sure it was already there before or gyro added it

Change it to this:

Code: Select all

[ "$TZ" ] && export TZ
hwclock -l -s
And don't add TZ= to BOOT_SPECS.

Repackage initrd.gz, test and report here if that makes any difference..

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#11 Post by Marv »

jlst wrote:
Marv wrote:@jlist I have a quick question on the new init, maybe a better place to post but you are here... When passing fsck as a kernel parameter, even though the OS is set to use a utc hardware clock and that hardware clock is correctly set, the fsck always reports the last savefile mount was in the future etc. date and hwclock agree run in the system agree. Running fsck on the savefiles from within the system doesn't give that error. Putting a BOOT_SPECS file in the initrd.gz with TZ='XXX-6' in it (my TZ) doesn't change things at all. At first glance, it seems that the TZ/hwclock set occurs at line 896 in init while the fsck occurs earlier around line 130. Could it be that at the time fsck is invoked the timezone hasn't been applied while later and when unmounting a savefile it has? Sorry if this is dumb but no-one better to point me right than you. I was modifying my ignore=usb utility to work with the new init so I took a look.
Actually the hwclock set occurs early. All the code before MAIN consists of functions that will be used later.

This is the code:

Code: Select all

[ "$TZ" ] || TZ='XXX-20'
export TZ
hwclock -l -s
I'm not sure it was already there before or gyro added it

Change it to this:

Code: Select all

[ "$TZ" ] && export TZ
hwclock -l -s
And don't add TZ= to BOOT_SPECS.

Repackage initrd.gz, test and report here if that makes any difference..
That fixes it. Several reboots to check and fsck now reports as expected.

Edit: init in LxPup 17.01.23, built from Rationalize branch, also patched per above. Works there also. Now tested on core 2 duo, Pentium M and Bay Trail (J1900) machines.

Thanks,
Last edited by Marv on Sat 28 Jan 2017, 23:46, edited 1 time in total.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#12 Post by mistfire »

@jlst it seems that the init script seems loose reliability a little bit compared to previous init script. I suggest to look at the code of previous (puppy 4.x) init (searching main SFS part) and adapt some part to the latest init script.

By the way aside from searching main sfs issue. the execution of depmod is slow on highly compressed main sfs file (This can be done by setting 1M block size in mksquashfs). Is there anyway to make the execution of depmod faster for highly compressed sfs file

jlst

#13 Post by jlst »

mistfire wrote:@jlst it seems that the init script seems loose reliability a little bit compared to previous init script. I suggest to look at the code of previous (puppy 4.x) init (searching main SFS part) and adapt some part to the latest init script.

By the way aside from searching main sfs issue. the execution of depmod is slow on highly compressed main sfs file (This can be done by setting 1M block size in mksquashfs). Is there anyway to make the execution of depmod faster for highly compressed sfs file
Probably, but with the latest init you can provide debug info.

You see that it's not able to boot, just type 'debugsave', specify the partition where the debug data will be saved.. then reboot. Post the whole directory here.

Well, there is a reason people with slow hardware complain about xz compression. If you don't want it to slow down the boot process, then include the generated depmod stuff by default. I think woofce puppies include it by default, at least the recent ones..

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#14 Post by mistfire »

@jlst however, generated depmod stuff does not include on puppy remastering.

UPDATE: Okay I made some hack on puppy remaster script to include generated depmod files.

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#15 Post by mistfire »

@jlst here is the debug files that you need.

Here is the content of bootinit.log

Code: Select all

0: PMEDIA= PDRV= PSUBDIR= pfix=
1: PDRV= P_BP_ID= P_BP_FN=
2: LOOK_PUP=yes LOOK_SAVE= PMEDIA=
3: PSUBDIR= P_BP_FN= P_DEF_FN=puppy_xslacko_4.2.sfs
HAVE_PARTS='sda1|ntfs'
TRY_PARTS='sda1|ntfs'
4: ONE_PART=sda1
2: USBDRVS=sdb| -> sdb
3: PSUBDIR= P_BP_FN= P_DEF_FN=puppy_xslacko_4.2.sfs
HAVE_PARTS='sda1|ntfs
sdb1|vfat'
param='sdb'
TRY_PARTS='sdb1|vfat
sda1|ntfs'
4: ONE_PART=sdb1
4: ONE_PART=sda1
6: ONE_PART=sda1 ONE_TRY_FN=/puppy_xslacko_4.2.sfs PDRV=
Note: The init does not jump on sdb1 if the main sfs file is not exists on sda1
Attachments
zz_initrd_tmp.zip
(23.05 KiB) Downloaded 241 times

jlst

#16 Post by jlst »

I know why it failed. It's missing psubdir=/boot

I think the file is: /boot/puppy_xslacko_4.2.sfs
but you have to confirm that.

The old behavior was to search in all subdirectories. If you had 200 directories, it would search in all of them.

Although /boot is a standard location for the kernel.. this might be solved by adding a single line after:

[ -f "${ONE_MP}${ONE_TRY_FN}" ] && ONE_FN="$ONE_TRY_FN"

this new line:
[ $? -ne 0 -a -f "${ONE_MP}/boot/${2}" ] && ONE_FN="/boot/${2}"

so what do you think...

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#17 Post by mistfire »

jlst wrote:I know why it failed. It's missing psubdir=/boot

I think the file is: /boot/puppy_xslacko_4.2.sfs
but you have to confirm that.

The old behavior was to search in all subdirectories. If you had 200 directories, it would search in all of them.

Although /boot is a standard location for the kernel.. this might be solved by adding a single line after:

[ -f "${ONE_MP}${ONE_TRY_FN}" ] && ONE_FN="$ONE_TRY_FN"

this new line:
[ $? -ne 0 -a -f "${ONE_MP}/boot/${2}" ] && ONE_FN="/boot/${2}"

so what do you think...
You are right. My main SFS file was in /boot folder

Nice idea @jlist. Much better if you add another boot option/parameter to search all subdirectories.

I suggest that the subdirectory depth was 2 (for example /boot/x-slacko/ folder) in case of fully organized bootable usb or just search all subdirectories if psubdir is not specified.

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

#18 Post by gyro »

mistfire wrote:Much better if you add another boot option/parameter to search all subdirectories.

I suggest that the subdirectory depth was 2 (for example /boot/x-slacko/ folder) in case of fully organized bootable usb or just search all subdirectories if psubdir is not specified.
Why not just add "psubdir=/boot/x-slacko" as a boot parameter.

You have to specify exactly where vmlinux and initrd.gz are, to the bootloader, why not tell init exactly where the puppy files are???
This information must be known when the puppy is installed.

gyro

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#19 Post by drunkjedi »

jlst wrote:
drunkjedi wrote: I can do this easily in fatdog with boot parameters 'savefile=location', 'basesfs=location', 'extrasfs=location'.

So my fatdog doesn't waste time searching for files and boots faster as it loads those files from hdd.

I searched for similar boot options for a puppy, didn't find them yet.
In https://raw.githubusercontent.com/puppy ... README.txt

see Boot parameters:
psave=
pupsfs=
zdrv=
fdrv=
adrv=
ydrv=
While I tried what you showed for tahr64.
Here's it's entry

Code: Select all

label tahr64-savelocation
linux /tahr64/vmlinuz
initrd /tahr64/initrd.gz
append psave=sda7:/tahr64save/
menu label Tahr64-savelocation
text help
Start Tahr64 puppylinux
endtext
Doesn't work.
I have to add pmedia=satacd for it to find my savefolder.

jlst

#20 Post by jlst »

drunkjedi wrote:...
How old is your tahrpup? I hope it's the one released not so long ago.

--

Ok, I created "aa" directory in sda3 (booting from sda1)

I see a grub4dos menu and press e to edit the cmd. I add
psave=sda3:/aa
It recognizes the savefolder and continues booting as usual.

Now, what happens if I add an extra slash:

psave=sda3:/aa/

It doesn't work. So avoid adding an extra slash.

---

If I have mypsave.4fs in sda3/zz/xx, I'd add this

psave=sda3:/zz/xx/mypsave.4fs

Post Reply