(F-42; stand-alone workstation; Gnome)
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick. The upgrade failed. A local friend gave me a windows-10 box to use. Until I could get the Fedora workstation adequately restored, I needed to get a few things off the F-40 back-up onto the windows-10 box. Attempts to re-install Fedora from Fedora-42 Live Workstation appear to have completely destroyed the partitioning of the hard drive. When I inserted the back-up stick into the port, windows-10 told me to use defender to scan the stick. I did so. I asked for a scan only. I did not want defender to attempt any repair or other changes. Defender reported no problems. But now when I insert the back-up stick into a port on either tower, it's claimed the back-up stick is un-formatted and empty. Fedora's "disks" and windows-10 (file browser and defender) agree. I do not recall which file system the back-up stick was formatted with beforehand.
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
On 5/1/25 8:12 PM, home user via users wrote:
(F-42; stand-alone workstation; Gnome)
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick. The upgrade failed. A local friend gave me a windows-10 box to use. Until I could get the Fedora workstation adequately restored, I needed to get a few things off the F-40 back-up onto the windows-10 box. Attempts to re-install Fedora from Fedora-42 Live Workstation appear to have completely destroyed the partitioning of the hard drive. When I inserted the back-up stick into the port, windows-10 told me to use defender to scan the stick. I did so. I asked for a scan only. I did not want defender to attempt any repair or other changes. Defender reported no problems. But now when I insert the back-up stick into a port on either tower, it's claimed the back-up stick is un-formatted and empty. Fedora's "disks" and windows-10 (file browser and defender) agree. I do not recall which file system the back-up stick was formatted with beforehand.
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
How did you do the backup? Windows doesn't like any Linux filesystems and will consider the drive corrupted or unformatted. But it doesn't usually overwrite it unless you say so.
You can try running "gpart" on it. That will try to discover the partitions.
On 5/1/25 9:41 PM, Samuel Sieb wrote:
On 5/1/25 8:12 PM, home user via users wrote:
(F-42; stand-alone workstation; Gnome)
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick.
[snip]
But now when I insert the back-up stick into a port on either tower, it's claimed the back-up stick is un-formatted and empty. Fedora's "disks" and windows-10 (file browser and defender) agree. I do not recall which file system the back-up stick was formatted with beforehand.
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
How did you do the backup? Windows doesn't like any Linux filesystems and will consider the drive corrupted or unformatted. But it doesn't usually overwrite it unless you say so.
This was an "incremental" back-up. 1. insert stick into port. 2. open file browser; navigate to the stick. 3. open another file browser; navigate to what I want to back up. 4. in the second file browser, select what I want to back up, and drag it to the first file browser. 5. when the copy is done, clear cache and then do a diff to check that it worked. This was done weekly. Once a back-up is 3 weeks old, it's deleted from the stick.
You can try running "gpart" on it. That will try to discover the partitions.
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
Primary partition(2) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
#
I don't know what to make of this. The defender totally zero everything, or are the files and directories actually out there but with nothing pointing to them?
On 5/2/25 9:44 AM, home user via users wrote:
On 5/1/25 9:41 PM, Samuel Sieb wrote:
You can try running "gpart" on it. That will try to discover the partitions.
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
That looks correct. The stick likely came preformatted as FAT32. Does "fdisk -l /dev/sdb" show any partitions? If not, then run "gpart -W /dev/sdb /dev/sdb". This will write the discovered partition table to the drive and you can try mounting it.
I don't know what to make of this. The defender totally zero everything, or are the files and directories actually out there but with nothing pointing to them?
The answer to that is not clear yet.
On 5/2/25 4:01 PM, Samuel Sieb wrote:
On 5/2/25 9:44 AM, home user via users wrote:
On 5/1/25 9:41 PM, Samuel Sieb wrote:
You can try running "gpart" on it. That will try to discover the partitions.
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
That looks correct. The stick likely came preformatted as FAT32. Does "fdisk -l /dev/sdb" show any partitions? If not, then run "gpart -W /dev/sdb /dev/sdb". This will write the discovered partition table to the drive and you can try mounting it.
(inserted stick into left USB3 port)
# fdisk -l /dev/sdb fdisk: cannot open /dev/sdb: No such file or directory #
(removed stick; inserted stick into right USB3 port)
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
The gnome file browser seems to not see the stick. By the way, I've never been able to figure out how to manually (from the command line) mount something. File browsers do that for me nicely.
I don't know what to make of this. The defender totally zero everything, or are the files and directories actually out there but with nothing pointing to them?
The answer to that is not clear yet.
On 5/2/25 3:34 PM, home user via users wrote:
On 5/2/25 4:01 PM, Samuel Sieb wrote:
On 5/2/25 9:44 AM, home user via users wrote:
On 5/1/25 9:41 PM, Samuel Sieb wrote:
You can try running "gpart" on it. That will try to discover the partitions.
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
That looks correct. The stick likely came preformatted as FAT32. Does "fdisk -l /dev/sdb" show any partitions? If not, then run "gpart -W /dev/sdb /dev/sdb". This will write the discovered partition table to the drive and you can try mounting it.
(inserted stick into left USB3 port)
# fdisk -l /dev/sdb fdisk: cannot open /dev/sdb: No such file or directory #
(removed stick; inserted stick into right USB3 port)
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
The gnome file browser seems to not see the stick. By the way, I've
Does windows see it?
never been able to figure out how to manually (from the command line) mount something. File browsers do that for me nicely.
"sudo mount /dev/sdb1 /mnt"
On 5/2/2025 4:40 PM, Samuel Sieb wrote:
On 5/2/25 3:34 PM, home user via users wrote:
On 5/2/25 4:01 PM, Samuel Sieb wrote:
On 5/2/25 9:44 AM, home user via users wrote:
On 5/1/25 9:41 PM, Samuel Sieb wrote:
You can try running "gpart" on it. That will try to discover the partitions.
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
That looks correct. The stick likely came preformatted as FAT32. Does "fdisk -l /dev/sdb" show any partitions? If not, then run "gpart -W /dev/sdb /dev/sdb". This will write the discovered partition table to the drive and you can try mounting it.
(inserted stick into left USB3 port)
# fdisk -l /dev/sdb fdisk: cannot open /dev/sdb: No such file or directory #
(removed stick; inserted stick into right USB3 port)
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
The gnome file browser seems to not see the stick. By the way, I've
Does windows see it?
yes and no! It knows I inserted the stick into the port. It pops up the file explorer. But it also pops up a little box that says "Please insert a disk into USB Drive (F:).
If I "eject" the stick, remove it, and put it into the other port, windows-10 pops up another little box saying "You need to format the disk in drive F: before you can use it. Do you want to format it?". The box has 2 buttons: "Format disk" and "Cancel". I clicked "Cancel". Then windows-10 popped up another window saying "F:\ is not accessible. Please make sure that all required file systems drivers are loaded and that the volume is not corrupted.".
By the way, I was able (with difficulty) to get a few files off the stick earlier this week, so windows-10 was able to read the stick. But then it insisted on me scanning it with defender, and I, not knowing better, did so. I don't know how relevant that is.
never been able to figure out how to manually (from the command line) mount something. File browsers do that for me nicely.
"sudo mount /dev/sdb1 /mnt"
Thank-you, Samuel.
On 5/2/25 3:58 PM, home user via users wrote:
On 5/2/2025 4:40 PM, Samuel Sieb wrote:
never been able to figure out how to manually (from the command line) mount something. File browsers do that for me nicely.
"sudo mount /dev/sdb1 /mnt"
Thank-you, Samuel.
I was expecting a follow-up to this. Did you try mounting it? If it doesn't work, what do you see in the journal?
On 5/5/25 3:37 PM, Samuel Sieb wrote:
On 5/2/25 3:58 PM, home user via users wrote:
On 5/2/2025 4:40 PM, Samuel Sieb wrote:
never been able to figure out how to manually (from the command line) mount something. File browsers do that for me nicely.
"sudo mount /dev/sdb1 /mnt"
Thank-you, Samuel.
I was expecting a follow-up to this. Did you try mounting it? If it doesn't work, what do you see in the journal?
I think I misunderstood your Friday messages. I thought you meant this: - - - - - Do "fdisk -l /dev/sdb". If (that does NOT show partitions) then ...run "gpart -W /dev/sdb /dev/sdb". ...try mounting the stick. End if. - - - - - The fdisk command did show a "primary" partition, so I bypassed the "gpart" and the mount attempt. Did you actually mean this: - - - - - Do "fdisk -l /dev/sdb". If (that does NOT show partitions) then ...run "gpart -W /dev/sdb /dev/sdb". End if. Try mounting the stick. - - - - - My apologies that I misunderstood you.
Here's a mount attempt: - - - - - # fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # - - - - -
I lost almost all notes last month. Please tell me how to get what's wanted from the journal.
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call.
Try the following:
lsblk -f /dev/sdb mount /dev/sdb1 /mnt dmesg | tail
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call.
Try the following:
lsblk -f /dev/sdb mount /dev/sdb1 /mnt dmesg | tail
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 3959.234522] usb 3-2: SerialNumber: 070735D7CBE2C554 [ 3959.235427] usb-storage 3-2:1.0: USB Mass Storage device detected [ 3959.235777] scsi host10: usb-storage 3-2:1.0 [ 3960.292550] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 3960.293059] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 3960.343345] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 3960.343761] sd 10:0:0:0: [sdb] Write Protect is off [ 3960.343770] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 3960.344185] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3960.355980] sd 10:0:0:0: [sdb] Attached SCSI removable disk #
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call.
Try the following:
lsblk -f /dev/sdb mount /dev/sdb1 /mnt dmesg | tail
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 3959.234522] usb 3-2: SerialNumber: 070735D7CBE2C554 [ 3959.235427] usb-storage 3-2:1.0: USB Mass Storage device detected [ 3959.235777] scsi host10: usb-storage 3-2:1.0 [ 3960.292550] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 3960.293059] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 3960.343345] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 3960.343761] sd 10:0:0:0: [sdb] Write Protect is off [ 3960.343770] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 3960.344185] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3960.355980] sd 10:0:0:0: [sdb] Attached SCSI removable disk
What happened to the partition? Run "journalctl -fa" in a terminal and try plugging it in again. You should see a line like: "kernel: sdb: sdb1" It might be a letter other than "b", so adjust all commands if it is different. If you don't get that partition list, then try running: dd if=/dev/sdb of=/dev/null bs=1M status=progress Let it run for a while. If it doesn't give an error, you can stop it with CTRL-C.
If you do get the partition list, then try that set of commands again.
On 5/5/25 6:31 PM, Samuel Sieb wrote:
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call.
Try the following:
lsblk -f /dev/sdb mount /dev/sdb1 /mnt dmesg | tail
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 3959.234522] usb 3-2: SerialNumber: 070735D7CBE2C554 [ 3959.235427] usb-storage 3-2:1.0: USB Mass Storage device detected [ 3959.235777] scsi host10: usb-storage 3-2:1.0 [ 3960.292550] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 3960.293059] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 3960.343345] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 3960.343761] sd 10:0:0:0: [sdb] Write Protect is off [ 3960.343770] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 3960.344185] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3960.355980] sd 10:0:0:0: [sdb] Attached SCSI removable disk
What happened to the partition? Run "journalctl -fa" in a terminal and try plugging it in again. You should see a line like: "kernel: sdb: sdb1" It might be a letter other than "b", so adjust all commands if it is different. If you don't get that partition list, then try running: dd if=/dev/sdb of=/dev/null bs=1M status=progress Let it run for a while. If it doesn't give an error, you can stop it with CTRL-C.
If you do get the partition list, then try that set of commands again.
1. entered journalctl -fa command 2. pulled stick out. 3. re-inserted stick. 4. when the journalctl output stopped, I selected it and pasted it into a text file (459 lines). 5. I grepped the text file for "kernel" and re-directed the output to another text file (335 lines). I Ctrl-C'd the journalctl.
The output files above are too long to post. Let me know if you want me to send them privately.
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 5763.115046] usb 3-2: SerialNumber: 070735D7CBE2C554 [ 5763.116009] usb-storage 3-2:1.0: USB Mass Storage device detected [ 5763.116419] scsi host10: usb-storage 3-2:1.0 [ 5764.122196] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 5764.122748] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 5764.150633] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 5764.151127] sd 10:0:0:0: [sdb] Write Protect is off [ 5764.151137] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 5764.151535] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 5764.162742] sd 10:0:0:0: [sdb] Attached SCSI removable disk #
I'm send this out now. While you look at this, I'll get the dd going.
On 5/5/25 5:57 PM, home user via users wrote:
On 5/5/25 6:31 PM, Samuel Sieb wrote:
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model:
This is very concerning. I wonder if you have a fake USB drive. If that's the case, then you can consider your data gone. And it often doesn't fail until you've written a certain amount of data. Or possibly also read a certain amount which is likely what happened in this case.
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb
If this or fdisk doesn't return any partitions, then there's no point trying to mount it.
Try running "gpart /dev/sdb" again. If it still finds the FAT32 partition, then run "gpart -W /dev/sdb /dev/sdb".
Assuming that's successful, try "lsblk -f /dev/sdb".
If that still shows the partition, then try mounting it.
If that fails, show "dmesg | tail".
read all the way to the end; don't stop too soon!
On 5/5/25 8:46 PM, Samuel Sieb wrote:
On 5/5/25 5:57 PM, home user via users wrote:
On 5/5/25 6:31 PM, Samuel Sieb wrote:
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model:
This is very concerning. I wonder if you have a fake USB drive. If that's the case, then you can consider your data gone. And it often doesn't fail until you've written a certain amount of data. Or possibly also read a certain amount which is likely what happened in this case.
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb
If this or fdisk doesn't return any partitions, then there's no point trying to mount it.
Try running "gpart /dev/sdb" again. If it still finds the FAT32 partition, then run "gpart -W /dev/sdb /dev/sdb".
Assuming that's successful, try "lsblk -f /dev/sdb".
If that still shows the partition, then try mounting it.
If that fails, show "dmesg | tail".
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
Primary partition(2) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 159.545514] usb-storage 3-1:1.0: USB Mass Storage device detected [ 159.545897] scsi host10: usb-storage 3-1:1.0 [ 160.560274] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 160.560711] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 160.592625] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 160.593048] sd 10:0:0:0: [sdb] Write Protect is off [ 160.593057] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 160.593483] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported #
Notes: Last week, before I did the defender scan that windows recommended, I did get a few files off the stick. I got all that I tried. I did not try most. Between doing fdisk (late last Friday) and "What happened to the partition?" (this afternoon) I tried to see if windows sees the stick. As far as I know, I did nothing that would have windows write to the stick. But might it have written to the stick without us knowing?
Breaking news?... Looking at last Friday's posts again, I see that you had me try fdisk, which I did do on Friday. That hasn't been tried today. Is that what produced output suggesting some sort of a partition on the stick? I just tried it again. The results:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 159.545514] usb-storage 3-1:1.0: USB Mass Storage device detected [ 159.545897] scsi host10: usb-storage 3-1:1.0 [ 160.560274] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 160.560711] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 160.592625] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 160.593048] sd 10:0:0:0: [sdb] Write Protect is off [ 160.593057] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 160.593483] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported #
Does that change the picture?
On 5/5/25 20:18, home user via users wrote:
read all the way to the end; don't stop too soon!
On 5/5/25 8:46 PM, Samuel Sieb wrote:
On 5/5/25 5:57 PM, home user via users wrote:
On 5/5/25 6:31 PM, Samuel Sieb wrote:
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote: > Here's a mount attempt: > - - - - - > # fdisk -l /dev/sdb > Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors > Disk model:
This is very concerning. I wonder if you have a fake USB drive. If that's the case, then you can consider your data gone. And it often doesn't fail until you've written a certain amount of data. Or possibly also read a certain amount which is likely what happened in this case.
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb
If this or fdisk doesn't return any partitions, then there's no point trying to mount it.
Try running "gpart /dev/sdb" again. If it still finds the FAT32 partition, then run "gpart -W /dev/sdb /dev/sdb".
Assuming that's successful, try "lsblk -f /dev/sdb".
If that still shows the partition, then try mounting it.
If that fails, show "dmesg | tail".
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
Primary partition(2) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 159.545514] usb-storage 3-1:1.0: USB Mass Storage device detected [ 159.545897] scsi host10: usb-storage 3-1:1.0 [ 160.560274] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 160.560711] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 160.592625] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 160.593048] sd 10:0:0:0: [sdb] Write Protect is off [ 160.593057] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 160.593483] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported #
Notes: Last week, before I did the defender scan that windows recommended, I did get a few files off the stick. I got all that I tried. I did not try most. Between doing fdisk (late last Friday) and "What happened to the partition?" (this afternoon) I tried to see if windows sees the stick. As far as I know, I did nothing that would have windows write to the stick. But might it have written to the stick without us knowing?
Breaking news?... Looking at last Friday's posts again, I see that you had me try fdisk, which I did do on Friday. That hasn't been tried today. Is that what produced output suggesting some sort of a partition on the stick? I just tried it again. The results:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 159.545514] usb-storage 3-1:1.0: USB Mass Storage device detected [ 159.545897] scsi host10: usb-storage 3-1:1.0 [ 160.560274] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 160.560711] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 160.592625] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 160.593048] sd 10:0:0:0: [sdb] Write Protect is off [ 160.593057] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 160.593483] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported #
Does that change the picture?
That looks to me like the whole stick is the partition. Have you tried mounting /dev/sdb ?
On 5/5/25 9:29 PM, Mike Wright wrote:
On 5/5/25 20:18, home user via users wrote:
[... snip ...]
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 159.545514] usb-storage 3-1:1.0: USB Mass Storage device detected [ 159.545897] scsi host10: usb-storage 3-1:1.0 [ 160.560274] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 160.560711] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 160.592625] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 160.593048] sd 10:0:0:0: [sdb] Write Protect is off [ 160.593057] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 160.593483] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported #
Does that change the picture?
That looks to me like the whole stick is the partition. Have you tried mounting /dev/sdb ?
Trying now:
# mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 160.604790] sd 10:0:0:0: [sdb] Attached SCSI removable disk [ 186.582746] evm: overlay not supported [ 2376.951230] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 2376.952072] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 2376.952564] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 2377.059210] ISOFS: Unable to identify CD-ROM format. [ 2377.060026] FAT-fs (sdb): invalid media value (0xb9) [ 2377.060034] FAT-fs (sdb): Can't find a valid FAT filesystem [ 2377.085793] hfs: can't find a HFS filesystem on dev sdb [ 2377.120959] hfsplus: unable to find HFS+ superblock #
On 5/5/25 8:18 PM, home user via users wrote:
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA)
I'm getting an idea of what might be going on, which does mostly assume it's a fake drive. Somehow gpart doing its scan triggers the partition table to be available. fdisk can see it because it directly reads the disk, but the OS doesn't know about the partition.
Don't remove the drive if it's still in.
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
On 5/5/25 10:15 PM, Samuel Sieb wrote:
On 5/5/25 8:18 PM, home user via users wrote:
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA)
I'm getting an idea of what might be going on, which does mostly assume it's a fake drive. Somehow gpart doing its scan triggers the partition table to be available. fdisk can see it because it directly reads the disk, but the OS doesn't know about the partition.
Don't remove the drive if it's still in.
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
I shut down for the night about a half an hour before you posted the above.
Note: For several months, whenever I put something on this stick, I checked it by running diff to compare what's on the stick with the hard drive source of the copy. I don't know if that affects the suspicion that the stick is a "fake drive".
Here's the output so far:
# gpart /dev/sdb
Begin scan... Possible partition(DOS FAT), size(14782mb), offset(3mb) End scan.
Checking partitions... Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary Ok.
Guessed primary partition table: Primary partition(1) type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA) size: 14782mb #s(30274944) s(8064-30283007) chs: (3/60/1)-(1023/63/32)d (3/60/1)-(14786/39/32)r
Primary partition(2) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4) type: 000(0x00)(unused) size: 0mb #s(0) s(0-0) chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
Questions: I have "partprobe"; I've read the man page. 1. What options (if any) do you want? 2. What goes in the [devices...] field?
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote:
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote:
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 646.042339] hfsplus: unable to find HFS+ superblock [ 5663.808861] sdb: sdb1 [ 5693.551417] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 5693.552043] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 5693.552537] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 5693.572912] ISOFS: Unable to identify CD-ROM format. [ 5693.573614] FAT-fs (sdb): invalid media value (0xb9) [ 5693.573622] FAT-fs (sdb): Can't find a valid FAT filesystem [ 5693.574649] hfs: can't find a HFS filesystem on dev sdb [ 5693.575167] hfsplus: unable to find HFS+ superblock #
On 5/6/25 5:07 PM, home user via users wrote:
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote:
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
mount /dev/sdb1 /mnt
On 5/6/25 6:09 PM, Samuel Sieb wrote:
On 5/6/25 5:07 PM, home user via users wrote:
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote:
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
mount /dev/sdb1 /mnt
# mount /dev/sdb1 /mnt # #
It does not show up in the gnome file browser. (should it?)
On 5/6/25 5:13 PM, home user via users wrote:
On 5/6/25 6:09 PM, Samuel Sieb wrote:
On 5/6/25 5:07 PM, home user via users wrote:
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote:
Try "fdisk -l /dev/sdb". If it doesn't show the partition table, then try "gpart /dev/sdb", then try "fdisk -l /dev/sdb" again. If it shows the partition table, then run "partprobe". If that's not available, then install "parted". Then try the mount.
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
mount /dev/sdb1 /mnt
# mount /dev/sdb1 /mnt # #
It does not show up in the gnome file browser. (should it?)
No errors? That's a really good sign! Anything interesting in "dmesg | tail"?
It won't pop up anywhere. Just go to /mnt. You can click on the folder name at the top of the window and type that in.
On 5/6/25 6:16 PM, Samuel Sieb wrote:
On 5/6/25 5:13 PM, home user via users wrote:
On 5/6/25 6:09 PM, Samuel Sieb wrote:
On 5/6/25 5:07 PM, home user via users wrote:
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote:
On 5/5/25 10:15 PM, Samuel Sieb wrote: > Try "fdisk -l /dev/sdb". > If it doesn't show the partition table, then try "gpart /dev/ > sdb", then try "fdisk -l /dev/sdb" again. > If it shows the partition table, then run "partprobe". If that's > not available, then install "parted". > Then try the mount. > # fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) #
Question: What counts (or doesn't count) as a "partition table" in the fdisk output?
It lists the partition.
Questions: I have "partprobe"; I've read the man page.
- What options (if any) do you want?
- What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
mount /dev/sdb1 /mnt
# mount /dev/sdb1 /mnt # #
It does not show up in the gnome file browser. (should it?)
No errors? That's a really good sign! Anything interesting in "dmesg | tail"?
# dmesg | tail [ 5693.575167] hfsplus: unable to find HFS+ superblock [ 6050.451123] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.451964] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.452424] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.473075] ISOFS: Unable to identify CD-ROM format. [ 6050.473745] FAT-fs (sdb): invalid media value (0xb9) [ 6050.473752] FAT-fs (sdb): Can't find a valid FAT filesystem [ 6050.474356] hfs: can't find a HFS filesystem on dev sdb [ 6050.474952] hfsplus: unable to find HFS+ superblock [ 6240.393795] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. #
It won't pop up anywhere. Just go to /mnt. You can click on the folder name at the top of the window and type that in.
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
On 5/6/25 5:31 PM, home user via users wrote:
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
ddrescue is more for failing physical media. testdisk might help.
On 5/6/25 6:37 PM, Samuel Sieb wrote:
On 5/6/25 5:31 PM, home user via users wrote:
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
ddrescue is more for failing physical media. testdisk might help.
I read through some stuff on that a few days ago, but I could not figure out out to properly use testdisk in this situation.
I really need to be coached through this. ... or are there more steps to do before doing testdisk?
On 5/6/25 6:31 PM, home user via users wrote:
On 5/6/25 6:16 PM, Samuel Sieb wrote:
On 5/6/25 5:13 PM, home user via users wrote:
On 5/6/25 6:09 PM, Samuel Sieb wrote:
On 5/6/25 5:07 PM, home user via users wrote:
On 5/6/25 5:31 PM, Samuel Sieb wrote:
On 5/6/25 3:57 PM, home user via users wrote: > On 5/5/25 10:15 PM, Samuel Sieb wrote: >> Try "fdisk -l /dev/sdb". >> If it doesn't show the partition table, then try "gpart /dev/ >> sdb", then try "fdisk -l /dev/sdb" again. >> If it shows the partition table, then run "partprobe". If >> that's not available, then install "parted". >> Then try the mount. >> > # fdisk -l /dev/sdb > Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors > Disk model: > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x5c3b37be > > Device Boot Start End Sectors Size Id Type > /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) > # > > Question: > What counts (or doesn't count) as a "partition table" in the > fdisk output?
It lists the partition.
> Questions: > I have "partprobe"; I've read the man page. > 1. What options (if any) do you want? > 2. What goes in the [devices...] field?
Oh, I missed that. I meant to say run "partprobe /dev/sdb".
# partprobe /dev/sdb # mount /dev/sdb /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
mount /dev/sdb1 /mnt
# mount /dev/sdb1 /mnt # #
It does not show up in the gnome file browser. (should it?)
No errors? That's a really good sign! Anything interesting in "dmesg | tail"?
# dmesg | tail [ 5693.575167] hfsplus: unable to find HFS+ superblock [ 6050.451123] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.451964] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.452424] EXT4-fs (sdb): VFS: Can't find ext4 filesystem [ 6050.473075] ISOFS: Unable to identify CD-ROM format. [ 6050.473745] FAT-fs (sdb): invalid media value (0xb9) [ 6050.473752] FAT-fs (sdb): Can't find a valid FAT filesystem [ 6050.474356] hfs: can't find a HFS filesystem on dev sdb [ 6050.474952] hfsplus: unable to find HFS+ superblock [ 6240.393795] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. #
It won't pop up anywhere. Just go to /mnt. You can click on the folder name at the top of the window and type that in.
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
The stick has a LED in it. It is currently flashing rapidly and continuously. Is there something that I should do? ... or is that not a problem?
On 5/6/25 5:38 PM, home user via users wrote:
On 5/6/25 6:31 PM, home user via users wrote:
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
The stick has a LED in it. It is currently flashing rapidly and continuously. Is there something that I should do? ... or is that not a problem?
That depends on the stick. Some flash all the time, some only when active. That does sound like it's probably active. Anything more in dmesg?
On 5/6/25 6:45 PM, Samuel Sieb wrote:
On 5/6/25 5:38 PM, home user via users wrote:
On 5/6/25 6:31 PM, home user via users wrote:
More progress. Doing that brings up some files and one directory. There should be multiple directories. If I try to look at the properties of that directory, it says "contents unreadable", and under that, "Unknown". I tried opening 2 JPG files; they could not be opened. I tried opening one text file; it could not be opened.
Is ddrescue and/or testdisk likely to help?
The stick has a LED in it. It is currently flashing rapidly and continuously. Is there something that I should do? ... or is that not a problem?
That depends on the stick. Some flash all the time, some only when active. That does sound like it's probably active. Anything more in dmesg?
# dmesg | tail [ 7496.462621] FAT-fs (sdb1): Directory bread(block 24936) failed [ 7496.462628] FAT-fs (sdb1): Directory bread(block 24937) failed [ 7496.462631] FAT-fs (sdb1): Directory bread(block 24938) failed [ 7496.462633] FAT-fs (sdb1): Directory bread(block 24939) failed [ 7496.462636] FAT-fs (sdb1): Directory bread(block 24940) failed [ 7496.462638] FAT-fs (sdb1): Directory bread(block 24941) failed [ 7496.462640] FAT-fs (sdb1): Directory bread(block 24942) failed [ 7496.462642] FAT-fs (sdb1): Directory bread(block 24943) failed [ 7496.462644] FAT-fs (sdb1): Directory bread(block 24944) failed [ 7496.462648] FAT-fs (sdb1): Directory bread(block 24945) failed #
It is a "MICRO CENTER" stick, probably bought in a Microcenter store in Rockville, Maryland at least 10 years ago.
It does not always flash.
On Tue, May 6, 2025 at 9:49 PM home user via users < users@lists.fedoraproject.org> wrote:
[...] It is a "MICRO CENTER" stick, probably bought in a Microcenter store in Rockville, Maryland at least 10 years ago.
It does not always flash.
Good news: fake USB drives were rare 10 years ago. Most claim much higher capacity than 14 GB.
Bad news: USB flash drives have a limited lifetime. I suspect your drive has failed. You might be able to recover some data with ddrescue. You should avoid writing on the drive as it may just do more damage.
On 7 May 2025 at 9:35, George N. White III wrote:
From: "George N. White III" gnwiii@gmail.com Date sent: Wed, 7 May 2025 09:35:10 -0300 Subject: Re: recovering back-up. To: Community support for Fedora users users@lists.fedoraproject.org Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On Tue, May 6, 2025 at 9:49 PM home user via users users@lists.fedoraproject.org wrote: [...] It is a "MICRO CENTER" stick, probably bought in a Microcenter store in Rockville, Maryland at least 10 years ago.
It does not always flash.
Good news: fake USB drives were rare 10 years ago. Most claim much higher capacity than 14 GB.
Bad news: USB flash drives have a limited lifetime. I suspect your drive has failed. You might be able to recover some data with ddrescue. You should avoid writing on the drive as it may just do more damage.
Just to note there is a tool to check for fake USB and test USB drives.
The latest version from Fedora Repo is f3-8.0-8.fc41.x86_64
There is a newer version on https://github.com/AltraMayor/f3 Link to download latest https://github.com/AltraMayor/f3/zipball/master
Change log show Version 9.0 - Mar 27, 2025
* f3read/f3write: Avoid the execution stack to list files * f3read/f3write: Add dynamic buffers * f3read/f3write: chroot(2) to source/target dir if allowed * Portability improvements for Ubuntu, ARM, OpenBSD, and Apple * Automated test of the code with GitHub Actions * Improved documentation
Version 8.0 - Oct 29, 2020
* f3read: add parameter --max-read-rate * f3read: report speed, percentage, remaining time like f3write * f3write: improve speed measurement (commit 791acdc32627...) * f3probe: handle rare assertion failure (issue #82 ENODATA)
The files it includes are f3brew f3fix f3probe f3read f3write
Have found it useful for testing USB devices. It finds fake devices, and can try to correct to real size, which is usually very small. Generally, just throw away fake USBs.
Good Luck.
-- George N. White III
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com mailto:msetzerii@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 5/7/25 8:19 AM, Michael D. Setzer II via users wrote:
On 7 May 2025 at 9:35, George N. White III wrote:
Just to note there is a tool to check for fake USB and test USB drives.
The latest version from Fedora Repo is f3-8.0-8.fc41.x86_64
There is a newer version on https://github.com/AltraMayor/f3 Link to download latest https://github.com/AltraMayor/f3/zipball/master
Change log show Version 9.0 - Mar 27, 2025
* f3read/f3write: Avoid the execution stack to list files * f3read/f3write: Add dynamic buffers * f3read/f3write: chroot(2) to source/target dir if allowed * Portability improvements for Ubuntu, ARM, OpenBSD, andApple * Automated test of the code with GitHub Actions * Improved documentation
Version 8.0 - Oct 29, 2020
* f3read: add parameter --max-read-rate * f3read: report speed, percentage, remaining time like f3write * f3write: improve speed measurement (commit 791acdc32627...) * f3probe: handle rare assertion failure (issue #82 ENODATA)The files it includes are f3brew f3fix f3probe f3read f3write
Have found it useful for testing USB devices. It finds fake devices, and can try to correct to real size, which is usually very small. Generally, just throw away fake USBs.
Good Luck.
I've used this on every stick I've bought since I learned about f3 from this list 1 or 2 years ago. I agree: it's useful. But it is not useful for the problem this thread is trying to address. f3probe writes to the stick being tested. That will destroy what I'm trying to recover.
On 5/7/25 6:35 AM, George N. White III wrote:
On Tue, May 6, 2025 at 9:49 PM home user via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
[...] It is a "MICRO CENTER" stick, probably bought in a Microcenter store in Rockville, Maryland at least 10 years ago. It does not always flash.Good news: fake USB drives were rare 10 years ago. Most claim much higher capacity than 14 GB.
Bad news: USB flash drives have a limited lifetime. I suspect your drive has failed. You might be able to recover some data with ddrescue. You should avoid writing on the drive as it may just do more damage.
It makes sense to me to not write to the stick I'm trying to recover data from. If I have done anything that changed the stick, it was unknowingly.
So I have people saying I should use ddrescue, and people saying I should use testdisk. Please come to an agreement on how to best recover what I can from my stick of back-ups!
I've read the man pages for both testdisk and ddrescue. They're skimpy, ok for experienced users but not adequate for a first-timer at this, especially as I'm not an IT professional. I've also looked at other on-line material for both commands, including what Tim referred me to. Better, but still not enough. I also saw somewhere that dd by itself should not be used, it either misses something or generates some extra stuff.
If it matters, the stick was not bootable.
What's the next step?
On Wed, May 7, 2025 at 7:59 PM home user via users < users@lists.fedoraproject.org> wrote:
On 5/7/25 6:35 AM, George N. White III wrote:
On Tue, May 6, 2025 at 9:49 PM home user via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
[...] So I have people saying I should use ddrescue, and people saying I should use testdisk. Please come to an agreement on how to best recover what I can from my stick of back-ups!
ddrescue is used to get the best possible copy of the contents. Typically this is used to create a disk image file. Testdisk is used to examine the contents of a disk or image file in the hope of recreating the missing or damaged structure or locating blocks of data for an important file.
See: https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step for examples.
On 5/8/2025 5:32 AM, George N. White III wrote:
On Wed, May 7, 2025 at 7:59 PM home user via users users@lists.fedoraproject.org wrote:
On 5/7/25 6:35 AM, George N. White III wrote: > On Tue, May 6, 2025 at 9:49 PM home user via users > <users@lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>> > wrote: [...] So I have people saying I should use ddrescue, and people saying I should use testdisk. Please come to an agreement on how to best recover what I can from my stick of back-ups!ddrescue is used to get the best possible copy of the contents. Typically this is used to create a disk image file. Testdisk is used to examine the contents of a disk or image file in the hope of recreating the missing or damaged structure or locating blocks of data for an important file.
See: https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step for examples.
I did see this. I've been busy trying to catch up on outdoor work, and could not get to this properly today. I did give that web page a skim. It definitely looks better than the testdisk man page. I will give it a good read next week, when I'm adequately close to caught up outdoors.
On 5/5/25 6:31 PM, Samuel Sieb wrote:
On 5/5/25 5:08 PM, home user via users wrote:
On 5/5/25 5:41 PM, Samuel Sieb wrote:
On 5/5/25 3:55 PM, home user via users wrote:
Here's a mount attempt:
# fdisk -l /dev/sdb Disk /dev/sdb: 14.44 GiB, 15504900096 bytes, 30283008 sectors Disk model: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5c3b37be
Device Boot Start End Sectors Size Id Type /dev/sdb1 8064 30283007 30274944 14.4G c W95 FAT32 (LBA) # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call.
Try the following:
lsblk -f /dev/sdb mount /dev/sdb1 /mnt dmesg | tail
# lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb # mount /dev/sdb1 /mnt mount: /mnt: fsconfig system call failed: /dev/sdb1: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # dmesg | tail [ 3959.234522] usb 3-2: SerialNumber: 070735D7CBE2C554 [ 3959.235427] usb-storage 3-2:1.0: USB Mass Storage device detected [ 3959.235777] scsi host10: usb-storage 3-2:1.0 [ 3960.292550] scsi 10:0:0:0: Direct-Access PMAP PQ: 0 ANSI: 6 [ 3960.293059] sd 10:0:0:0: Attached scsi generic sg3 type 0 [ 3960.343345] sd 10:0:0:0: [sdb] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 3960.343761] sd 10:0:0:0: [sdb] Write Protect is off [ 3960.343770] sd 10:0:0:0: [sdb] Mode Sense: 45 00 00 00 [ 3960.344185] sd 10:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3960.355980] sd 10:0:0:0: [sdb] Attached SCSI removable disk
What happened to the partition? Run "journalctl -fa" in a terminal and try plugging it in again. You should see a line like: "kernel: sdb: sdb1" It might be a letter other than "b", so adjust all commands if it is different. If you don't get that partition list, then try running: dd if=/dev/sdb of=/dev/null bs=1M status=progress Let it run for a while. If it doesn't give an error, you can stop it with CTRL-C.
If you do get the partition list, then try that set of commands again.
Here's the dd run:
# dd if=/dev/sdb of=/dev/null bs=1M status=progress 15504900096 bytes (16 GB, 14 GiB) copied, 196 s, 79.1 MB/s 14786+1 records in 14786+1 records out 15504900096 bytes (16 GB, 14 GiB) copied, 196.851 s, 78.8 MB/s #
In case we're heading towards copying the stick to the hard drive, this shows what space is available:
# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 1951850496 6936968 1943250264 1% / devtmpfs 4096 0 4096 0% /dev tmpfs 8023320 92 8023228 1% /dev/shm efivarfs 128 83 41 68% /sys/firmware/efi/efivars tmpfs 3209328 1856 3207472 1% /run tmpfs 1024 0 1024 0% /run/credentials/systemd-journald.service tmpfs 8023320 16 8023304 1% /tmp /dev/sda3 1951850496 6936968 1943250264 1% /home /dev/sda2 996780 379236 548732 41% /boot /dev/sda1 613160 19740 593420 4% /boot/efi tmpfs 1024 0 1024 0% /run/credentials/systemd-resolved.service tmpfs 1604664 188 1604476 1% /run/user/0 #
On Mon, May 5, 2025 at 7:41 PM Samuel Sieb samuel@sieb.net wrote:
[...] mount /dev/sdb1 /mnt [...]
Unless you are already root that probably should be "sudo mount /dev/sdb1 /mnt"
On 5/5/25 6:27 PM, Go Canes wrote:
On Mon, May 5, 2025 at 7:41 PM Samuel Sieb samuel@sieb.net wrote:
[...] mount /dev/sdb1 /mnt [...]
Unless you are already root that probably should be "sudo mount /dev/sdb1 /mnt"
I'm already root.
On Thu, 2025-05-01 at 21:12 -0600, home user via users wrote:
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick.
Too late now, but never consider a USB stick as a back-up. It's flakey technology. I only use them as sneakernet tech.
I don't know if "dd" can be used to try to duplicate a failed drive over to something else to safely experiment on a rescue. There is a "ddrescue" tool with that kind of thing in mind.
On 5/1/25 10:48 PM, Tim wrote:
On Thu, 2025-05-01 at 21:12 -0600, home user via users wrote:
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick.
Too late now, but never consider a USB stick as a back-up. It's flakey technology. I only use them as sneakernet tech.
I don't know if "dd" can be used to try to duplicate a failed drive over to something else to safely experiment on a rescue. There is a "ddrescue" tool with that kind of thing in mind.
Having looked at the man page, I couldn't make sense of how I should use these for this situation.
By the way, the stick was not bootable; it's 16GB.
Tim:
There is a "ddrescue" tool with that kind of thing in mind.
home user
Having looked at the man page, I couldn't make sense of how I should use these for this situation.
See if this page is any different from what you've read, then try discussing things with people here:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
I don't think I've ever used *it*, though.
I do remember using some recovery tools, long ago, for some drive that Windows mangled. The problem with data recovery is that often you can only get partial remains from each file. Which may be good enough for recovering important bits of some text, but not for direct use of existing files.
If you want to attempt to recover from a drive failure (of any kind), it's important that all subsequent accesses are read-only. Don't let anything write anything to the drive, that includes new meta data about when files were accessed.
There's different approaches to recovering data from a drive with drive failures as opposed to the computer stuffing it up.
If the drive is failing, then repeatedly trying to read it until you recover something is a common approach, bearing in mind that doing *that* can cause worsening of the failure.
If you're recovering from a stuff-up, and you presume the drive is fine but you just want to recover data from it. In that case using dd to do a direct dump of all the bits to another drive, then attacking that copy with recovery tools *may* be the way to go (though doing this with a big drive is difficult). The dump is going to make a clone, a copy made now should be the same as one made ten minute later, so there's no point in repeatedly trying to read a non-failed drive to get better results, and you don't risk anything going wrong with the original drive.
Seeing as you said just plugging it into a Windows box but not letting Windows do it's "format the drive it doesn't recognise" routine was enough to kill it does kind of suggest the drive may be faulty.
On 3 May 2025 at 17:20, Tim via users wrote:
Subject: Re: recovering back-up. To: Community support for Fedora users users@lists.fedoraproject.org Date sent: Sat, 03 May 2025 17:20:54 +0930 Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Tim via users users@lists.fedoraproject.org Copies to: home user mattisonw@comcast.net, Tim ignored_mailbox@yahoo.com.au
Tim:
There is a "ddrescue" tool with that kind of thing in mind.
https://www.cgsecurity.org/wiki/TestDisk
TestDisk is another program that can look for partitions on disk. testdisk-7.2-2.fc41.x86_64 Is the version I have installed on my Fedora 41.
Include both ddrescue and testdisk as part of my G4L project, but only used them a few times.
ddrescue-1.28-2.fc41.x86_64
Had a few times where windows would not recognize partitions that Linux would have no problem seeing.
What did you use to make the backup??
home user
Having looked at the man page, I couldn't make sense of how I should use these for this situation.
See if this page is any different from what you've read, then try discussing things with people here:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
I don't think I've ever used *it*, though.
I do remember using some recovery tools, long ago, for some drive that Windows mangled. The problem with data recovery is that often you can only get partial remains from each file. Which may be good enough for recovering important bits of some text, but not for direct use of existing files.
If you want to attempt to recover from a drive failure (of any kind), it's important that all subsequent accesses are read-only. Don't let anything write anything to the drive, that includes new meta data about when files were accessed.
There's different approaches to recovering data from a drive with drive failures as opposed to the computer stuffing it up.
If the drive is failing, then repeatedly trying to read it until you recover something is a common approach, bearing in mind that doing *that* can cause worsening of the failure.
If you're recovering from a stuff-up, and you presume the drive is fine but you just want to recover data from it. In that case using dd to do a direct dump of all the bits to another drive, then attacking that copy with recovery tools *may* be the way to go (though doing this with a big drive is difficult). The dump is going to make a clone, a copy made now should be the same as one made ten minute later, so there's no point in repeatedly trying to read a non-failed drive to get better results, and you don't risk anything going wrong with the original drive.
Seeing as you said just plugging it into a Windows box but not letting Windows do it's "format the drive it doesn't recognise" routine was enough to kill it does kind of suggest the drive may be faulty.
--
uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com mailto:msetzerii@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 5/3/2025 3:17 AM, Michael D. Setzer II via users wrote:
On 3 May 2025 at 17:20, Tim via users wrote:
Subject: Re: recovering back-up. To: Community support for Fedora users users@lists.fedoraproject.org Date sent: Sat, 03 May 2025 17:20:54 +0930 Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Tim via users users@lists.fedoraproject.org Copies to: home user mattisonw@comcast.net, Tim ignored_mailbox@yahoo.com.au
Tim:
There is a "ddrescue" tool with that kind of thing in mind.
https://www.cgsecurity.org/wiki/TestDisk
TestDisk is another program that can look for partitions on disk. testdisk-7.2-2.fc41.x86_64 Is the version I have installed on my Fedora 41.
See my second post to this thread. No one has responded to the results I put in that post.
Include both ddrescue and testdisk as part of my G4L project, but only used them a few times.
ddrescue-1.28-2.fc41.x86_64
Had a few times where windows would not recognize partitions that Linux would have no problem seeing.
What did you use to make the backup??
I spelled that out in my third post to this list (mainly a reponse to the same question from Samuel).
On 2 May 2025, at 04:12, home user via users users@lists.fedoraproject.org wrote:
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
If the files are in your /home you can do a fresh install on f42 and tell it to use the existing /home.
If you boot a Fedora UDB live image you can mount your backup USB in that environment and network copy the files you need to the Windows machine.
Barry
On 5/2/25 3:14 AM, Barry Scott wrote:
On 2 May 2025, at 04:12, home user via users users@lists.fedoraproject.org wrote:
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
If the files are in your /home you can do a fresh install on f42 and tell it to use the existing /home.
If you boot a Fedora UDB live image you can mount your backup USB in that environment and network copy the files you need to the Windows machine.
Barry
The install (2 weeks ago now) was tried 3 times. First, the windows-7 partition was reduced about 100 GB. Then...... 1. I wanted to re-install on a dual-boot system. But that killed the partition in which /home was located, I'm guessing by in part converting all Linux partitions to btrfs. 2. I tried installing on the dual-boot system. If I remember correctly, it couldn't find enough space, though there was about 1 TB available. Then a local friend gave me the windows-10 box. So then.... 3. I had no choice left but to try a total new install; no more dual-boot. That's what I have now.
So the files that were on the hard drive are gone. The partition they were in is gone. Everything, both in Fedora and windows seems to be saying the stick is empty and un-formatted.
On 5/1/25 9:12 PM, home user via users wrote:
(F-42; stand-alone workstation; Gnome)
snip
But now when I insert the back-up stick into a port on either tower, it's claimed the back-up stick is un-formatted and empty. Fedora's "disks" and windows-10 (file browser and defender) agree. I do not recall which file system the back-up stick was formatted with beforehand.
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
Before trying what y'all suggested overnight... Just after my original post, before shutting down for the night, I tried "testdisk". The log file is almost 41 thousand lines long. I included the first and last parts below the body of this post. This program is time-consuming. I recovered nothing. Questions: * Is it worth trying this again with different "number of heads/cylinder" and/or "number of sectors per track"? * Is it worth trying this again using the non-partitioned option?
= = = = = = = = = = = = = = =
Thu May 1 21:44:00 2025 Command line: TestDisk
TestDisk 7.2, Data Recovery Utility, February 2024 Christophe GRENIER grenier@cgsecurity.org https://www.cgsecurity.org OS: Linux, kernel 6.14.3-300.fc42.x86_64 (#1 SMP PREEMPT_DYNAMIC Sun Apr 20 16:08:39 UTC 2025) x86_64 Compiler: GCC 15.0 ext2fs lib: 1.47.2, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: 20140608, curses lib: ncurses 6.5 /dev/sda: LBA, HPA, LBA48, DCO support /dev/sda: size 3907029168 sectors /dev/sda: user_max 3907029168 sectors /dev/sda: native_max 3907029168 sectors Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512 Hard disk list Disk /dev/sda - 2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512 - ST2000DM006-2DM1, FW:CC26 Disk /dev/sdb - 15 GB / 14 GiB - CHS 14786 64 32, sector size=512 - Phison USB DISK 50X, FW:PMAP
Partition table type (auto): Intel Disk /dev/sdb - 15 GB / 14 GiB - Phison USB DISK 50X Partition table type: Intel
Analyse Disk /dev/sdb - 15 GB / 14 GiB - CHS 14786 64 32 Geometry from i386 MBR: head=43 sector=43 BAD_RS LBA=8064 2048 FAT32 at 3/60/1 Info: size boot_sector 30274944, partition 30274944 FAT1 : 10144-17535 FAT2 : 17536-24927 start_rootdir : 24928 root cluster : 2 Data : 24928-30274943 sectors : 30274944 cluster_size : 32 no_of_cluster : 945313 (2 - 945314) fat_length 7392 calculated 7386 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) Current partition structure: Warning: number of heads/cylinder mismatches 128 (FAT) != 64 (HD) Warning: number of sectors per track mismatches 63 (FAT) != 32 (HD) 1 P FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK]
Warning: Bad ending sector (CHS and LBA don't match) No partition is bootable
search_part() Disk /dev/sdb - 15 GB / 14 GiB - CHS 14786 64 32 FAT32 at 3/60/1 FAT1 : 10144-17535 FAT2 : 17536-24927 start_rootdir : 24928 root cluster : 2 Data : 24928-30274943 sectors : 30274944 cluster_size : 32 no_of_cluster : 945313 (2 - 945314) fat_length 7392 calculated 7386 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD)
FAT32 at 3/60/1 FAT: cluster=2(0x2), pos=32992 FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB Warning: the current number of heads per cylinder is 64 but the correct value may be 255.
Results L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB
Hint for advanced users: dmsetup may be used if you prefer to avoid rewriting the partition table for the moment: echo "0 30274944 linear /dev/sdb 8064" | dmsetup create test0 add_ext_part_i386: max add_ext_part_i386: min
interface_write() 1 E extended LBA 3 0 1 14786 39 32 30276864 5 L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK]
search_part() Disk /dev/sdb - 15 GB / 14 GiB - CHS 14786 64 32 FAT32 at 3/60/1 FAT1 : 10144-17535 FAT2 : 17536-24927 start_rootdir : 24928 root cluster : 2 Data : 24928-30274943 sectors : 30274944 cluster_size : 32 no_of_cluster : 945313 (2 - 945314) fat_length 7392 calculated 7386 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD)
FAT32 at 3/60/1 FAT: cluster=2(0x2), pos=32992 FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB BAD_RS LBA=1064832 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) BAD_RS LBA=2121600 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) BAD_RS LBA=3178368 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) BAD_RS LBA=4235136 2048 [... snip ...] BAD_RS LBA=22200192 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) BAD_RS LBA=23256960 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) BAD_RS LBA=24313728 2048 heads/cylinder 128 (FAT) != 64 (HD) sect/track 63 (FAT) != 32 (HD) file_pread(5,16,buffer,25378942(12392/3/31)) read err: Input/output error file_pread(5,1,buffer,25378942(12392/3/31)) read err: Input/output error file_pread(5,2,buffer,25380864(12393/0/1)) read err: Input/output error [... snip ...] file_pread(5,11,buffer,30281918(14786/5/31)) read err: read after end of file file_pread(5,8,buffer,30282752(14786/32/1)) read err: read after end of file file_pread(5,8,buffer,30282880(14786/36/1)) read err: read after end of file Warning: the current number of heads per cylinder is 64 but the correct value may be 255.
Results L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB
Hint for advanced users: dmsetup may be used if you prefer to avoid rewriting the partition table for the moment: echo "0 30274944 linear /dev/sdb 8064" | dmsetup create test0 file_pread(5,1,buffer,8064(3/60/1)) read err: read after end of file Can't read FAT boot sector. Can't read FAT boot sector.
L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB Can't open filesystem. Filesystem seems damaged. Can't read FAT boot sector. Can't read FAT boot sector.
L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] FAT32, blocksize=16384, 15 GB / 14 GiB Can't open filesystem. Filesystem seems damaged. add_ext_part_i386: max add_ext_part_i386: min
interface_write() 1 E extended LBA 3 0 1 14786 39 32 30276864 5 L FAT32 LBA 3 60 1 14786 39 32 30274944 [USB DISK] simulate write!
write_mbr_i386: starting... file_pread(5,1,buffer,0(0/0/1)) read err: read after end of file
Partition: Read error Store new MBR code write_all_log_i386: starting... write_all_log_i386: CHS: 3/0/1,lba=6144 file_pread(5,1,buffer,6144(3/0/1)) read err: read after end of file
TestDisk exited normally.
= = = = = = = = = = = = = = =
On 5/1/2025 9:12 PM, home user via users wrote:
(F-42; stand-alone workstation; Gnome)
Just before trying to upgrade from F-40 to F-41, I did a back-up to a USB 3 stick. The upgrade failed. A local friend gave me a windows-10 box to use. Until I could get the Fedora workstation adequately restored, I needed to get a few things off the F-40 back-up onto the windows-10 box. Attempts to re-install Fedora from Fedora-42 Live Workstation appear to have completely destroyed the partitioning of the hard drive. When I inserted the back-up stick into the port, windows-10 told me to use defender to scan the stick. I did so. I asked for a scan only. I did not want defender to attempt any repair or other changes. Defender reported no problems. But now when I insert the back-up stick into a port on either tower, it's claimed the back-up stick is un-formatted and empty. Fedora's "disks" and windows-10 (file browser and defender) agree. I do not recall which file system the back-up stick was formatted with beforehand.
How can I recover the back-up (without cost)? Note that I'm needing to recover the back-up as a whole, not just a file or 2 from a back-up.
This hit at a v-e-r-y bad time in multiple ways. This and other things, like f-42 "anaconda", proved c-r-u-s-h-i-n-g, both to my hard drive and to my brain. I had to seek off-line help. The first key piece came from a long-time friend who's been an IT professional for many years, and is better and a lot more current than me. It took him a while, but he gave me the "ddrescue" command that got the USB stick's contents into an "img" file on my hard drive. This was the command: ddrescue -f -n /dev/sdb backup0624.img The text search functionality of the "bless" hex editor enabled me to establish that the contents of at least some files were still intact. I then turned to a list member off-line. The img file was gzipped and uploaded to the google drive. The other person downloaded it from there. He tells me that to recover things, he "just mounted it and used "tar"". Almost everything was recovered. Only the contents of the last 2 back-ups - just a few files - were lost. I'm also told "There was nothing physically wrong with the drive".
I thank all who tried to help. I've tagged this thread SOLVED.
-
Barry Scott -
George N. White III -
Go Canes -
home user -
Michael D. Setzer II -
Mike Wright -
Samuel Sieb -
Tim