Workaround for 'GParted renders FAT32 partition unreadable to Windows'

[Phoenix]

Bionicpup64 8.0 comes with a GParted/parted version that has a known regression. When resizing a FAT32 partition it will use psuedo-random data to write to the bootcode. However since Windows only looks for a specific pattern it won't read the said partition and claim it requires formatting. This already happened to me a couple of times, and the only way to put the bootcode back on is to format it in Windows again.
The specific GParted and parted version is 0.30.0 and 3.2.
I already have created my own .sfs and .desktop to work around this. Download here
The attachment is actually gzipped, so please don't actually try changing the extension.
NOTE: mtools became a new dependency too for FAT partitions. So an .sfs is also provided. As well, libgtkmm-3.0 is a new dependency. libgtkmm-3.0 is bundled into the gparted .sfs so no need to get it.
UPDATE NOTE 1: In case you're wondering why I put it into /usr/local or using LD_PRELOAD, this is because I don't expect the isos to be replaced with patched ones, and because otherwise the linker will just use the faulty libraries in /usr/lib instead of /usr/local/lib.

[April]

So if I use this will the formatted usb be readable by windows?

Its a particular pain that you take a usb stick of images you want printed to the store and the bloody windows based machines won't f,,n read it. Also go to the library to print a document and their machines won't read it either .

Its been happening for at least 5 years now in all versions of Puppy I have used so if this fixes that you have done us a great service.
I'll let you know .

So I downloaded the ".sfs" files to home and loaded them .
I put the desktop file on the desktop.
So what do I do now?
I'm assuming there will not be much difference between Bionicpup64 and xenialpup64 but that may be wrong.
I'm getting this error when trying to execute the load command in a terminal .Do you not include "libgtkmm-3.0.so.1" in the sfs?

Code: Select all

root# sh -c "LD_PRELOAD=/usr/local/lib/libparted.so.2:/usr/local/lib/libparted-fs-resize.so.0 /usr/local/libexec/gpartedbin"
/usr/local/libexec/gpartedbin: error while loading shared libraries: libgtkmm-3.0.so.1: cannot open shared object file: No such file or directory
root#

I used the package manager to download "libgtkmm-3.0.so.1" but it would not so I tried it with dependencies also and that appears to have suceeded so I'm at a loss where to go now? The terminal still shows the same error.

GPartedfix.jpg (181.98 KiB) Viewed 717 times

[Phoenix]

Uh yeah I forgot to pack in libgtkmm, that is why it was listed as a dependency. I will re-squash it then with libgtkmm-3.0. To be more specific, it is a version of (lib)parted that has the required patch for fixing the resizing bug. When it resizes, it should take a copy of the boot sector, then after it has completed, rewrite it as needed. However they failed to realize that the code was changed slightly, so that it would instead write psuedo-random data to the boot sector and make it unreadable.
Also I find it strange that if you installed libgtkmm-3.0 there is no symbolic link for that.
UPDATE: New .sfs has been uploaded.

[April]

Ah man looks like another of those .
Next problem

Code: Select all

root# sh -c "LD_PRELOAD=/usr/local/lib/libparted.so.2:/usr/local/lib/libparted-fs-resize.so.0 /usr/local/libexec/gpartedbin"
/usr/local/libexec/gpartedbin: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /usr/local/lib/libparted.so.2)
root# 

I don't understand why these are not found if loaded with the sfs file.?

Anyway ran the executable from within the sfs itself and it gave me gparted 3.2 and Gparted of 0.25.0
The puppy version I have in xenial64 7.5 is "0.25.0" so I stll don't think I am getting it.

I have reformatted the usb stick with gparted 3.2 now so Ill give it a try tomorrow in town. I have 180 photos I have been trying to get printed so this is very timely for me. Thanks

PS reading this

When it resizes, it should take a copy of the boot sector, then after it has completed, rewrite it as needed.

I'm thinking you have to start with a windows formatted Fat32 file anyway or the boot sector won't be there to copy so maybe I'll just score a usb format first and then try a reformat and copy my pics to it then and see if it works.

Can the boot sector be stored anywhere and reloaded independently any time?
Do you have a copy of the boot sector that I can write onto my Fat 32 usb sticks maybe?
You say it can't be done but surely there is a way ,even dd?

[Phoenix]

Ah man looks like another of those .
Next problem

Code: Select all

root# sh -c "LD_PRELOAD=/usr/local/lib/libparted.so.2:/usr/local/lib/libparted-fs-resize.so.0 /usr/local/libexec/gpartedbin"
/usr/local/libexec/gpartedbin: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /usr/local/lib/libparted.so.2)
root# 

I don't understand why these are not found if loaded with the sfs file.?

Anyway ran the executable from within the sfs itself and it gave me gparted 3.2 and Gparted of 0.25.0
The puppy version I have in xenial64 7.5 is "0.25.0" so I stll don't think I am getting it.

I have reformatted the usb stick with gparted 3.2 now so Ill give it a try tomorrow in town. I have 180 photos I have been trying to get printed so this is very timely for me. Thanks

PS reading this

When it resizes, it should take a copy of the boot sector, then after it has completed, rewrite it as needed.

I'm thinking you have to start with a windows formatted Fat32 file anyway or the boot sector won't be there to copy so maybe I'll just score a usb format first and then try a reformat and copy my pics to it then and see if it works.

Can the boot sector be stored anywhere and reloaded independently any time?
Do you have a copy of the boot sector that I can write onto my Fat 32 usb sticks maybe?
You say it can't be done but surely there is a way ,even dd?

It's rather quite difficult to attempt adding in an external libc and attempt to use the correct one. I'm afraid I don't have the skills for ensuring it would work. It would only work for bionicpup64 and perhaps more recent versions of the ubuntu pups. (But to be certain it will definitely work on bionicpup64).
The bug report that initiated this release https://bugzilla.gnome.org/show_bug.cgi?id=759916 states you can manually fix it. Either via hexedit or this (You may need to double backslashes as mentioned)
You can also back it up if you wish.

[April]

Thanks again .
I found this command to copy the first 3 bytes so it ran OK .
I won't be able to give it a test run for a few days probably, riding the wind atm.

Code: Select all

root#  echo -ne '\xeb\x58\x90' | dd conv=notrunc bs=1 count=3 of=/dev/sdb1
3+0 records in
3+0 records out
3 bytes copied, 0.00168072 s, 1.8 kB/s
root# 

I'll have a look at the rest of the 512 byte sector in time and try to see what is on my sticks.
Its always easier to just copy over the relevent bytes if you have them. (eb5890)

[Phoenix]

@666philb It would be appreciated if you could get on this issue soon, I already checked again in quickpet and there isn't a change to the parted version used.

[April]

Ther is a Gparted Live disk available
It can be booted into and it has the latest versions so you can format with that . Saves running out to find a windows machine.
https://gparted.org/livecd.php?fbclid=I ... bivGu2ZIt8

It also has a number of other features that may be useful like testdisk to recover deleted files etc.

[April]

Just to confirm I used the gparted live disk on my usb stick , put all the pics I wanted printed on it and went to BigW. The stick worked a treat

I also tried it on a laptop with the latest windows crap on it and it was fine.

I would mark this one as "SOLVED"