Puppy Linux Discussion Forum

In the past few months I've had several different flash drives change over to read only, without my having done anything unusual.A couple of days ago, the 64GB flash, setup from the Ventoy site, and used exclusively for me to place various
iso's upon it, and then check them out, went read only. I've tried several linux commands(evidently wrong!), and even went into win10 registry to fix, all to no avail. As I have loads of iso's on each of these various flash drives, I haven't tried using gparted to format any of them and start anew. I've also done a google search and read lots of others with same problem. Would sure appreciate some assistance with this, please. Thanks.

@tosim :-

What make of flash drives are these? Some manufacturers have a bit of a reputation for this sort of thing, y'see....

Mike.

Most flash drives have a builtin protection.
If they are going bad.
It will go into read only mode, so stuff can be gotten off of it.

But they may have corrupted file systems on them.

If format is a Windows format (fat32 or ntfs)
Try using the Windows chckdsk and defrag programs on them.

If Linux format.
Try running e2fsck on them.

In Puppy Linux.
Plug the flash drive in, BUT do not mount it.
To do the whole partition:
(the partition must be unmounted)
Example:
partition sda1
in a terminal:
e2fsck -p /dev/sda1

My observations:
- Linux has messed up many of my USB sticks. For some reason it is hard on them. Until lately I would say Linux destroys USB sticks. Heck, one time Linux messed up my 1 T Passport. I was able to fix it though.

- Windows almost always has been what saves the day. Even after trying all night just take it to a windows computer and format it there. FIXED.

- It is UEFI boot images that messes my sticks up. Never a problem with legacy boot. Look with gparted and you find more than one partition and for some reason that becomes a problem when trying to reformat and use again. Not only do they become write protected but very restrictive as far as partition size with the rest being unwritable

- I buy whatever I can afford. Sometimes is cheap brand and sometimes is a better quality brand. I have had them messed up the very first time I have used it.

- I accidentally found out that zeroing the stick overnight (big sticks take awhile) actually fixes the stick. Before that time I resorted to murdering the offending stick with a hammer.

- For some reason unmounting and ejecting didn't afford any insurance against this phenomenon but just pulling it out works (for me anyway) every time with no issues.

A couple of points:

When copying large files to flash with ROX filer, there is about 20 seconds between the point ROX shows the copy as complete and when writing to the drive stops.

USB sticks store the LBA translation table hidden in the first erase block. If a write to the first erase block fails you may lose access to the drive.

Put the two together and you have a recipe for trouble. You need to watch the blinking light.

You need to watch the blinking light.

One of my usb sticks is 2.0, relatively slow.
It has the light which blinks when it writes or reads.
Sometimes I copy larger files and it blinks quite long time (2 files, each 600 Mb -> blinking approx. 3 minutes).
So I wait, till the blinking stops, although the rox-filer looks like the copying is already done.

I also have usb stick 3.0, much faster but without the signal light. When copying large files, I wait some time preventively and hope the proccess is finished. No problem till now.

1. Note the device name of the flashdrive you're want to unplug. Is it sdb2, sdc1 or whatever (remember this name).
2. Open terminal.
3. Type "watch -n1 grep sdc2 /proc/diskstats" --- replace sdc2 with whatever it is that you want to unplug. You should see something like this:

Every 1.0s: grep sdc2 /proc/diskstats         james-pc: Sat Jan  1 23:50:14 2022

   8      34 sdc2 250 144 6896 321 4012 0 899104 233662 0 234193 231583 0 0 0 0

Watch that line with the "sdc2" carefully.

4. Un-mount the flash drive by clicking on the ROX desktop.
5. Watch the numbers on that terminal above. It will start changing, but eventually it will stop.
6. Un-plug only when those numbers have stopped. Then close terminal.

You will never lose any flash drive ever again.

Too complicated? Go bugger your favourite Puppy developers to integrate the above logic into their un-mount code.
Or, as @Feek and @LateAdopter say, always buy flash drives that come with light, and watch that light.

Since many of my USBs "DO NOT" have lights, here's a prescription in USB storage device use.

FWIW, I ALWAYS do the following when using USB storage/sticks:

1. unmount the USB

2. use terminal 'sync' command BEFORE dislodging a USB from the PC (this insures that ALL I/O cache operations are completed)

Discovered this several years ago when dealing with USBs. (This is a safety MUST in my use of USBs)

Hope this is helpful

Thank you all so very much. Will try using the suggestions y'all have posted.
mikewalsh-Some of the drives are:SanDisk,TeamGroup,AData,PNY

G0rdie wrote: ↑Sat Jan 01, 2022 4:23 am

- For some reason unmounting and ejecting didn't afford any insurance against this phenomenon but just pulling it out works (for me anyway) every time with no issues.

This works as long as Puppy is finished writing to the drive.

LateAdopter wrote: ↑Sat Jan 01, 2022 9:32 am

A couple of points:

When copying large files to flash with ROX filer, there is about 20 seconds between the point ROX shows the copy as complete and when writing to the drive stops.

USB sticks store the LBA translation table hidden in the first erase block. If a write to the first erase block fails you may lose access to the drive.

Put the two together and you have a recipe for trouble. You need to watch the blinking light.

I find that if I click the X in the drive symbol (lower left of my desktop) to unmount the drive, the X doesn't disappear (indicating the drive is unmounted) until Puppy has finished whatever it is doing with the drive.

Clarity wrote: ↑Sat Jan 01, 2022 4:05 pm

Since many of my USBs "DO NOT" have lights, here's a prescription in USB storage device use.

FWIW, I ALWAYS do the following when using USB storage/sticks:

1. unmount the USB

2. use terminal 'sync' command BEFORE dislodging a USB from the PC (this insures that ALL I/O cache operations are completed)

Discovered this several years ago when dealing with USBs. (This is a safety MUST in my use of USBs)

Hope this is helpful

I Think you should 1. issue the 'sync' command and then (when you get the command prompt back) 2. unmount the drive - at least that is what I do.

Overcautious people execute the command even twice ...

peace

Overcautious people execute the command even twice ...

Sync waits until all of the blocks of data in the buffer is written to the hardware.
but it does not wait until the last block is written.
Sync stops waiting when the last data block starts to be written.

The second sync will wait until that last data block has finished writing.

For example, if there are 1000 blocks of data waiting to be copied to a flash drive,
sync will wait until 999 blocks have written and then return.
A second sync will wait until that last block of data has finished writing.

Look with gparted and you find more than one partition and for some reason that becomes a problem when trying to reformat and use again.
Not only do they become write protected but very restrictive as far as partition size with the rest being unwritable

To do a clean complete setup of a drive.
Make a new partition table.
Partition and format.

bigpup-Thanks, however, I only do that as a last resort.

bigpup wrote: ↑Sat Jan 01, 2022 10:12 pm

Look with gparted and you find more than one partition and for some reason that becomes a problem when trying to reformat and use again.
Not only do they become write protected but very restrictive as far as partition size with the rest being unwritable

To do a clean complete setup of a drive.
Make a new partition table.
Partition and format.

bigpup, I see from your reply that you have not had this happen to you. When it does you cannot use gparted to do anything to the stick. It has become read only. You cannot write a partition table or a partition or do a format. No rabbits can be pulled out of a Linux hat. Until Linux I never messed up a USB stick. When I switched from Windows to Linux I can buy them be the gross. Indeed, it is tempting to buy them in bulk because I live an hour on the highway from Thunder Bay which is the closest place to buy computers and accessories.

From the Slackware Forum on LQ I found an answer that promises "I have never seen this fail" only to find that I (personally) have never seen it be successful.

Typically I have found a small partition of a couple of meg and one of a couple of gig (at best) and the rest of my new and used only once USB stick is unallocated and around in circles I go until I get the persuader and pound the stick against a solid surface. Since I was using them to try Live Linux Distros I cannot tell you what the format was. I start out with an MSDOS partition table and FAT32 format. The file system copies not only data but the partition and the format and I have no way to record what they are.

These are 16 gig and 32 gig but I have a couple of 64 gig and even a 127 gig sticks that make me real nervous when using them for anything Linux. After all, I am not made of money.

Now, these are only observations and ONLY from my memory. It has happened only when inconvenient. I just tried to get it to happen on purpose so I could report what actually happens and not from my flawed 70 year old memory but no such luck. I will try more times and then we all can see. Maybe then someone will have an answer but I won't hold my breath. DDG is chock full of queries but no answers.

I have NOT found a solution and the more I look, the more questions I have.

G0rdle-Amen to your above; well said.

There is of course dd.....the good old "disk destroyer" (so-called because that's exactly what it WILL do if you're not very careful with your commands).

I've had this happen to me a few times over the years. gParted is a waste of time initially, because it can't do anything with it. More often than not, what has happened is that the MBR has become corrupted; that first 'block' on the drive has been "zapped" some way or another, and without the MBR to 'guide' it, the controller won't have a clue what to do with anything. Hence, the stick appears 'dead', and unresponsive.

Almost always, the following command has fixed things for me:-

dd if=/dev/zero of=/dev/sdX bs=512 count=1 conv=notrunc

.....where /sdX is the drive you want to "fix". (For God's sake, make absolutely sure you get this correct, or you can easily end up borking everything).

That last stanza tells it NOT to 'truncate' the output, i.e., make sure to clear the full 512 bytes in which the MBR resides....just to make absolutely certain. After this has been done, gParted can work with it again, and create a new partition table & partitions.

YMMV, of course. What works for me may NOT necessarily work for you..... Worth a try at this point, however, because even though the MBR/file-system/partitioning is all shot to hell, a simple

lsusb

.....will usually still show the basic hardware device, so all is not entirely lost.

Up to you, of course. At this stage, what have you got to lose?

LateAdopter wrote: ↑Sat Jan 01, 2022 9:32 am

A couple of points:

When copying large files to flash with ROX filer, there is about 20 seconds between the point ROX shows the copy as complete and when writing to the drive stops.

USB sticks store the LBA translation table hidden in the first erase block. If a write to the first erase block fails you may lose access to the drive.

Put the two together and you have a recipe for trouble. You need to watch the blinking light.

LateAdopter's pretty near the mark, as usual. It's all tied up with that first data block; even these current top-end 512 GB flash drives are still controlled by the contents of that very first half-kilobyte of flash memory. It's the bit that holds the 'roadmap' for finding your way around the rest of it, y'see.

Mike.

You can test a usb flash drive like this:

#!/bin/sh
while true
do
  md5sum /dev/sdb
done

It assumes that your flash drive is /dev/sdb
Partitions on the flash drive should not be mounted.
it reads all of /dev/sdb including boot records, partition tables, file system, all files and dirs etc etc.
it prints an md5sum to the screen.

It does this over and over again.
to stop it, press the ctrl+C keys.

This does the same thing, but only tests the first 100MiB of the drive.

#!/bin/sh
while true
do
  dd status=none if=/dev/sdb bs=1M count=100 | md5sum
done

For example:

# sh foo
25be012a25933b293cd5463be8581c54  -
25be012a25933b293cd5463be8581c54  -
25be012a25933b293cd5463be8581c54  -
25be012a25933b293cd5463be8581c54  -
25be012a25933b293cd5463be8581c54  -
25be012a25933b293cd5463be8581c54  -
^C
#

which assumes the shell script is named foo
It doesn't matter what the md5sum is,
as long as it's the same number each rime.

AFAIK, flash drives can be read a limited number of times, as well as a limited number of writes.

One of the things I usually do with a new usb stick/sd card/micro SD is to run gparted for new partition table. Usually the item is Fat32 by default. One other thing is set up part of the stick/card as ext3. Linux seems to like this better than W32. Generally this set-up means I don't have to defrag. that partition. W32... you're on your own!, it just makes a mess of itself.

8Geee

If you use some program to do installs of a Linux OS ISO to a USB.
Some of the installer programs will use iso9660 for the format.
Those will install only the files in the ISO to a partition formatted iso9660, only the size needed for the files, and leave the rest of the drive unused.
iso9660 is a read only format.

Can try this:
In a console type this code and hit enter.
Important
(The code of=/dev/sdb. (sdb is the flash drive, yours could be sdc, sdd, etc.... adjust to match yours)

dd if=/dev/zero of=/dev/sdb bs=1M count=1

This will remove all partitions, format, and data from USB flash drive.

Note:
mikewalsh's, earlier posted dd command, my be better command to use.

Use Gparted to get back to normal setup.
1. Make a partition table:
GParted > Device > Create Partition Table > MS-DOS default.
2. Partition and format as you like.

Another point...

When you get a new USB stick or SD card, it comes with a partition already on it. There is an unpartitioned space of 4, 8, 16 or 32 MB at the start of the device.

I think you should assume that it is unsafe to include this space within a working partition that is written frequently.

I have created small bootloader/EFI partitions within this space without having any problems, but they are only written infrequently.

Flash devices have multiple slices, but I have not found an explanation of how the slices are addressed. I speculate that the original partition starts at the first available alignment point, taking erase blocks and slices into account. I think USB sticks do not align on a megabyte as a consequence of the hidden LBA translation table.

Desperation caused me to try all sorts of things. After all, Necessity is the Mother of Invention.

Since Slackware is my go to Linux OS I looked in the available Slackbuilds to see what I could compile into a usable program.

Gnome-Disk-Utility worked some of the time. It provides a gui to zero a drive. No safety with it (I borked my hard drive when I was too tired to be doing such things. Thank God for backups

Anyway, a really messed USB proved bulletproof to it. If you try it YMMV
https://slackbuilds.org/repository/14.2 ... k-utility/

It is also provided as a pre-compiled package but I prefer to roll my own as I find it to be more fun that way.
https://packages.slackonly.com/pub/pack ... k-utility/

For problem USB sticks I set this up and go to bed. Things might be fixed in the morning.

LOL - My son is somewhat of a Windows guru. He said to send it to him and he would see what he can do with it. Canada Post took it down to him in Hamilton along with a couple of others for good measure. That ONE proved so impossible to work with I told him to use it for a boat anchor.

In the beginning of all this I used dd to write an image (iso) to my USBs. Not knowing what the source of this problem was led me to try a Linux version of UNetbootin and sometimes these days I will use balenaEtcher but ... I think that the writing of the image to USB is not the problem. At least the method of writing to the USB doesn't change a blessed thing for me so ... I have come full circle to lean heavily on dd again.

I'll keep trying to find the solution. Oh, I did notice that I format a large disk and WOW, that finished already? Yup, that stick is messed and the saga begins again.

Reports that it is "write protected" and "read only" and that I "do not have permission" to make changes to the data on the disk. My disk, my property and it defies my efforts to have it do what I want. Nothing gets my blood boiling faster

bigpup wrote: ↑Sun Jan 02, 2022 9:53 pm

If you use some program to do installs of a Linux OS ISO to a USB.
Some of the installer programs will use iso9660 for the format.
Those will install only the files in the ISO to a partition formatted iso9660, only the size needed for the files, and leave the rest of the drive unused.
iso9660 is a read only format.

Can try this:
In a console type this code and hit enter.
Important
(The code of=/dev/sdb. (sdb is the flash drive, yours could be sdc, sdd, etc.... adjust to match yours)

Code: Select all

dd if=/dev/zero of=/dev/sdb bs=1M count=1

This will remove all partitions, format, and data from USB flash drive.

Note:
mikewalsh's, earlier posted dd command, my be better command to use.

Use Gparted to get back to normal setup.
1. Make a partition table:
GParted > Device > Create Partition Table > MS-DOS default.
2. Partition and format as you like.

You should be able to use Gparted to look at what is on the USB drive.
If it shows the format as iso9660.
That is the problem.

bigpup wrote: ↑Tue Jan 04, 2022 3:50 am

You should be able to use Gparted to look at what is on the USB drive.
If it shows the format as iso9660.
That is the problem.

Thanks for that. It may well prove to be the explanation for this phenomenon.
Thank you for your time and expertise. I am truly grateful

bigpup
Perhaps I was premature with my thanks and praise and should have checked first.

iso9660 is the file system I would expect to find with a cd or dvd iso. gparted doesn't show me an iso9660 choice for formatting my stick.

Hmm, MXLinux, Slackware, Fatdog64 and BionicPup all show as iso9660 when written to my USB stick.

Back to square 1. write a live system iso to USB and at odd intervals expect to smoke a USB stick now and again. Linux is destroying my flashdrives.
I never meant that a drag and drop of files to USB would do any harm but an entire bootable image sure can and you never see it coming.

I used the command line to prepare the USB, format, write and to restore the USB to an "as purchased" condition. MSDOS partition table, FAT32 format. This time I only used gparted to check for iso9660 file system

Maybe you do not, exactly understand, what I am talking about.

Use Gparted to look at the USB drives, that have an issue.
See what it says is the format, of whatever partition(s), are on the drive.
If iso9660 format is shown, as the format.
That is why they are read only.

Use Gparted to get the format changed, to a read/write format. (any other format is read/write. fat32, ntfs, ext 2,3,or4, etc....)
Do it by the directions, I posted earlier.

I am not saying to ever format a partition in iso9660 format!
Even if Gparted could do iso9660 formats.
Do not use iso9660 format.

There are several installer programs, for installing a operating system(OS) to a USB drive, using the operating system ISO.
Several of them will write the OS to the USB, like it would be burned to a CD/DVD.
They will format the USB drive iso9660 format.
Basically the same format a CD/DVD uses.
One is the basic dd command, to do an install to a USB drive. It will make the format iso9660.

Last time I used Unetbootin installer.
It did no formatting.
It did insist that the USB was already formatted fat32.
(a new USB flash drive, comes with one partition, already formatted fat32. So, that is an easy requirement, to have.)

None of the installers in Puppy Linux, will do this formatting.
They always want the USB partitioned and formatted by you first.

Note:
Use an installer program that does not do any formatting of the USB drive.
One that will accept the format already on the drive.

I think some of these installer programs, were coded with the idea, all you want to do is put the OS on a USB, and boot the computer with it.
Than install the OS to the internal drive of the computer, using programs in the OS.
Thus, make the USB boot and work, like a live install on a CD/DVD, which is why it gets formatted iso9660.

SIGH

I can see plainly that this has never happened to you, has it? You are fortunate.

The USB itself becomes "Write Protected", "Read Only". gparted is a poor tool in this case and proves powerless to do anything with it. Linux needs a better solution than that. What is most maddening is that ROOT has no ability to use the USB flashdrive. Another one yes, but that one no.

Hi @G0rdie

1st my emotional: "I HATE USB sticks"

Next the practical: There have been numerous members sharing about issues that they have personally "achieved" in horrible experiences in the sticks.

In my cases, until SAMSUNG and now some recent sticks from China, they are finally behaving 'close' to their advertised behaviors. ... but not all. (I have about 30 of them over the years, with ONLY 2 of the sticks having performance above 14 MB/sec.) The SAMSUNGs match their advertisements in performance...but mine are really SSD in a SAMSUNG casing (namely the T5 and a T7).

All of my HDDs over USBs, both IDEs and SATAs, perform better than sticks.

On the issue you have posted on your stick findings, I have had 2 that are identical to the issues you are reporting. One was a vendor stick from a seminar that I attempted to repurposed and another was a personal one that just flat fell into a state as you described. I found nothing in either Linux or Windows that would rescue them from the clutches of the Death Star. ... They ultimately were discarded in the trash after weeks of attempts with everything know to man. I also found that the "filesystem" IS NOT THE PROBLEM!!!

I currently have one that is 'LOCKED' in Fatdog that, again, nothing I have found will allow it to be repurposed. So, I continue to use it as a rescue disk to run apps from time to time.

I wish I could offer you a solution, but I cannot. I can only share my personal failures.

Most recently, over last 3 months, the SSD prices have plummeted to match the cost of sticks. And, they are performing very well over the USB enclosures I use. So, unless something new comes along to change my observation which has led to my views, I will NEVER buy another stick again.

The ONLY use for the sticks I have over the past 3 years are for simple information transfer or for ISO file booting. ANYONE who chooses to use a USB stick for anything beyond these limited uses, I wish you well. But my personal findings (my evidence) is horrible behaviors, horrible BIOS/UEFI interchanges from time to time depending on PCs, horrible performance, horrible lifespans, just HORRIBLE sticks...except for 2.

If I discover something useful, additional to my findings, I will share.
P.S. My USB drives (HDD/SSD) perform acceptably, by comparison.

G0rdie wrote: ↑Tue Jan 04, 2022 3:46 pm

MXLinux, Slackware, Fatdog64 and BionicPup all show as iso9660 when written to my USB stick.
Can you tell us which tools you used to create these installs?

I used the command line to prepare the USB, format, write and to restore the USB to an "as purchased" condition. MSDOS partition table, FAT32 format.
Could you say more about which commands and tools you use to a. format, b. write and c. restore

This time I only used gparted to check for iso9660 file system
when you use gparted, which version?, and have you tried to use gparted to initially create a new partition table by first choosing "device" in the menu, then "create partition table" in the dropdown and finally choosing "msdos"?
after running the operation what does gparted report?

williwaw wrote: ↑Wed Jan 05, 2022 4:23 am

G0rdie wrote: ↑Tue Jan 04, 2022 3:46 pm

MXLinux, Slackware, Fatdog64 and BionicPup all show as iso9660 when written to my USB stick.
Can you tell us which tools you used to create these installs?

I used the command line to prepare the USB, format, write and to restore the USB to an "as purchased" condition. MSDOS partition table, FAT32 format.
Could you say more about which commands and tools you use to a. format, b. write and c. restore

This time I only used gparted to check for iso9660 file system
when you use gparted, which version?, and have you tried to use gparted to initially create a new partition table by first choosing "device" in the menu, then "create partition table" in the dropdown and finally choosing "msdos"?
after running the operation what does gparted report?

Trust me I have tried everything I could think of with the help of DuckDuckGo. Actually got much practice making partition tables when I was trying to get UEFI working on this old laptop.

Version? Why the latest. gparted Version 1.3.1

Of late trying to keep unetbootin working with Slackware Current changing so frequently has kept me in a corner so to speak. Last evening I was able to compile unetbootin into a working program so I will resume using it from time to time.

For perhaps the last 6 months I have been using balenaEtcher. However, at least 50% of the time it crashes just as it begins to write and has to be reconfigured and started over. PITA sometimes.

There is reason for me to assume that once or twice I powered off while writing and interrupted it causing corruption on the flashdrive. Luckily I was able to recover from the situation and walk away with a fully functional flashdrive.

To write an image (iso) on a USB (Don't need a light):

dd if=bionicpup32-8.0-uefi.iso of=/dev/sdX status=progress

To restore a USB flashdrive:
The command line?

fdisk /dev/sdX

Commands?

man fdisk

There are lots of web pages showing how to use fdisk.

I keep files with the commands and use geany to send the commands to terminal. Cryptic names for these files helps me find what I need without having to open and read everything in my computer