[opensuse-factory] Can't mount fat32 USB sticks anymore
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Hi! Since a recent update (also had a problem with snapper rollback, so I can't be too sure the problem is from the update), I can't mount fat32 USB sticks any more using Plasma interface. The displayed name of the USB key is wrong (it displays a name like Kubuntu-x64-xxxx from when the USB was formatted to be a live USB, which it's not any more, very strange!) and clicking on "Open in File Manager" results in "Impossible to mount". However, the device can be mounted in CLI using the mount "command", files can be read, copied and written on the device using CLI. I suspect something went wrong at some point in how Plasma is supposed to mount USB keys and since I see nowhere report on this, that the problem is somehow specific to my system. Any help to pinpoint the origin of this issue (and for how to fix it) is welcomed! Cheers, Pierre. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-25 02:26, Pierre de Villemereuil wrote:
Hi!
Since a recent update (also had a problem with snapper rollback, so I can't be too sure the problem is from the update), I can't mount fat32 USB sticks any more using Plasma interface. The displayed name of the USB key is wrong (it displays a name like Kubuntu-x64-xxxx from when the USB was formatted to be a live USB, which it's not any more, very strange!) and clicking on "Open in File Manager" results in "Impossible to mount".
This means that you did not erase the critical areas before formatting it again as FAT. That situation has been described here some time ago, but I don't remember details enough to locate the thread or link. It doesn't fully explain why it does not mount automatically, only why the label is confused. maybe the system is sufficiently confused to not attempt to mount automatically. I would, thus, try with a new stick or a used one that you did not repurpose. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Oh, yeah, forgot to say, I tested different USB keys (all FAT32), they all behave the same. All where used to host a live USB though... Another thing is that they all work on another laptop with Linux Mint installed. I managed to find a key that worked. The main difference of that key is that it's a USB3-compatible one. It might that it was erased "better" than the others after hosting a live USB, though I don't remember doing anything different with it. If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32. I'm clueless about what's happening... Thanks for your help! Cheers, Pierre Le dimanche 25 juin 2017, 12:37:21 NZST Carlos E. R. a écrit :
On 2017-06-25 02:26, Pierre de Villemereuil wrote:
Hi!
Since a recent update (also had a problem with snapper rollback, so I can't be too sure the problem is from the update), I can't mount fat32 USB sticks any more using Plasma interface. The displayed name of the USB key is wrong (it displays a name like Kubuntu-x64-xxxx from when the USB was formatted to be a live USB, which it's not any more, very strange!) and clicking on "Open in File Manager" results in "Impossible to mount".
This means that you did not erase the critical areas before formatting it again as FAT. That situation has been described here some time ago, but I don't remember details enough to locate the thread or link.
It doesn't fully explain why it does not mount automatically, only why the label is confused. maybe the system is sufficiently confused to not attempt to mount automatically.
I would, thus, try with a new stick or a used one that you did not repurpose.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-25 02:55, Pierre de Villemereuil wrote:
Oh, yeah, forgot to say, I tested different USB keys (all FAT32), they all behave the same. All where used to host a live USB though... Another thing is that they all work on another laptop with Linux Mint installed.
I managed to find a key that worked. The main difference of that key is that it's a USB3-compatible one. It might that it was erased "better" than the others after hosting a live USB, though I don't remember doing anything different with it.
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
Ah, then, that hitches it.
I'm clueless about what's happening... Thanks for your help!
The issue is that the areas that the system uses to recognize an ISO image as an ISO image were not deleted or overwritten because they occupy different sectors than those overwritten when the media was formatted again as FAT. Remember that nowdays "format" means "fast format", ie, only the structures needed for FAT (in this case) are initialized, the rest are left intact. This usually means the data sectors are intact, but in this case the metadata for the iso and the fat do not use the same sectors so were not erased. Very probably the information is in the partition table or following few sectors. I would backup each stick, erase a bunch of raw sectors at the start of each stick - say 200 MB - and then partition-format as FAT again, and finally reload files from backup. Maybe someone remembers the thread where this thing happened some years ago and what steps were taken to investigate; might be mail list or forum. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Hi Carlos, You were right, I did a big purge of a non-working USB stick using: dd if=/dev/zero of=/dev/sdb bs=1M dd if=/dev/zero of=/dev/sdb bs=446 count=1 (I'm sure one of these two is not needed, but I just wanted to make sure I erased all partition data and the MBR) Then creating a partition table and FAT32 partition restores the ability to mount the USB stick! I'm still puzzled as to: - why this suddenly became a problem? - why the key was working on the Linux Mint laptop? I'm leaning toward a kernel update as the culprit, but this far above my skill set to investigate... Thanks for your help! Cheers, Pierre. Le dimanche 25 juin 2017, 13:10:27 NZST Carlos E. R. a écrit :
On 2017-06-25 02:55, Pierre de Villemereuil wrote:
Oh, yeah, forgot to say, I tested different USB keys (all FAT32), they all behave the same. All where used to host a live USB though... Another thing is that they all work on another laptop with Linux Mint installed.
I managed to find a key that worked. The main difference of that key is that it's a USB3-compatible one. It might that it was erased "better" than the others after hosting a live USB, though I don't remember doing anything different with it.
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
Ah, then, that hitches it.
I'm clueless about what's happening... Thanks for your help!
The issue is that the areas that the system uses to recognize an ISO image as an ISO image were not deleted or overwritten because they occupy different sectors than those overwritten when the media was formatted again as FAT. Remember that nowdays "format" means "fast format", ie, only the structures needed for FAT (in this case) are initialized, the rest are left intact. This usually means the data sectors are intact, but in this case the metadata for the iso and the fat do not use the same sectors so were not erased.
Very probably the information is in the partition table or following few sectors.
I would backup each stick, erase a bunch of raw sectors at the start of each stick - say 200 MB - and then partition-format as FAT again, and finally reload files from backup.
Maybe someone remembers the thread where this thing happened some years ago and what steps were taken to investigate; might be mail list or forum.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-25 04:07, Pierre de Villemereuil wrote:
Hi Carlos,
You were right, I did a big purge of a non-working USB stick using: dd if=/dev/zero of=/dev/sdb bs=1M dd if=/dev/zero of=/dev/sdb bs=446 count=1
A single: dd if=/dev/zero of=/dev/sdb bs=1M count=100 would more than suffice.
(I'm sure one of these two is not needed, but I just wanted to make sure I erased all partition data and the MBR)
Then creating a partition table and FAT32 partition restores the ability to mount the USB stick!
I'm still puzzled as to: - why this suddenly became a problem? - why the key was working on the Linux Mint laptop?
It has happened before. Simply something sees the clue that it is an ISO before it sees that it is also a partition table with a FAT partition, that's all. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/abdee805d4df05af9a496107100c582c.jpg?s=120&d=mm&r=g)
* Pierre de Villemereuil <flyos@mailoo.org> [06-24-17 20:55]:
Oh, yeah, forgot to say, I tested different USB keys (all FAT32), they all behave the same. All where used to host a live USB though... Another thing is that they all work on another laptop with Linux Mint installed.
I managed to find a key that worked. The main difference of that key is that it's a USB3-compatible one. It might that it was erased "better" than the others after hosting a live USB, though I don't remember doing anything different with it.
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
I'm clueless about what's happening... Thanks for your help!
Cheers, Pierre
Le dimanche 25 juin 2017, 12:37:21 NZST Carlos E. R. a écrit :
On 2017-06-25 02:26, Pierre de Villemereuil wrote:
Hi!
Since a recent update (also had a problem with snapper rollback, so I can't be too sure the problem is from the update), I can't mount fat32 USB sticks any more using Plasma interface. The displayed name of the USB key is wrong (it displays a name like Kubuntu-x64-xxxx from when the USB was formatted to be a live USB, which it's not any more, very strange!) and clicking on "Open in File Manager" results in "Impossible to mount".
This means that you did not erase the critical areas before formatting it again as FAT. That situation has been described here some time ago, but I don't remember details enough to locate the thread or link.
It doesn't fully explain why it does not mount automatically, only why the label is confused. maybe the system is sufficiently confused to not attempt to mount automatically.
I would, thus, try with a new stick or a used one that you did not repurpose.
I am running Tw 20170622 and have no problem reading fat16/32 cards via a usb3 hub or usb2 hub. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e76779f0629280df6d2dfce07e4e1600.jpg?s=120&d=mm&r=g)
Hello, Am Sonntag, 25. Juni 2017, 02:55:26 CEST schrieb Pierre de Villemereuil:
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
That might explain it. What Gparted sees is the partition type byte as stored in the partition table. You wrote that the sticks were used as live installers before, so it's likely that the partition type was indeed set to iso9660 [1]. The file system inside the partition is something completely unrelated, even if it would be nice if it matches the partition type. (Think of the difference between file name extensions and what the file command tells you about a file.) I woldn't be surprised if changing the partition type with fdisk or Gparted would be enough to solve your problem ;-) To do this with fdisk: fdisk /dev/sdx # obviously use the correct device of the stick type "m" for the manual (optional if you trust me ;-) type "p" to display the partition list type "t" for changing a partition type type "1" for the first partition, "2" for the second etc. type "b" to change the partition to "W95 FAT32" type "w" to write the changes to the stick In theory, this shouldn't do any damage to your data - but as always, having a backup is a good idea ;-) To change the name of the stick, the "fatlabel" command might help you. Regards, Christian Boltz [1] AFAIK there isn't a partition type specific to iso9660. Looking at a stick with the Leap 42.2 installer, I see Device Boot Start End Sectors Size Id Type /dev/sdc1 4084 11643 7560 3.7M ef EFI (FAT-12/16/32) /dev/sdc2 * 11644 8562687 8551044 4.1G 17 Hidden HPFS/NTFS -- it's possible that the K might have been inspired with Q from 'Qt' (and was expanded to 'Kool', because all acronyms are made by letting a cat walk on the keyboard/other random method first and then figuring what words match to the letters :-) ) [Łukasz "Cyber Killer" Korpalski in opensuse-project] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/a836ff90f492078f494adcf0c6059fc6.jpg?s=120&d=mm&r=g)
Christian Boltz composed on 2017-06-25 09:51 (UTC+0200):
schrieb Pierre de Villemereuil composed:
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
That might explain it.
What Gparted sees is the partition type byte as stored in the partition table. You wrote that the sticks were used as live installers before, so it's likely that the partition type was indeed set to iso9660 [1].
The file system inside the partition is something completely unrelated, even if it would be nice if it matches the partition type. (Think of the difference between file name extensions and what the file command tells you about a file.)
I woldn't be surprised if changing the partition type with fdisk or Gparted would be enough to solve your problem ;-)... To change the name of the stick, the "fatlabel" command might help you. . [1] AFAIK there isn't a partition type specific to iso9660. . According to https://en.wikipedia.org/wiki/Partition_type type 96 is iso9660. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
As per my last e-mail, I managed to make it work by wiping the USB stick using dd and /dev/zero as input (brutal, but efficient). On the second USB stick, dd actually had an issue, stopped very quickly, but that somehow fixed the issue (?!!). Interestingly, fdisk was analysing the USB sticks "properly" the whole time (i.e. it was seeing FAT32 partitions). Let's just say this was a gigantic mess, though I'm still wondering about which update made it apparent while the system bared with it before. I guess we'll never know. Thanks so much for you help, guys! Cheers, Pierre. Le dimanche 25 juin 2017, 19:51:48 NZST Christian Boltz a écrit :
Hello,
Am Sonntag, 25. Juni 2017, 02:55:26 CEST schrieb Pierre de Villemereuil:
If it helps, Gparted recognise the partition of the USB sticks not working as "iso9660" (I'm positive they're in fat32 and they are recognised as fat32 on the other laptop), while the USB stick that is working is actually recognised as a fat32.
That might explain it.
What Gparted sees is the partition type byte as stored in the partition table. You wrote that the sticks were used as live installers before, so it's likely that the partition type was indeed set to iso9660 [1].
The file system inside the partition is something completely unrelated, even if it would be nice if it matches the partition type. (Think of the difference between file name extensions and what the file command tells you about a file.)
I woldn't be surprised if changing the partition type with fdisk or Gparted would be enough to solve your problem ;-)
To do this with fdisk:
fdisk /dev/sdx # obviously use the correct device of the stick type "m" for the manual (optional if you trust me ;-) type "p" to display the partition list type "t" for changing a partition type type "1" for the first partition, "2" for the second etc. type "b" to change the partition to "W95 FAT32" type "w" to write the changes to the stick
In theory, this shouldn't do any damage to your data - but as always, having a backup is a good idea ;-)
To change the name of the stick, the "fatlabel" command might help you.
Regards,
Christian Boltz
[1] AFAIK there isn't a partition type specific to iso9660. Looking at a stick with the Leap 42.2 installer, I see
Device Boot Start End Sectors Size Id Type /dev/sdc1 4084 11643 7560 3.7M ef EFI (FAT-12/16/32) /dev/sdc2 * 11644 8562687 8551044 4.1G 17 Hidden HPFS/NTFS
-- it's possible that the K might have been inspired with Q from 'Qt' (and was expanded to 'Kool', because all acronyms are made by letting a cat walk on the keyboard/other random method first and then figuring what words match to the letters :-) ) [Łukasz "Cyber Killer" Korpalski in opensuse-project]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
25.06.2017 11:33, Pierre de Villemereuil пишет:
Let's just say this was a gigantic mess,
You successfully destroyed any possibility to investigate and fix it. Do not complaint when you see it again next time ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
You successfully destroyed any possibility to investigate and fix it. Do not complaint when you see it again next time ...
What's the point of this message? Have I been complaining? I just needed my USB sticks back, pinpointing to the actual responsible update is way above my league and the problem arose basically because of screwed-up formatting of a device, so I'm not even sure there's something here to "fix". But sure, thank you for your kind words... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-25 10:43, Andrei Borzenkov wrote:
25.06.2017 11:33, Pierre de Villemereuil пишет:
Let's just say this was a gigantic mess,
You successfully destroyed any possibility to investigate and fix it. Do not complaint when you see it again next time ...
He has more sticks with that problem :-) If you want to investigate, just burn an ISO image to a stick, then partition and format as FAT. Oh, but we probably need to use the same tools as he used for formatting. What did you use, Pierre? To avoid this happening again, just write a hundred megabytes of zeroes to the raw stick from its start to erase an ISO. Maybe 10 Mb suffices, maybe 1 Mb. I have seen this problem before. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Hi, The live USB (USB install in the case of openSUSE) were created using dd. They were after that formatted using Gparted. I guess it's a you say: Gparted is lazy (just as I am) and didn't wipe everything clean (well, most likely because I didn't care to do it since it worked "just fine"). Cheers, Pierre. Le lundi 26 juin 2017, 10:40:16 NZST Carlos E. R. a écrit :
On 2017-06-25 10:43, Andrei Borzenkov wrote:
25.06.2017 11:33, Pierre de Villemereuil пишет:
Let's just say this was a gigantic mess,
You successfully destroyed any possibility to investigate and fix it. Do not complaint when you see it again next time ...
He has more sticks with that problem :-)
If you want to investigate, just burn an ISO image to a stick, then partition and format as FAT. Oh, but we probably need to use the same tools as he used for formatting. What did you use, Pierre?
To avoid this happening again, just write a hundred megabytes of zeroes to the raw stick from its start to erase an ISO. Maybe 10 Mb suffices, maybe 1 Mb.
I have seen this problem before.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/abdee805d4df05af9a496107100c582c.jpg?s=120&d=mm&r=g)
* Pierre de Villemereuil <flyos@mailoo.org> [06-25-17 19:09]:
Hi,
The live USB (USB install in the case of openSUSE) were created using dd. They were after that formatted using Gparted.
I guess it's a you say: Gparted is lazy (just as I am) and didn't wipe everything clean (well, most likely because I didn't care to do it since it worked "just fine").
Cheers, Pierre.
Le lundi 26 juin 2017, 10:40:16 NZST Carlos E. R. a écrit :
On 2017-06-25 10:43, Andrei Borzenkov wrote:
25.06.2017 11:33, Pierre de Villemereuil пишет:
Let's just say this was a gigantic mess,
You successfully destroyed any possibility to investigate and fix it. Do not complaint when you see it again next time ...
He has more sticks with that problem :-)
If you want to investigate, just burn an ISO image to a stick, then partition and format as FAT. Oh, but we probably need to use the same tools as he used for formatting. What did you use, Pierre?
To avoid this happening again, just write a hundred megabytes of zeroes to the raw stick from its start to erase an ISO. Maybe 10 Mb suffices, maybe 1 Mb.
I have seen this problem before.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
if you read the openSUSE instructions on making a "live" usb stick, you will find there are also instructions on recovering the usb stick to use for normal file storage. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-26 02:25, Patrick Shanahan wrote:
* Pierre de Villemereuil <> [06-25-17 19:09]:
Hi,
The live USB (USB install in the case of openSUSE) were created using dd. They were after that formatted using Gparted.
I guess it's a you say: Gparted is lazy (just as I am) and didn't wipe everything clean (well, most likely because I didn't care to do it since it worked "just fine").
if you read the openSUSE instructions on making a "live" usb stick, you will find there are also instructions on recovering the usb stick to use for normal file storage.
Yes, but these were intended for the case where the standard procedure failed. Ie, if you simply initialize a stick using gparted, one assumes that gparted knows how to do it. It is a gparted bug. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Hi, Just to let you know that I could reproduce using the following protocol. 1- Download the Leap ISO, I used the NET install image from: https://software.opensuse.org/distributions/leap 2- Plug a USB key and copy the ISO on the USB key using: sudo dd if=/home/pierre/Downloads/openSUSE-Leap-42.2-NET-x86_64.iso of=/dev/sdc bs=4M status=progress && sync 3- Unplug & Replug (probably not necessary...) 4- Open Gparted, remove partitions on the USB key (don't touch the partition table!), create a new one in FAT32, put a label of your liking (say "MYLABEL"). This was a bit brutal and not cautious, but it creates roughly what you need, a formatted USB stick. This result in the following different behaviour in Leap and Tumbleweed: - In Leap, when you plug the USB stick, Plasma reads a USB device named "MYLABEL" and mount it without problem. Gparted sees it as a FAT32 partitioned device, as does fdisk. - In Tumbleweed, when you plug the USB stick, Plasma reads a USB device named "openSUSE-Leap..." and can't mount it. Gparted sees it as a ISO9660 partitioned device, but fdisk sees it as a FAT32 partitioned one. That's all I could think about. I'm keeping the USB stick as is if you want me to run some more tests (Leap I can do only at work during the day). Cheers, Pierre. On Monday, 26 June 2017 04:45:49 NZST Carlos E. R. wrote:
On 2017-06-26 02:25, Patrick Shanahan wrote:
* Pierre de Villemereuil <> [06-25-17 19:09]:
Hi,
The live USB (USB install in the case of openSUSE) were created using dd. They were after that formatted using Gparted.
I guess it's a you say: Gparted is lazy (just as I am) and didn't wipe everything clean (well, most likely because I didn't care to do it since it worked "just fine").
if you read the openSUSE instructions on making a "live" usb stick, you will find there are also instructions on recovering the usb stick to use for normal file storage.
Yes, but these were intended for the case where the standard procedure failed. Ie, if you simply initialize a stick using gparted, one assumes that gparted knows how to do it.
It is a gparted bug.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-26 05:28, Pierre de Villemereuil wrote:
Hi,
Just to let you know that I could reproduce using the following protocol.
1- Download the Leap ISO, I used the NET install image from: https://software.opensuse.org/distributions/leap 2- Plug a USB key and copy the ISO on the USB key using: sudo dd if=/home/pierre/Downloads/openSUSE-Leap-42.2-NET-x86_64.iso of=/dev/sdc bs=4M status=progress && sync 3- Unplug & Replug (probably not necessary...) 4- Open Gparted, remove partitions on the USB key (don't touch the partition table!), create a new one in FAT32, put a label of your liking (say "MYLABEL"). This was a bit brutal and not cautious, but it creates roughly what you need, a formatted USB stick.
This result in the following different behaviour in Leap and Tumbleweed: - In Leap, when you plug the USB stick, Plasma reads a USB device named "MYLABEL" and mount it without problem. Gparted sees it as a FAT32 partitioned device, as does fdisk. - In Tumbleweed, when you plug the USB stick, Plasma reads a USB device named "openSUSE-Leap..." and can't mount it. Gparted sees it as a ISO9660 partitioned device, but fdisk sees it as a FAT32 partitioned one.
Perfect! You could write a Bugzilla with that precise information, it is enough. :-) If you look at a dump of that USB stick with a hex editor you will see the ISO label somewhere near the start. Some of the structures of the ISO were not overwritten by gparted when formatting as FAT. I don't know if that data is in the first sector (the partition table) or further on. My guess is further on.
That's all I could think about. I'm keeping the USB stick as is if you want me to run some more tests (Leap I can do only at work during the day).
Maybe extract a 1 MB dump, verify the above, and attach to the bugzilla. I see two bugs or problems: - not clearing of the ISO structures by gparted - incorrect identification by TW. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-26 12:06, Carlos E. R. wrote:
If you look at a dump of that USB stick with a hex editor you will see the ISO label somewhere near the start. Some of the structures of the ISO were not overwritten by gparted when formatting as FAT. I don't know if that data is in the first sector (the partition table) or further on. My guess is further on.
Finding where is that label will tell the size of the area that should be erased with dd when you repurpose the stick. And maybe if the stick can be repaired without a full backup-erase-format-restore cycle. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Hi, No problem for opening a bug for this, but what do you mean by "creating a dump with a hex editor"? Could you provide me some guidelines to do that or point to a resource where it is explained? Thanks! Pierre Le lundi 26 juin 2017, 22:06:53 NZST Carlos E. R. a écrit :
On 2017-06-26 05:28, Pierre de Villemereuil wrote:
Hi,
Just to let you know that I could reproduce using the following protocol.
1- Download the Leap ISO, I used the NET install image from: https://software.opensuse.org/distributions/leap 2- Plug a USB key and copy the ISO on the USB key using: sudo dd if=/home/pierre/Downloads/openSUSE-Leap-42.2-NET-x86_64.iso of=/dev/sdc bs=4M status=progress && sync 3- Unplug & Replug (probably not necessary...) 4- Open Gparted, remove partitions on the USB key (don't touch the partition table!), create a new one in FAT32, put a label of your liking (say "MYLABEL"). This was a bit brutal and not cautious, but it creates roughly what you need, a formatted USB stick.
This result in the following different behaviour in Leap and Tumbleweed: - In Leap, when you plug the USB stick, Plasma reads a USB device named "MYLABEL" and mount it without problem. Gparted sees it as a FAT32 partitioned device, as does fdisk. - In Tumbleweed, when you plug the USB stick, Plasma reads a USB device named "openSUSE-Leap..." and can't mount it. Gparted sees it as a ISO9660 partitioned device, but fdisk sees it as a FAT32 partitioned one.
Perfect! You could write a Bugzilla with that precise information, it is enough. :-)
If you look at a dump of that USB stick with a hex editor you will see the ISO label somewhere near the start. Some of the structures of the ISO were not overwritten by gparted when formatting as FAT. I don't know if that data is in the first sector (the partition table) or further on. My guess is further on.
That's all I could think about. I'm keeping the USB stick as is if you want me to run some more tests (Leap I can do only at work during the day).
Maybe extract a 1 MB dump, verify the above, and attach to the bugzilla.
I see two bugs or problems:
- not clearing of the ISO structures by gparted - incorrect identification by TW.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-26 12:42, Pierre de Villemereuil wrote:
Hi,
No problem for opening a bug for this, but what do you mean by "creating a dump with a hex editor"? Could you provide me some guidelines to do that or point to a resource where it is explained?
dd if=/dev/sdX of=dumpfile bs=1M count=10 :-) Then use hexdump to see it, for instance. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/5f3b039558520fa6287ba843ddc8c6c7.jpg?s=120&d=mm&r=g)
Here's the bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1046096 Hopefully everything is there. Cheers, Pierre Le lundi 26 juin 2017, 22:51:32 NZST Carlos E. R. a écrit :
On 2017-06-26 12:42, Pierre de Villemereuil wrote:
Hi,
No problem for opening a bug for this, but what do you mean by "creating a dump with a hex editor"? Could you provide me some guidelines to do that or point to a resource where it is explained?
dd if=/dev/sdX of=dumpfile bs=1M count=10
:-)
Then use hexdump to see it, for instance.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-06-27 10:02, Pierre de Villemereuil wrote:
Here's the bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1046096
Hopefully everything is there.
Thanks :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (6)
-
Andrei Borzenkov
-
Carlos E. R.
-
Christian Boltz
-
Felix Miata
-
Patrick Shanahan
-
Pierre de Villemereuil