Fossapup doesn't boot from USB drive if there is another USB drive in system

AkhIL · Post by **AkhIL** » Wed Sep 30, 2020 10:40 am

Greetings.

I have a problem booting from a USB flash drive on a modern system with B450 chipset in both UEFI and Legacy mode. The init script cannot find partition with the sfs files.
This same disk works as expected on multiple other older non-UEFI machines.
In addition, after an error, I can manually start the init script and it detects the partition and all necessary files without any problems.

I believe that the detection of the partition falls too early and everything will work if after an error the init script will try to find the partition again after a short interval.

Please tell me where exactly in the init script is the search for the data section.

Here is log files from failed boot: https://ipfs.io/ipfs/QmYGUpdeTxwyr2kgrZ ... fj3q7nYwx4

AkhIL · Post by **AkhIL** » Wed Sep 30, 2020 2:45 pm

I understood why Puppy does not boot. I have another USB drive connected to my system and it is detected earlier than the one Puppy installed. However wait4usb waits only the first USB drive to show up.

The solution will be waiting not just for some USB drive, but for a partition with the necessary UUID or label.

Post by **bigpup** » Wed Sep 30, 2020 11:40 pm

So, will Fossapup64 9.5 boot OK if it is the only USB drive plugged into the computer?

booting from a USB flash drive on a modern system with B450 chipset in both UEFI and Legacy mode

What is the make and model of the computer?
Do you have any info on what version the UEFI bios is and what it supports?
Running Fossapup64 9.5
menu->System->Pup-Sysinfo->Mainboard->Bios
This will give a good info report on the UEFI bios

Post what it gives for info.

AkhIL · Post by **AkhIL** » Thu Oct 01, 2020 12:16 am

Yes. With only one USB drive all works fine.

I am slowly getting into the Woof_CE codebase. So I will make a pull request as soon as I fix this issue.

AkhIL · Post by **AkhIL** » Thu Oct 01, 2020 12:37 am

My menu->System->Pup-Sysinfo->Mainboard->Bios:

Code: Select all

▶—— BIOS ——◀

Vendor: American Megatrends Inc.
Version: P3.30
Release Date: 07/13/2020
Runtime Size: 64 kB
ROM Size: 16 MB

--

# biosdecode 3.2
SMBIOS 3.2 present.
	Structure Table Length: 1591 bytes
	Structure Table Address: 0x000E6CC0
	Number Of Structures: 29
	Maximum Structure Size: 166 bytes
SMBIOS 3.2.1 present.
	Structure Table Maximum Length: 1591 bytes
	Structure Table 64-bit Address: 0x00000000000E6CC0
PNP BIOS 1.0 present.
	Event Notification: Not Supported
	Real Mode 16-bit Code Address: F000:BE06
	Real Mode 16-bit Data Address: F000:0000
	16-bit Protected Mode Code Address: 0x000FBE2E
	16-bit Protected Mode Data Address: 0x000F0000
PCI Interrupt Routing 1.0 present.
	Router Device: 00:14.3
	Exclusive IRQs: None
	Compatible Router: 1022:790b
	Device: 01:00, on-board
	Device: 00:00, on-board
	Device: 00:00, on-board
	Device: 00:00, on-board
	Device: 00:00, on-board
	Device: 06:00, slot 53
	Device: 07:00, on-board
	Device: 08:00, on-board
ACPI 2.0 present.
	OEM Identifier: ALASKA
	RSD Table 32-bit Address: 0x5C8AC028
	XSD Table 64-bit Address: 0x000000005C8AC0A0
BIOS INFORMATION (dmidecode):
	Vendor: American Megatrends Inc.
	Version: P3.30
	Release Date: 07/13/2020
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 16 MB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 5.14

foxpup · Post by **foxpup** » Thu Oct 01, 2020 8:54 am

In addition, after an error, I can manually start the init script and it detects the partition and all necessary files without any problems.

Are you using grub2?
Are you sure the failure is in init, and not before: in grub2?
Asking because it reminds of something I had when I was playing with grub2 a long time ago.
I discovered some problem with prefix (or root) not properly set when 2 usb where inserted.
I had to add some line(s) to the grub.cfg to settle it properly.

AkhIL · Post by **AkhIL** » Thu Oct 01, 2020 11:16 am

Yes I'm using grub2.

I can clearly see in logs that during the execution of the init script USB drive with the system was not detected. But I can easily mount that disk as /dev/sdc immediately after init fault.

probedisk.log

Code: Select all

/dev/nvme0n1|drive| GIGABYTE GP-GSM2NE3128GNTD|119.2G
/dev/sda|drive|ATA SAMSUNG HD153WI|1.36T
/dev/sdb|usbdrv|Kingston DT Mini 10|7.4G
/dev/sr0|optical|Optiarc DVD RW AD-7191S|1023M

Boot partition with grub and grub's config is /dev/sdc1, Kernel, initrd and sfs files stored in /dev/sdc2. And grub definitely loads the initrd.
But then init script calls wait_for_usb function, which calls /sbin/wait4usb.

In /sbin/wait4usb we can see that it is waiting for the first any USB disk and solemnly reports that the USB disks are ready.

Code: Select all

CNTUSB=0
USBDRVS="$(find /sys/block -maxdepth 1 -name 'sd*' -o -name 'sr*' | xargs -n 1 readlink 2>/dev/null | grep '/usb[0-9]')"
while [ "$USBDRVS" = "" ]; do
	[ $CNTUSB -ge $TIMEOUT ] && break
	sleep 1
	[ "${1}" ] || echo -en "\\033[1;33m.\\033[0;39m" >/dev/console #yellow dot
	USBDRVS="$(find /sys/block -maxdepth 1 -name 'sd*' -o -name 'sr*' | xargs -n 1 readlink 2>/dev/null | grep '/usb[0-9]')"
	CNTUSB=$(($CNTUSB + 1))
	echo -n " - $CNTUSB" #debug
done
echo

I have two solutions in mind. The first one is to wait in the /sbin/wait4usb until list of USB drives not changes for a 1 second interval. And the second one, much better in my opinion, is to replace the wait4usb by something like wait4part <dev_name|uuid|label> and wait for specifically required disks.

foxpup · Post by **foxpup** » Thu Oct 01, 2020 1:17 pm

So you end in the initial system. (not in the grub2 shell). Okay.

Then init should look for the folder that contains the Puppy system files, it should look on all available drives.
At least for possible pupsaves, it should look on all drives. They can be anyware.
Or not? I am puzzled here,
if what you say is true. I am not good at reading bash.
Have you opened an issue over at woof-CE to check with the devs?

AkhIL · Post by **AkhIL** » Thu Oct 01, 2020 1:46 pm

Github issue: https://github.com/puppylinux-woof-CE/w ... ssues/1877

mikeslr · Post by **mikeslr** » Thu Oct 01, 2020 10:07 pm

just out of curiosity, have you tried adding psubdir= to the kernel line?

I appreciate that it is not obvious that the psubdir= argument has anything to do with locating the drive/partition. But see my experience here: viewtopic.php?p=4593#p4593. This was a case where I had a Puppy (albeit puli) on a USB-Key, the only key plugged in. But the bootloader didn't look for files on the Key at all until I added that argument.

"puli on what my laptop saw as sdb2...However, I noticed that the only partitions grub4dos was looking at were sda --which is the computer's hard-drive. On a hunch, I added psubdir=puli to the menu.listings so that they now read...Success.

"

Post by **bigpup** » Fri Oct 02, 2020 12:31 am

I am not sure it is something wrong with Puppies boot process.

It may be the computer and the version of UEFI bios it is using and how the computer manufacturer set it up.

Why do I say this.

I have a very new desktop computer that has no problem booting with multiple USB drives plugged in.

I have a laptop that is about as new and it will only boot from USB drive if the USB booting drive is the only USB drive plugged in.

foxpup · Post by **foxpup** » Fri Oct 02, 2020 6:42 am

mikeslr wrote: Thu Oct 01, 2020 10:07 pm just out of curiosity, have you tried adding psubdir= to the kernel line?

Good advice!

or Pdev1? pdev?
It is something like pdev=sdc.
(Incvonvenience here is, if you boot up with an extra device, or one pulled out, sdc may become sdx.)

http://wikka.puppylinux.com/BootParametersPuppy
Maybe even psubok=TRUE may apply?

gyrog · Post by **gyrog** » Fri Oct 02, 2020 11:59 am

The problem with Puppy not booting when there are multiple usb drives is in the' wait4usb' routine used by the 'init' script.
It returns as soon as a single usb drive becomes "seen", unfortunately this might not be the required one.

Unfortunately the real solution is not simple, the 'init' script needs to be changed so that it waits (if necessary) for each individual partition, but that only works if the partition is already specified.
It still won't do anything if folk depend on the 'init' script "finding" the Puppy installation.

foxpup · Post by **foxpup** » Fri Oct 02, 2020 3:18 pm

That confirms the detective work of AkhIL is correct. Good to know. Thank you Gyro.

gyrog wrote:Unfortunately the real solution is not simple, the 'init' script needs to be changed so that it waits (if necessary) for each individual partition, but that only works if the partition is already specified.

I think I get what you mean: The init does not know how many devices it should look for.

But there is an error when it does not have system files to load.
Could it not continue after the error, going back to continue the search?
Maybe it could ask whether to continue searching or not.
Also, could pdev not be used?

gyrog · Post by **gyrog** » Fri Oct 02, 2020 5:50 pm

foxpup wrote: Fri Oct 02, 2020 3:18 pm Could it not continue after the error, going back to continue the search?

Yes, it could, but there would need to be some delay, probably "Sleep" for some arbitary number of seconds,
'wait4usb' would simply return immediately.

foxpup wrote: Fri Oct 02, 2020 3:18 pm Also, could pdev not be used?

Specifying the partition with a "pdev1=" or "pdrv=" would avoid 'init' having to search for the Puppy files.
Then 'init' could wait for that partition to appear in '/proc/partitions' or the output from 'blkid'.
(Specifying the install partition and "psubdir=", is good practice anyway, then 'init' doesn't have to search, and possibly get it wrong.)

ozsouth · Post by **ozsouth** » Sat Oct 03, 2020 12:20 am

I use pupsfs= and label my ext partitions with gparted so drive letter doesn't matter either. Syslinux example:

label 9
kernel 9/vmlinuz
initrd micd/microcode-update-20200508-64.cpio,9/initrd.gz
append pupsfs=201119a:9/puppy_ScPup64_19.09.sfs psubdir=9 pfix=fsck rootwait ro

gyrog · Post by **gyrog** » Sat Oct 03, 2020 11:07 am

This is just meant to provide extra information.

1. "pupsfs=" is an alias for "pdrv=", it doesn't matter which one you use.
"pupsfs=" is the older one, "pdrv=" is an attempt to make it consistent with "adrv=", "fdrv=" etc...

2. Assuming 'puppy_ScPup64_19.09.sfs' is the default name for the puppy...sfs file,
there is no need to specify it.

So in ozsouth 's example above, I would use:
append pdrv=201119a psubdir=/9 pfix=fsck rootwait ro

gyrog · Post by **gyrog** » Sat Oct 03, 2020 12:43 pm

Getting back to the original issue.
I have attached a parched version of 'init' for fossapup64.
( I tried to attach a replacement 'initrd.gz', but it is too big.)

This 'init' waits for the needed partition to be "seen" by the kernel, (as in present in '/proc/partitions' or reported by 'blkid'),
for every partition, provided it is specified.
If 'init' has to resort to "searching" to locate the Puppy, this patch will not help.

To use:
Unpack the release 'initrd.gz'.
Replace 'init' with the downloaded one.
pack the updaed 'initrd.gz'

Please consider this as alpha software, it's not well tested.

init.gz: gunzip to produce 'init' file; (14.26 KiB) Downloaded 57 times

Clarity · Post by **Clarity** » Sun Oct 04, 2020 4:13 pm

Question:

Is the position of the USB sticks a factor?

As I understand, there is USB on the front and on the back of most dektop (non-AIO) PCs. And, on 1 of my PCs, there is 2 'different" USB connectors on the back as well as the front.

This problem the OP reports is related to "Where" the USB(s) is plugged. As hardware hierarchy can/may be THE culprit.

On another of my PCs, it has 1 section for USB3 ports and another "section" for its USB2 ports.

There is NO software substitution for hardware design.

So seeking a software solution to the varied hardware designs, all of us have, requires a better description of this problem.

I do realize that software can be designed to accomodate how hardware can be visualized and set to manipulate thru various efforts and timings. But, that will NOT make hardware be something different than how it is set. BIOS/UEFI controls can preceed what happens in post presentations if a user is aware and the controls are present.

All of this is compounded by the FACT that USB sticks are horrible! The performance variences are so trememdous that its any wonder we dont have more problems in this misunderstood performing technology that the manufacturers throw at all of us. This is even more complex when you account for USB HDDs vs USB with SSD vs USB with X.2 vs USB with SDcards of various std/mini/micro vs USB wtth DVD vs USB with ... you get the picture.

This post is just an FYI.

EDIT: @gyrog has given Puppy a pathway to work around the challenges posed in the I/O subsystem during the boot process. Thanks! ... to the Puppy development community to seek (and address) this! Users must test and report to help.

gyrog · Post by **gyrog** » Mon Oct 05, 2020 9:28 am

I have uploaded a new version of the patched 'init' that works when the install partition is specified, and when the 'init' script has to resort to searchig for the Puppy install, (thanks jamesbond).

You can download 'fossa64-initrd.gz' from https://www.mediafire.com/folder/hkwe9y ... /init-wait.
Then replace the current Fossapup64 'initrd.gz' with 'fossa64-initrd.gz', and reboot.

This initrd.gz contains the patched version of the current 'init' script from woof-ce,
and the 'wait4usb' script has been removed, since this 'init' never calls 'wait4usb'.

gyrog

gyrog · Post by **gyrog** » Wed Oct 07, 2020 1:49 pm

Apparently there are other scripts in 'initrd.gz' that use 'wait4usb', (thanks 01micko).
So if you go to https://www.mediafire.com/folder/hkwe9y ... /init-wait you will find a 'fossa64-withwait4usb-initrd.gz' file. This has the same 'init' but with the '/sbin/wait4usb' file restored.

gyrog · Post by **gyrog** » Sat Oct 10, 2020 1:55 pm

Unfortunately I have an "improved" 'init' script, that includes a 'wait_for_blkid' function that can be used by things other than just the 'decode_id' function.
As an example, this 'init' includes code that calls 'wait_for_blkid' to get a list of "iso96660" partitions when "PMEDIA=cd".
And if there is only 1, makes that the "install partition" so there is no "seraching" for the required Puppy files.

So if you go to https://www.mediafire.com/folder/hkwe9y ... /init-wait you will find a 'fossa64+cd-initrd.gz' file.

Post by **mikewalsh** » Sat Oct 10, 2020 6:44 pm

@AkhIL :-

Just so I don't get hold of the wrong end of the stick here, is it absolutely "essential" that you MUST leave other USB sticks plugged in? Seems to me it would make life a lot easier to simply unplug them before booting...

Or is that asking too much?

Mike.

gyrog · Post by **gyrog** » Mon Oct 12, 2020 10:31 am

While a simple workaround is available, in some situations, there exists an underlying deficiency in Puppy, it should not matter to Puppy how many usb devices are connected.

For a simpler and more general method of testing the "test" 'int' script, see viewtopic.php?f=66&t=1059.

gyrog

Puppy Linux Discussion Forum