Posted: Mon 04 Mar 2013, 10:47
Are you saying it wasn't pulled between the write and the fdisk remount? My thoughts are still here.
READ-ONLY Archive
https://oldforum.puppylinux.com/
You are correct. The partition table isn't getting written.Sylvander wrote:I read that as a FAILURE to delete.
Am I correct?
Code: Select all
dmesg | tail -30 | grep -A 30 usb
Code: Select all
# dmesg | tail -30 | grep -A 30 usb
[ 1179.925574] usb 1-1.1: USB disconnect, device number 3
[ 1185.481062] usb 1-1.1: new high-speed USB device number 4 using ehci_hcd
[ 1185.567446] usb 1-1.1: New USB device found, idVendor=0a16, idProduct=2004
[ 1185.567450] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1185.567453] usb 1-1.1: Product: Store 'n' Go
[ 1185.567455] usb 1-1.1: Manufacturer: Verbatim
[ 1185.567457] usb 1-1.1: SerialNumber: de656f60c080aa
[ 1185.567752] scsi5 : usb-storage 1-1.1:1.0
[ 1186.570999] scsi 5:0:0:0: Direct-Access Verbatim Store 'n' Go 1.00 PQ: 0 ANSI: 2
[ 1186.572241] sd 5:0:0:0: [sdb] 1974271 512-byte logical blocks: (1.01 GB/963 MiB)
[ 1186.573220] sd 5:0:0:0: [sdb] Write Protect is off
[ 1186.573225] sd 5:0:0:0: [sdb] Mode Sense: 00 00 00 00
[ 1186.574202] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.574205] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.579315] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.579319] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.689749] sdb: sdb1
[ 1186.693315] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.693318] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.693321] sd 5:0:0:0: [sdb] Attached SCSI removable disk
#
Code: Select all
dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
Code: Select all
dd if=/dev/sdb1 bs=256 skip=0 count=1 2>/dev/null | hexdump -C
Code: Select all
fdisk -l /dev/sdb
Code: Select all
dd if=/dev/sdb1 bs=1 skip=3 count=4 2>/dev/null | hexdump -C
Code: Select all
echo -n test | dd of=/dev/sdb1 bs=1 seek=3 count=4
Code: Select all
dd if=/dev/sdb1 bs=1 skip=3 count=4 2>/dev/null | hexdump -C
Code: Select all
# dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100
# dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100
#
Code: Select all
# fdisk -l /dev/sdb
Disk /dev/sdb: 1010 MB, 1010826752 bytes
196 heads, 9 sectors/track, 1119 cylinders, total 1974271 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009dcf9
Device Boot Start End Blocks Id System
/dev/sdb1 2048 1972223 985088 b W95 FAT32
# dd if=/dev/sdb1 bs=1 skip=3 count=4 2>/dev/null | hexdump -C
*
# echo -n test | dd of=/dev/sdb1 bs=1 seek=3 count=4
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.00296508 s, 1.3 kB/s
# dd if=/dev/sdb1 bs=1 skip=3 count=4 2>/dev/null | hexdump -C
#
Yes, hexdump sometimes just prints an asterisk if it only see a few zeros. That those four bytes of the boot sector were zero is consistent with the read of the first 256 bytes of the boot sector, reported earlier in your post. And the fact that those bytes didn't change to "74 65 73 74" ("test") shows that they couldn't be written to. (I am a little surprised, though, that the second read didn't produce the single asterisk that the first read did.)Sylvander wrote:Code: Select all
# dd if=/dev/sdb1 bs=1 skip=3 count=4 2>/dev/null | hexdump -C *
Q1. Did she work anywhere near radiography?My wife had this Verbatim Flash Drive on her keychain given her by someone at her workplace, for use in her employment, but she never used it, so gave it to me.
Code: Select all
# e2fsck -f -p -v /dev/sdb
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
/dev/sdb:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
#
Code: Select all
# fsck -nv /dev/sdb1
fsck from util-linux 2.19
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? no
fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdb1
# fsck.ext2 -pv /dev/sdb1
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1
/dev/sdb1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# e2fsck -b 8193 /dev/sdb1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# dosfsck -av /dev/sdb1
dosfsck 3.0.11 (24 Dec 2010)
dosfsck 3.0.11, 24 Dec 2010, FAT32, LFN
Logical sector size is zero.
#
-b 8193 is from 1,44MB floppy disk drives times. If mkfs.ext2-4 is called without any inode or block or superblock parameters, the first backup of the superblock is written to -b 32768.is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# e2fsck -b 8193 /dev/sdb1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
Code: Select all
dumpe2fs /dev/sdaX | grep -i backup
bash-3.00# dumpe2fs /dev/sda2 | grep -i backup
dumpe2fs 1.41.11 (14-Mar-2010)
Journal backup: inode blocks
Backup superblock at 32768, Group descriptors at 32769-32771
Backup superblock at 98304, Group descriptors at 98305-98307
Backup superblock at 163840, Group descriptors at 163841-163843
Backup superblock at 229376, Group descriptors at 229377-229379
Backup superblock at 294912, Group descriptors at 294913-294915
Backup superblock at 819200, Group descriptors at 819201-819203
Backup superblock at 884736, Group descriptors at 884737-884739
Backup superblock at 1605632, Group descriptors at 1605633-1605635
Backup superblock at 2654208, Group descriptors at 2654209-2654211
Backup superblock at 4096000, Group descriptors at 4096001-4096003
Backup superblock at 7962624, Group descriptors at 7962625-7962627
Backup superblock at 11239424, Group descriptors at 11239425-11239427
-S Write superblock and group descriptors only. This is useful if
all of the superblock and backup superblocks are corrupted, and
a last-ditch recovery method is desired. It causes mke2fs to
reinitialize the superblock and group descriptors, while not
touching the inode table and the block and inode bitmaps. The
e2fsck program should be run immediately after this option is
used, and there is no guarantee that any data will be salvage-
able. It is critical to specify the correct filesystem block-
size when using this option, or there is no chance of recovery.
I would like to introduce you to the man command:Sylvander wrote:I have little to no understanding of all of this stuff.
Could you give explicit instructions as to what I aught to do?
And explanations needed to give me essential understanding needed to get it right?
Code: Select all
man mke2fs
Code: Select all
man mke2fs
Code: Select all
dumpe2fs /dev/sdb1 | grep -i backup
Code: Select all
dumpe2fs /dev/sdb1 | grep -i backup
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
#