Weird issues using Gparted

[taersh]

Hi.

In all Puppies beyond Tahr I'm experiencing weird issues when using Gparted to format USB flash drives and hard disks.
Default use of writing and reading of files etc. all went fine.
But when I'm starting Gparted I get multiple messages like (abc stands for e.g. /dev/sdc):

Device abc removed.
New device abc found.

Device abc removed.
New device abc found.

Device abc removed.
New device abc found.

This happens three to five times before the device abc is recognized and stable existing.
Then again it repeats as soon as I'm starting the actions/tasks in Gparted like creating new partition, formatting partition etc.
This has already ruined at least three USB flash drives.

Anyone else ever experienced such?

[Clarity]

I am using 64bit Fossas, modern PUPs, and FATDOGs: I have not seen that.

I ask, have you tried PARTED to see if it exhibits the same. (If I understand Gparted, it is merely the graphical front-end to Parted).

P.S, which PUP/DOG and which version of Gparted?

[bigpup]

No problems like this for me in any Puppy version using Gparted.

You could have something going bad with the computers USB connection port.
Is this showing up using other USB connection ports?

Is Windows 10 on this computer?
If yes.
Did you do a complete normal shutdown of Windows 10?
Do not shutdown in hibernate!
Hibernate does not completely release control of the computer from Windows 10.

[HerrBert]

I can confirm this strange behaviour using GParted 0.26.1 on Slacko64 7.0 except for the messages about removing and finding new device.
The drive icon on desktop flashes when starting, applying changes, editing flags.
/tmp/udevtrace.log after starting GParted without doing any changes to the drive sdb:

Code: Select all

add_host8_scsi___
add_host8_scsi_host___
add_target8:0:0_scsi___
add_8:16_bdi___
add_8:0:0:0_scsi_SanDisk__scsi:t-0x00
add_8:0:0:0_scsi_device___
add_8:0:0:0_scsi_disk___
add_8:0:0:0_bsg___
add_sdb_block___
add_sdb1_block___
change_sdb1_block___
change_sdb_block___
change_sdb1_block___
change_sdb_block___
change_sdb1_block___
change_sdb_block___
change_sdb1_block___
change_sdb_block___
change_sdb1_block___
change_sdb_block___
change_sdb1_block___

No other messages found in /tmp/xerrs.log or dmesg

[April]

Insert and remove usb plug many times quickly . Corrosion will be my guess. Try to clean computer port contacts with metho or contact cleaner and a cotton bud reduced to fit. Else replace the port with a new one if you can.

[LateAdopter]

I think April is on the right track.

Type-A USB connectors are unreliable. If the supply breaks while you are writing the first erase block of a USB stick, you lose the LBA translation table. Then you get the error: "Insert disk in drive X" or "No media" depending on your operating system.

I have read that Sandisk and Transcend can fix their sticks over the internet, but only with Windows. SD Cards probably don't have this problem.

USB3 connectors are not as wobbly as USB2. I haven't had a problem with them, yet.

[taersh]

I can confirm this strange behaviour using GParted 0.26.1 on Slacko64 7.0 except for the messages about removing and finding new device.

The messages are not literally exactly. It's a small Xdialog or Yad message GUI that appears.
The computer is completely new. It doesn't make a difference if plugged into USB2 or USB3 ports.
The USB flash drives have been new, just bought a few days before using/formatting them.

[HerrBert]

In my case this behaviour is not limited to USB drives, happens to internal hd also. Tried on 2 different machines.
This is what it looks like when starting GParted:

driveicons.gif (127.37 KiB) Viewed 935 times

[Feek]

I also see the blinking of these icons when Gparted is launched.

But I think the blinking is not a problem. My explanation is that Gparted is searching for all available partitions on the computer.

[LateAdopter]

The computer is completely new.

There has been a problem reported with AMD 5000 series, of dropped USB connections. There have been a few BIOS updates that are supposed to fix it.

Could that be the problem?

[Jafadmin]

What you are witnessing is udev "bounce" or "jitter". It's the result of 'partprobe' running for each change that gets committed.

So: Parted changes something on the USB drive -> 'partprobe' forces a kernel drive scan -> udev rescans for the new change

It doesn't happen on non-PnP devices because they don't trigger udev.

Just don't goof with the removable drive until it "settles".

[bigpup]

If this is correct.
We should all be seeing this.
I am not.
Well, seeing any error messages or access issues.

taersh,

Tell us the exact specs of the computer?
Laptop or desktop?

Give us a specific Puppy version to work with?
Fossapup64 9.5 would be a good Puppy version to troubleshoot with.

You say you partitioned and formatted these USB sticks.

What format?
That could be an issue.
Puppy does not support all possible formats.

Did you do this using Gparted in Puppy?
Did you use a fairly new version of Gparted?
Make new partition table?
Partition?
Format?

Could try making a Gparted live CD or USB to be using the latest Gparted.
https://gparted.org

Some Puppy versions have some very old versions of Gparted.

You say this is a new computer.
No way it could have any hardware problems!
It is new!

Example:
I have seen a brand new desktop computer that had front face USB ports that did not work correctly.
Open the side of computer.
Found cable from motherboard to these USB ports, having loose connection to the motherboard.
Pushed cable connection back down completely.
No more front face USB port problems.

[taersh]

Computer (Desktop PC):

Motherboard Vendor: ASRock
Product Name: B450 Pro4

BIOS Vendor: American Megatrends Inc.
Version: L3.31
Release Date: 05/31/2019

AMD Ryzen 5 2600X Six-Core Processor
Min/Max Speed: NA/NA MHz
Current Speed of Core 0:3599 MHz, 1:3599 MHz, 2:3599 MHz, 3:3599 MHz, 4:3599 MHz, 5:3599 MHz, 6:3599 MHz, 7:3599 MHz, 8:4025 MHz, 9:4019 MHz, 10:3599 MHz, 11:3599 MHz
Core Count: 6
Thread Count: 12

The problem appears on front USB ports as well as on the main board's USB ports. No difference at all.
As I wrote: I'm experiencing this in all Puppies beyond Tahr. When I'm booting my own Tahr version everything's fine.
So, this is an issue experienced in different versions of Gparted and its underlying parted.

There's no difference, if I'm formatting ext or vfat partitions.
The icon blinks (it disappears and again appears on the desktop) and the message GUI appears several times.
No difference, if I made a new partition table or not.

Default read and write works like a charm on all USB ports, with all USB hard drives and flash drives.
Even booting form USB hard drive or flash drive works fine.

Since I'm using Puppy exclusively, yes, it's Gparted in Puppy being used.

[Clarity]

Hello @taeRSH
Not sure if it is related to this problem, but @Shinobar reports this

[bigpup]

This is info on Bios updates for that motherboard Asrock B450 pro4
https://www.asrock.com/MB/AMD/B450%20Pr ... x.asp#BIOS

[bigpup]

Look in the UEFI bios setup.
Under advanced storage configuration
SATA Controller(s)Enable.
SATA M o d e set to:
AHCI: Supports new features that improve performance.
SATA Hot Plug Enable the SATA Hot Plug Function.

Any help?

Also look at other settings in the UEFI setup for anything not normal.
Voltage settings maybe.

[LateAdopter]

This is info on Bios updates for that motherboard Asrock B450 pro4
https://www.asrock.com/MB/AMD/B450%20Pr ... x.asp#BIOS

Ha! Ha! The warnings are dazzling. No BIOS update needed for your Pinnacle Ridge processor.

The problem that I mentioned only affected 5000 series that were added with AGESA-AM4 1.2.0.0

[Jafadmin]

If this is correct.
We should all be seeing this.

Why? Unless we are all using the same Mobo and USB stick, that statement is extremely whackadoodle.

Every time you boot a puppy version you will see the message, "Waiting for USB devices". This is because the kernel does not process PnP at wire speed. Furthermore, USB chipsets do not work at wire speed. The net result is that changes to a USB flash drive are not instantaneous. They can take up to 5 seconds to register with the kernel.

If you make several change operations to a USB stick with GPartEd before clicking on the 'Apply' button, it will have a 'churning' type behavior. It will be more noticeable on slower mobos and flash drives.

[rcrsn51]

and the message GUI appears several times.

Please post a screen snapshot of it.

[taersh]

and the message GUI appears several times.

Please post a screen snapshot of it.

I could do that, if the messages would stay for a while. But they don't. Within appr. 2 seconds the messages appears up to 5 times.
I will try to record this with SSR and getting a single frame from that video.

vlcsnap-2021-07-18-20h59m19s989.jpg (49.12 KiB) Viewed 850 times

[bigpup]

Did you build this computer?

Did you look in the UEFI setup for any of the items I suggested?

Being a desktop computer.
It is simple to take the side off and check all connections to the motherboard.

in ASRock BIOS menu, there's a feature called Deep Sleep.
This affects power to the USB ports.

you can only figure out what is wrong by finding out what is correct.

Did you try making a Gparted live USB or CD and see how it reacts?
That should not be showing this issue.
If it does not have issues.
Then that points to a Puppy specific problem.
Besides, this Gparted live is a good repair device to have.
It has some good fix programs besides Gparted.
It could also be a way to fix this:

This has already ruined at least three USB flash drives.

Give us a specific Puppy version to work with?
Fossapup64 9.5 would be a good Puppy version to troubleshoot with.
Maybe something is just missing, that is needed to make it all work correctly, to support this specific hardware.
It does seem to be issue on this specific hardware, only.

[bigpup]

Looking at some of my Puppy versions installs.
I see a one or two times the desktop drive icon not showing and then showing, when starting Gparted, set to access a specific drive. but nothing like you are seeing.
It is the drive icon for the drive you select in the Gparted startup window, where you select drive to work on.

Never getting any messages.

Gparted seems to work OK.

Your hardware seems to be really affected by this.

So, maybe you have found a bug that has gotten into the newer Puppy versions.
Lets try to look at a specific Puppy version to troubleshoot.

Update:
If I select all drives in this Gparted startup selection window.
I am seeing the desktop icons not showing and showing in a cycle around 4 or 5 times.
But still not seeing any messages like you are.
Gparted still works OK.

[greengeek]

Sounds like two different items of software trying to access the drive and causing a conflict.

I suspect maybe a udev rule trying to handle MTP devices may be interfering with Gparted's attempt to mount and umnount the drives.

(even though the drives are not part of a MTP device)

Does dmesg show anything?

[taersh]

Ok.

This has nothing to do with the new computer's hardware.
The same problem appears on my older AMD K6 computer.
It appears in all Puppies beyond Tahr Puppy on both computers.

For the messages appearing:

I found out, these messages are from my modified version of a related script.
This gives me a message when a new USB storing device is plugged in and it gives me also a message when it's plugged out.
Since Gparted is loosing the device the message of plugging in and out appears on the screen.
Without that modification the related icon disappears and appears on the screen only several times.

NO, no, no, these message aren't causing this strange behavior, as I have exactly the same modifications in my Tahr Puppy.
In my Tahr Puppy Gparted doesn't loose any device at all.

[taersh]

Just in addition:

- the problem appears also on e.g. SD-Cards plugged into the card reader

Can't say for the older computer, as this doesn't have a card reader port.

[bigpup]

Well, I think you have discovered a small bug that has gotten into Puppy.
The desktop drive icons will disappear and reappear as Gparted is accessing them.

I see this in Fossapup64 9.5 for testing.

Shouldn't the desktop drive icon disappear, when Gparted is doing something to change the file system, on it?
Making partition table, partitioning, formatting.
For a time, it has no readable functioning file system.

If I am remembering correctly.
The desktop drive icons get search refreshed about every 2 seconds for the hot plug feature.

But Gparted is still working OK.
Doing anything I want to do to the drive. Any drive.

Note:
I tried using Gparted in Slacko64 8.2.1 and it is having maybe the problem you describe on making a usable drive.
But this Slacko is in Alpha/Beta status and is going to be buggy.
Bug already reported in the Slacko64 8.2.1 topic.

[bigpup]

Gparted in Fossapup64 9.5 is working OK for me as far as doing anything to a drive.

So how about trying Gparted in Fossapup64 9.5.
If it makes a messed up drive.
Specifically, what does it seem to be doing to it???

specific details.
You do what?
You see what?

That Gparted live or as you say, Gparted in Tahrpup, should be able to fix the drive, if you have to use them, to do the fix.

[greengeek]

Are there any clues in the dmesg output?

[Jafadmin]

Shouldn't the desktop drive icon disappear, when Gparted is doing something to change the file system, on it?
Making partition table, partitioning, formatting.
For a time, it has no readable functioning file system.

If I am remembering correctly.
The desktop drive icons get search refreshed about every 2 seconds for the hot plug feature.

But Gparted is still working OK.
Doing anything I want to do to the drive. Any drive.

The key thing to keep in mind is that GPartEd is running as root and doing system/kernel level tasks, and has nothing whatsoever to do with your desktop manager.

The icon "jittering" is produced by your desktop manager trying to follow and display whatever state 'parted' has the PnP devices in.

So two things are happening; GpartEd is re-configuring the partitions and filesystems on a plug 'n play device, and your desktop manager is trying to keep up with the changes as they occur and display them in "real time".

This is not a bug. It is a misunderstanding of what is happening.

[taersh]

Are there any clues in the dmesg output?

How would I check this?
Do I need the USB flash drive plugged in?
Do I need to run Gparted?
Before dmesg or after dmesg?