Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: SamK on January 02, 2013, 12:14:54 PM
-
TC v 4.7.2
Gparted v 0.13.1
mtools v 4.0.17
At startup of the app, Gparted shows a warning for FAT32
Error converting to codepage 850 invalid argument
Cannot initialize 'H:'
mlabel: Cannot initialize drive
When trying to apply a label to FAT32 it fails with the message
GParted 0.13.1
Libparted 3.1
Set Partition Label "LINWIN" on /dev/sdc1 00:00:01 ( ERROR )
calibrate /dev/sdc1 00:00:00 ( SUCCESS )
path: /dev/sdc1
start: 2048
end: 69631
size: 67584 (33.00 MiB)
Set partition label to "LINWIN" on /dev/sdc1 00:00:00 ( ERROR )
export MTOOLSRC=/tmp/gparted-XXIjnPPM && mlabel H:"LINWIN"
Error converting to codepage 850 Invalid argument
Cannot initialize 'H:'
mlabel: Cannot initialize drive
For reference, the issue is not present in the previous *.tcz
Gparted v 0.6.2
mtools v 4.0.12
-
Do you see the same thing on other partitions?
I have to say I never tested gparted on FAT since I don't use it - on testing a FAT16 partition I don't get the startup error, but I do get this: GParted 0.13.1
Libparted 3.1Set Partition Label "juanito" on /dev/sdc1 00:00:01 ( ERROR )
calibrate /dev/sdc1 00:00:00 ( SUCCESS )
path: /dev/sdc1
start: 32
end: 246271
size: 246240 (120.23 MiB)
Set partition label to "John_F" on /dev/sdc1 00:00:00 ( ERROR )
export MTOOLSRC=/tmp/gparted-XXabTFgU && mlabel H:"juanito"
Error converting to codepage 850 Invalid argument
Cannot initialize 'H:'
mlabel: Cannot initialize drive
No idea what caused this as yet...
-
From http://forum.tinycorelinux.net/index.php?topic=11128.0
Due to an unrelated subject I've discovered that the Error converting to codepage 850 Invalid argument error will most likely be resolved if you install the glibc_gconv.tcz extension. Whether that also helps to resolve the other errors is unknown to me, but I'm sure you'll find out yourself.
This seems to be connected to mtools mtools_default_codepage in config.c being 850?
Maybe you could try with glibc_gconv loaded?
-
Do you see the same thing on other partitions?
No idea what caused this as yet...
Only on FAT
This seems to be connected to mtools mtools_default_codepage in config.c being 850?
Maybe you could try with glibc_gconv loaded?
With glibc_gconv loaded the issue is not present.
Further Tests
Here, there is an existing system
TC v 4.1
Gparted v 0.6.2
mtools v 4.0.12
glibc_gconv is not installed
In this system the reported issue is not present.
Replacing mtools in the new (problematical) system
TC v 4.7.2
Gparted v 0.13.1
mtools v 4.0.12
glibc_gconv is not installed
In this condition the reported issue is still present.
Does this indicate the cause may not be mtools? Perhaps glibc_gconv is somehow working around the problem without addressing the cause.
Edit
Just musing. Might this have a bearing...
Working systemuname -r
3.03-tinycoreProblem systemuname -r
3.0.21-tinycore
-
If mtools needs to do codepage conversions, then it should depend on glibc_gconv (or eglibc_, don't remember the exact name).
-
Hi SamK
Do you have eglibc_gconv.tcz installed under TC4.1?
-
Hi SamK
Do you have eglibc_gconv.tcz installed under TC4.1?
Hi Rich
Neither eglibc_gconv or glibc_gconv are loaded and the gparted+mtools combination works OK.
-
Hi SamK
How about samba3.tcz ?
-
Hi SamK
How about samba3.tcz ?
Hi Rich,
Samba3, (just like the others mentioned earlier) is not installed.
-
Just to avoid playing tcz-tennis the list of extensions is attached.
Edit
The list refers to the TC 4.1 system.
-
Just a guess, perhaps the older mtools didn't have the conversion feature.
-
SamK
just a wild guess you have xorg lib tcz but not xorg-7.6 but my eyesight can not spot in those files any codepage 850
nor in kmaps
-
Wondering what would happen if you would omit loading mtools, if gparted would not just fall back on dosfstools for label function.
-
Just a guess, perhaps the older mtools didn't have the conversion feature.
In reply #3 (Further Tests) the older mtools was used together with the newer gparted and the current kernel. This was an attempt to identify if the needs of mtools had changed. Is there a way to directly enquire of the installed mtools whether the conversion feature is required?
just a wild guess you have xorg lib tcz but not xorg-7.6 but my eyesight can not spot in those files any codepage 850
nor in kmaps
None of the TC systems here use full Xorg, only Xvesa is used.
Wondering what would happen if you would omit loading mtools, if gparted would not just fall back on dosfstools for label function.
This does not work. Both dosfstools and mtools are required. If it had worked it would leave the cause of the discrepancy unidentified.
-
What, if anything, does "iconv --list" give on the two systems?
Does this bring any clarity:
http://www.nslu2-linux.org/wiki/HowTo/MountFATFileSystems
-
What, if anything, does "iconv --list" give on the two systems?
Attached are the two reports.
The 4.1 system runs in cloud mode and required libiconv.tcz to be downloaded in order to produce the report. In 4.7.2, iconv is present as a dependency of icewm.
-
Hmm - I wonder if this doesn't show all the code pages that were available in the eglibc source rather than those present on the system at present...
Anyway, since "850" is present in both, not terribly conclusive.
-
Just a guess, perhaps the older mtools didn't have the conversion feature.
In reply #3 (Further Tests) the older mtools was used together with the newer gparted and the current kernel. This was an attempt to identify if the needs of mtools had changed. Is there a way to directly enquire of the installed mtools whether the conversion feature is required?
Oh, I missed that. Could be from gparted and not mtools then. Anyway, glibc_gconv is required to do codepage conversions, so adding it as a dep is harmless.
-
Could be from gparted and not mtools then.
Or maybe parted.tcz itself. Current version 3.1 is 188KB. Previous version 2.3 is 240KB. Maybe a compile time
option was removed?
-
Wondering what would happen if you would omit loading mtools, if gparted would not just fall back on dosfstools for label function.
This does not work. Both dosfstools and mtools are required. If it had worked it would leave the cause of the discrepancy unidentified.
That made me sort of think about a weakness in gparted, when apparently mlabel and dosfslabel would serve the same purpose.
Doing some research, I found an explanation which I had not expected, the whole subject seems to be way more complex than I thought.
For reference:
http://gparted-forum.surf4.info/viewtopic.php?id=14115
https://bugzilla.gnome.org/show_bug.cgi?id=576616
-
Here are ldd reports from the TC 4.7.2 system. Gparted returns an error. Is this significant?
ldd /usr/local/sbin/gparted/usr/local/sbin/gparted: error while loading shared libraries: /usr/local/sbin/gparted: invalid ELF header
ldd /usr/local/bin/mtools linux-gate.so.1 => (0xb7732000)
libparted.so.2 => /usr/local/lib/libparted.so.2 (0xb76f1000)
libc.so.6 => /lib/libc.so.6 (0xb75e6000)
libdl.so.2 => /lib/libdl.so.2 (0xb75e2000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb75c7000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb75c2000)
/lib/ld-linux.so.2 (0xb7733000)
-
Hi SamK
Here are ldd reports from the TC 4.7.2 system. Gparted returns an error. Is this significant?
No, gparted is a script. Try:
ldd /usr/local/sbin/gpartedbin