Odd thumbdrive problems

[vtpup]

I bought a 5 pack of Eastfun brand 8gb thumbdrives thinking to use them as small test installs of pups, etc.

But I couldn't get any one of the 5 to work when using Fossapup64 and doing the Install>Bootflash>Create Grub4dos USB (mbr-bios) in any of the formats: f2s, fat32, ext3, ext4.

The boot would always do the same thing with all of the thumb drives. I'd get the boot menu, pick the top entry, and get the normal messages up until the point where it says Waiting for usb. Five dots later, it would fail to find the main Fossapup64 sfs and then a few red lines of panic and shut down.

I have another older 16gb PNY thumbdrive, so I did the same with it and, no problems, Fossapup64 started right up. All of these thumb drives are USB 2.0.

Thinking the PNY drive must be faster than the Eastfuns I did a few read and write tests of large and small files, also hdparm in a terminal, and established that the Eastfuns were actually pretty good for USB 2.0 drives, and faster than the PNY on writes. Eastfuns were about 23-24 mB/sec for both reads and writes, PNY was about 30 on reads and a only 7 on writes. (Write speed was tested with a 2.2 gig file, and checking time to completion.)

I can't help but think that something else than speed must be the problem.

So I thought I'd try actually running a program on both types for comparison. I happened to have Mikes Anydesk portable handy, so copied it to one of the Eastfuns. I got 6 errors while copying. Hmm. So I tried the same thing with the PNY thumb drive and got exactly the same six errors. Hmm. Why is that?

So I copied the Anydesk file to /root/ on the HD and got no errors. Hmm.

The errors all said I didn't have permission to copy the files, and those 6 files also were all file links, not actual files. And they all belonged to Spot. But ALL of the Anydesk files belong to Spot, and most of them copied over fine. So why don't file links copy over, for "permissions" reasons?

So I have two problems -- why can't I get a bootable usb thumbdrive out of this, and why the permissions errors -- or is that a single question, because they are somehow related?

[wizard]

You cant' copy Linux links to fat32, so you get errors. Try formatting one of the drives to ext3 and do an install.

wizard

[bigpup]

The boot would always do the same thing with all of the thumb drives. I'd get the boot menu, pick the top entry, and get the normal messages up until the point where it says Waiting for usb. Five dots later, it would fail to find the main Fossapup64 sfs and then a few red lines of panic and shut down.

This is a bug in the Fossapup64 boot process when booting from a USB install.

You must boot with no other USB drives plugged into the computer.

Only the one with Fossapup64 on it plugged in.

[vtpup]

Thank you Wizard and Bigpup!

(all here w/laptop in sig)
Well, actually, I didn't have another usb drive plugged in at the time, but I did have a USB bluetooth mouse. So I decided to try again with an absolutely pristine test version of everything, and do it in BionicPup64.
Steps taken:
1.) I removed the USB bluetooth dongle.
2.) I booted into clean updated copy of Bionicpup64
3.) I opened GParted and wrote a new partition table to the thumb drive (msdos type)
4.) I formatted the entire drive ext3
5.) I in Bionic64 desktop I selected Install>BootFlash USB Installer>This>sdb General Udisk, and hit Okay
6.) Formatting and file copying were accomplished. Drive was formatted to Fat32, and all Puppy files were present
7.) I checked the filesize of the new puppy_bionicpup64_8.0.sfs against the original and they were identical.

I closed down the computer and then started it with the thumbdrive inserted and got the same behavior as before.---

Here's a pic of the console error screen of a typical attempt. I don't understand why it can't find the main Puppy file.

BootErrorBionic.jpg (104.19 KiB) Viewed 675 times

[wizard]

You should probably use a program to validate the flash drive capacity. The Chinese are famous for counterfeiting the size.

wizard

[vtpup]

I've found and installed a very useful small program for checking thumbdrives. It's called f3 and is available on the Bionic64 repos.

Usage on pup:
With a blank thumbdrive, format to the type you want to test.

mount the drive, then in terminal (for my thumbdrive mounted on sdb1):

Code: Select all

f3write /mnt/sdb1

This will write large files to the drive until the drive is filled. It will also show write speeds of each.

Then to check, enter:

Code: Select all

f3read /mnt/sdb1

This will read and check all files written, and also report errors and speeds.

Interesting facts emerging about relative speeds of ext, fat, and f2fs as I'm playing with this.........

[bigpup]

The next possible fix for this Fossapup64 USB install boot issue.

Look on the USB for the boot loader menu config file.

grub.cfg

open it in a text editor.
anyplace in the entries that has pmedia=cd
Change to pmedia=usbflash
save edits.

Now try to boot with the USB.

May still need to have the Fossapup64 USB as only USB drive plugged in.

The USB Bluetooth mouse, plugged in or not, is not the issue.

[vtpup]

Thanks Bigpup. Sorry no pmedia=cdrom:

Code: Select all

menuentry "Puppy bionicpup64 8.0" {
    insmod fat
    search --no-floppy --fs-uuid --set  5FD9-1F9D
    echo "Loading vmlinuz"
    linux /bionicpup64/vmlinuz net.ifnames=0 pmedia=usbflash pdrv=5FD9-1F9D psubdir=/bionicpup64 pfix=fsck,fsckp TZ=EST5EDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /bionicpup64/initrd.gz

Also I've tried making bootflash usb with these drives in Bionic64 and Racy32, with the same results. Also tried many formats FAT32 Ext 2, 3,4, f2fs, with basically the same results. I've also tried using the Universal installer with the same results.

Wizard, these drives actually seem rather good for USB 2.0. Here are the test results using the f3 test program. They are faster than two other branded low cost thumb drives I own, yet those two work well as boot drives.

(BTW it turns out, after multiple checks with f3 that flash drives in general work faster with FAT32 than ext 3 --- for writes especially. There's a 10x speed difference. FAT32 with these drives writes at 10mB/sec, but on ext3 it's reduced to 1 mB/sec.

Here's a test of an Eastfun drive (typical)), this one is formatted FAT32:

fat32speed.png (108.39 KiB) Viewed 626 times

*****I made a copy of the debugging logs folder suggested by the screenshot posted earlier. I've tarred it and am attaching below.

zz_initrd_tmp.tar

(110 KiB) Downloaded 14 times

[wizard]

@vtpup

Nice find on the f3 program and thanks for posting your results. I've had a few problem flash drive that this MS Win utility was able to correct, maybe will work on yours. Also, have you tried installing the ISO with Unetbootin?
https://www.bleepingcomputer.com/downlo ... rmat-tool/

wizard

[vtpup]

Hi wizard, yes I really like that f3 program a lot -- could be really handy utility for Puppy in general so newcomers (and well old hands as well) could test USB thumbdrives before loading boot-Puppies.

Unfortunately it doesn't tell me why my present thumbdrive doesn't like being a boot drive!

re Unetbootin, nope I hadn't tried that but I did try:

Code: Select all

dd bs=4M if=Downloads/Fossapup/fossapup64-9.5.iso of=/dev/sdb conv=fdatasync

which should have done similar. Didn't boot. I also tried it with the Xubuntu 20 Live ISO in case it had something to do with Puppy. But same result.

[vtpup]

I saw an error message in log indicating "device not accepting address 3, error -110"

110 is an operation timed out code.

"Not accepting address" references online suggest that the device (and other USB devices) may be momentarily drawing too much current through USB. Suggested workarounds are turning off computer for a few minutes to cool down (didn't work) or adding a powered USB hub (not tried). BTW, this might explain the "no two USB drives at a time/Fossapup issue". See:

https://paulphilippov.com/articles/how- ... ress-error

Other suggestions about similar USB "device not accepting address" errors suggest that an internal drive descriptor might be problematic. From an older IBM document re. Redhat and SUSE:

The reason that the issue occurs in RHEL5 (any Update) and SLES10 (any Service Pack) is that their USB Hub drivers (over 2.6.10 kernel) have made some modifications to introduce a new USB device initialization scheme, which closely resembles the way Microsoft Windows works. In this revision, the drivers will start by issuing a 64-byte GET_DESCRIPTOR request. This is what Microsoft Windows does, so it may help with some non-standards-compliant devices.

Some previously working devices (low-speed devices, like USB mouse) may start giving rise to "device not accepting address" errors because the data structure does not fit the new USB device initialization scheme. Normally, the low-speed devices cannot work in this case. However, RHEL5 (any Update) and SLES10 (any Service Pack) have implemented the recovery mechanism to automatically switch the USB device initialization scheme to the old USB initialization scheme in consistence with need for USB low-speed devices. Although the user will still see the error message in the Linux event logs, it does not affect the functionality of USB.

I'm guessing that the descriptor may be present in these thumb drives but may be flawed somehow. I did also notice in the logs a peculiar symbol in the "serial number" field:

Code: Select all

Aug 30 14:59:00 (none) kern.info kernel: usb 2-1.2: Product: UDisk           
Aug 30 14:59:00 (none) kern.info kernel: usb 2-1.2: Manufacturer: General 
Aug 30 14:59:00 (none) kern.info kernel: usb 2-1.2: SerialNumber: Љ

[Clarity]

HI @vtpup

Should you/would you test this bootable image file on one of those USB sticks, please.

After write, boot it and ONLY hit the enter keys on Menu. Wait a few moments for a 2nd menu list of ISO files at the screen's bottom. Choose ANY one of them and report your finding. The results will yield an answer i am thinking of. It was exposed by @mistfire to me months ago.

Report back here with a result.

[vtpup]

Hi Clarity, thanks. I actually posted a comment at the end of your thread there a few days ago. Way too big for downloading here in this household.

[Clarity]

@vtpup See the reply to your post on that thread.

[bigpup]

@vtpup

I have been trying to do an install of Bionicpup64 8.0 to a USB drive and boot it.

I tried several different installer programs, that I know should work.

I am getting the same issue you are

I am trying to figure out what is happening.

The really strange thing.
I have Bionicpup64 8.0 installed on a USB hard drive and it boots with no problem.

The boot menu entry has pmedia=atahd

Wild thing to try.

Change the boot loader menu entry to using pmedia=atahd

[vtpup]

Hi Bigpup, thanks. I just tried changing to pmedia=atahd, and no difference in boot problem. I did have high hopes for that one.

Clarity, thanks!

1.)With Gparted, I clean formatted one of the new Eastfun USB thumbdrives to ext2
2.)I downloaded supergrub2-2.06s1-beta2-multiarch-USB.img
3.)I issued the following command from a terminal in the download directory:

Code: Select all

dd bs=4M if=./supergrub2-2.06s1-beta2-multiarch-USB.img of=/dev/sdb conv=fdatasync

4.) It created two new FAT32 partitions on that drive. The second partition contained a folder called BOOTISOS.
5.)I ran Gparted and expanded the second FAT32 partition to 2gB.
6.)I copied 2 ISO test files to the BOOTISOS folder: fossapup64-9.5.iso and ubuntu-18.04.6-live-server-amd64.iso
7.) I shut down the computer after all files had copied.
8.) I restarted the computer.
9.) From the Supergrub2 menu I chose Boot Manually>Bootable ISOs>fossapup64-9.5
10.) Fossapup's normal boot menu showed. I chose the top entry
11.) The usual initial booting messages showed until just after it said it was waiting for USB. Then instead of normal booting it just dropped to a blinking prompt.
12.) I typed xwin. It replied no such command.
13.) I typed poweroff and the computer shut down.
14.) I repeated steps 8-9 above and chose ubuntu-18.04.6-live-server-amd64
15.) After some initial error messages about SR0, which scrolled by too quickly to remember, it eventually booted normally to the Ubuntu installation screens.

I conclude the problem with booting these USB sticks has been anticipated and corrected by Ububtu. Fossapup (and Bionicpup tried earlier via the same supergrub2 method) do not have the ability to recognize what these sticks need for booting.

Supergrub does seem to work with these memory sticks, the problem comes at the stage in Puppies where they are looking for the main Puppy sfs file and can't find it. They also seem to throw error messages about Sr0. Maybe there is some confusion introduced at this stage about which drive contains that file.

I also believe (a guess really) that most other past attempt booting methods work, not just supergrub2, the failure comes from the puppy boot process itself, at the same point, right after the timed delay and just when the boot is looking for the main Pup sfs file and can't find it.

[wizard]

@vtpup
Ordered some of the Eastfun drives to give a go, will let you know how mine turn out.

wizard

[mouldy]

ok, f3 looks like real find. For anything that can deal with debs or has apt, its available from Debian repositories.

Or if you want to compile it yourself: https://fight-flash-fraud.readthedocs.i ... stallation

[vtpup]

Fatdog boots in Supegrub2, unlike Fossapup and Bionicpup.

Beginning to suspect initrd.gz in these two.

[vtpup]

@vtpup
Ordered some of the Eastfun drives to give a go, will let you know how mine turn out.

wizard

Heh, well Wizard they certainly are providing fun here in the east (northeast)!
If we can get them to boot, they are not bad at 5 pack for under $12 from amazon. (I got the type with the swivel guard). Double the price seems to be the rule on Ebay -- maybe they are re-seliing them.

They seem to have decent performance otherwise, and work well for data. They are listed as 17 mB/sec read speed, but mine all measured 24 read and ~11 write (on FAT32). Pleasantly surprised.

And so far if you want Ubuntu 18 server edition or Fatdog 810, (oddball stuff I happen to have ISOs for) they will boot those, too.

Just puzzling over the Bionicpup/Fossapup boot crashes.....

[mouldy]

Made me look. So Eastfun is better than SamData? Ok, the SamData name just struck me as really funny. Glad somebody selling low end has a sense of humor. Eastfun just sounds like some weird translation that probably sounds lot less stupid in Chinese.

Yea whatever works. Especially if you play a lot with linux from thumbdrives. Curious how Etcher or Rufus or such see these?

[vtpup]

I avoid my old copy of Win7 unless ABSOLUTELY necessary to run some ridiculously obscure software eg. cheap laser cutter program, etc

I worry it will self destruct.

[Clarity]

@vtpup the success you are seeing with SG2D allows you (and the rest of us who use this) a method to compare behaviors with the forum PUPs & DOGs. There are 2 non-PUPs on the forum that will NOT work booting from their ISO files as they are specifically coded to NOT WORK booting that way. All of the WoofCE PUPs (except the 1 experimental) will boot without issues, normally, without issues.

Occasionally I have hit the EXACT condition you have surfaced.

This I believe to be PC related (firmware and chipset).

The last distro I hit this with is @mistfire's QuickPUP64 in a prior release. His distro is wonderful in that when there is a problem, it bounces you to a GRUB2 command line-gui where you can capture the logs which leads to problem identification. @mistfire is wonderful in that he responses quickly as does many other PUP distro developers when we hit these kinds of problems and have captured the logs to make clear.

I went back looking for my notes on the specifics of what I noted on this specific problem.

That said, I offer 3 test cases which each should help identify a USB problem and 1 case of identifying a distro problem (aside from a USB problem between PC and USB stick's controller).

In the meantime, there are 3 distro where I KNOW the developer are quickly helpful; namely @fredx181 DebianDog, @rockedge KLV, and QuickPUP. EAch distro's thread are very good should you present the DEBUG info when the distro runs into a boot problem, as these usually drops to a cli-gui to capture the logs. I would be careful as each's solution could be different from each other as the accommodations might differ accordingly in INIT.

TEST Cases that should be helpful

• Easiest non USB.

  1. Create a folder on your PC's internal drive; namely /BOOTISOS.

  2. copy the offending ISO file to that folder

  3. Boot SG2D USB.

  4. At SG2D;s meny, do NOTHING except hit the enter key and wait

  5. Scroll to the bottom of the next screen looking for your ISO file in the "BOOTISOS" folder (this will be the one on your system's drive...not the one on the USB)

  6. Select it to observe is it drops at the same place or continues to desktop

  ,

• USB testcase #1

  • Switch the USB port from back of the PC to the front and boot the USB

  .

• USB testcase #2

  • Depending which SG2D you are using, it should boot no matter if UEFI Secure boot is on or NOT, so turn on secureboot and boot the USB

  .

• USB testcase #3 (this case ask you to add the following when the problem PUP's Menu is presented after you selected it and before the PUP starts to boot )

  1. edit the PUP Menu's top line stanza (usually hit the "e" key)

  2. change by adding the following to the end of the linux line
     ... pmedia=usbflash pdrv=sdb2

  3. allow this to boot

Please report if any of this is helpful

BTW: AS I remember, I have also triied the SG2D in a different PC and found that the offending PUP booting without issues on a different PC. Cant remember which PUP that happened with in the past. Thus, it merely demonstrates the differing PC behavior with the same USB stick.

P.S. Chinese sticks work just as well as all 30-40 other sticks I have collected over the decades.

[vtpup]

Clarity, thanks.
1.) It makes no difference to behavior no matter what USB port is used on this laptop.
2.) It makes no difference to behavior if I change to an adapted Acer C720 Chromebook running Bionic64 normally.
3.) If BOOTISOS is on the USB drive, and Bionic64, Fossa64, and FatDog810 isos are located in that folder, only Fossa and Fatdog are found:
a.) Bionic64 is not found.
b.) Fatdog810, if chosen boots properly.
c.) Fossa64 does not boot properly and fails immediately after the "waiting for USB" stage.

4.) If BOOTISOS is on the hard drive, results are the same as 3.

5.) It makes no difference to behavior if the Fossa64 grub first stanza line is edited to pmedia=usbflash pdrv=sdb2, it still fails to boot properly at the same point.

[vtpup]

Using a different brand of memory stick, and SG2, Bionic64 is still not found by supergrub:
Fossa64 and Fatdog810 are both found.
Both also boot properly.

[wizard]

@vtpup
Well that was an interesting experience. I got some of the Eastfun USB flash drives and first ran r/w test to validate their capacity, they passed. Then tried to install different Pup's using multiple methods, multiple formats, hard reformatting, etc. Nothing would create a bootable USB and some installs could not complete. Additionally, operations involving file copying would often fail or lockup the computer. At one point I could not delete a file from the USB. This echos your reports and I'm guessing that these drives have faulty flash drive controllers. Anyway, back in the package for a return to the seller.

Thanks
wizard

[Clarity]

@vtpup I apologize for slow response here, as I JUST saw your updates to this thread.

If SG2D does NOT see an ISO, the ISO file does not possess the ingredients for ISO file discovery that SG2D looks for in its ability to present the ISO file for booting.

SG2D does the following for you

• SG2D discovers all modern WoofCE PUPs (except one where that author has specifically coded around the ability for discovery to discourage new user testing via this simple boot method)

• and all DOGs since 2020

• and KLV distros found on the forum.

• Also, as you may have noticed, all UBUNTUs since 2015 and their derivatives are discovered and presented as well.

• And some other ISO files that exist on Distrowatch

• Further, SG2D will also list, for boot, ANY bootable OSes that are installed on your system's drives as well as the ISO files it finds.

• Additionally, SG2D will find ISO files if you have them in a boot-isos folder on your system drive, too.

Its product and author is on GIT but this forum has at least 1 report of the author's responsiveness

As I remember, BIONIC was introduced to the forum prior to the WoofCE of 2019 when SG2D GRUB2 changes were added to expand PUPPY linux ability for easy ISO file discovery and bootingby the WoofCE developers. The change that the developers introduced was NOT to Puppy Linux code: The change were merely to the PUP's boot Menus...not to anything in Linux or PUP system code.

This is why I post that SG2D is PUP friendly as it merely allows booted PC to appear as a mere frugal with no effort or issues that usually occurs with new and sometimes experienced users.

In my use of SG2D in Puppyland, it has saved me so much time in getting a modern PUP/DOG/KLV up, active, and saving any sessions with NO drawbacks, thus far. SG2D is merely a friendly assistant to ease the task and save time in getting to a desktop from an ISO file download eliminating Frugal setup and Frugal issues that surround setup needs and resulting behavior; while yielding PUPs/DOGs/KLV desktops in all their glory.

You may have already discovered these points. Hope this info is helpful.

P.S. I recently started using the author's latest SG2D that is based with GRUB v2.06...Works without issues.

[vtpup]

Thanks wizard, clarity

The drives were so cheap, and I find they work for file transfers so I decided it wasn't worth the trouble to return them. Also it might be an interesting exercise to try to rewrite the internal firmware.... but that's for another day!