I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
fdisk -l /dev/sdf gives the following: Disk /dev/sdf: 8004 MB, 8004829184 bytes 102 heads, 38 sectors/track, 4033 cylinders Units = cylinders of 3876 * 512 = 1984512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc3072e18
Device Boot Start End Blocks Id System /dev/sdf1 3 4034 7813184 7 HPFS/NTFS
mount -t ntfs /dev/sdf1 /mnt/usb gives: NTFS signature is missing. Failed to mount '/dev/sdf1': Invalid argument The device '/dev/sdf1' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
as does mount -t ntfs /dev/sdf /mnt/usb NTFS signature is missing. Failed to mount '/dev/sdf': Invalid argument The device '/dev/sdf' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
I have the following installed: ntfs-3g-2011.4.12-5.el6.x86_64 ntfsprogs-2011.4.12-5.el6.x86_64
Has there been a change to the NTFS system with the advent of windoze 8.0/8.1?? Any help appreciated. TIA Rob
On 4/14/2014 6:06 PM, Rob Kampen wrote:
I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
most USB sticks are formatted FAT32
On Apr 14, 2014, at 7:23 PM, John R Pierce pierce@hogranch.com wrote:
On 4/14/2014 6:06 PM, Rob Kampen wrote:
I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
most USB sticks are formatted FAT32
Also keep in mind that the partition type is only a *hint*. It's just a flag that's set in the partition. What is actually in the partition does not need to match what is on the disk.
Some utilities will use it for autodetection purposes, etc., and some will completely ignore it and blindly do whatever you ask.
"file" is a good tool to find out what's actually on the partition.
--Russell
On 04/15/2014 02:42 PM, Russell Miller wrote:
On Apr 14, 2014, at 7:23 PM, John R Pierce pierce@hogranch.com wrote:
On 4/14/2014 6:06 PM, Rob Kampen wrote:
I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
most USB sticks are formatted FAT32
Also keep in mind that the partition type is only a *hint*. It's just a flag that's set in the partition. What is actually in the partition does not need to match what is on the disk.
Some utilities will use it for autodetection purposes, etc., and some will completely ignore it and blindly do whatever you ask.
"file" is a good tool to find out what's actually on the partition.
tried VFAT, NTFS, HFS HFSPLUS MSDOS - all gave error messages
& USBFS the usbfs did mount and gave me seven directories named 001 through 007 and one file called "devices" - this in no way resembles what is actually on the usb drive.
file when applied /dev/sdf/(1) indicted a block device - nothing else helpful.
I guess there is thus a new ntfs format out there that ntfs-3g does not recognise. Any other way to read / deal with this??
--Russell _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2014-04-16 at 18:26 +1200, Rob Kampen wrote:
On 04/15/2014 02:42 PM, Russell Miller wrote:
On Apr 14, 2014, at 7:23 PM, John R Pierce pierce@hogranch.com wrote:
On 4/14/2014 6:06 PM, Rob Kampen wrote:
I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
most USB sticks are formatted FAT32
file when applied /dev/sdf/(1) indicted a block device - nothing else helpful.
Try as root: dd if=/dev/sdf1 of=somefile count=100 file somefile
regards, Louis
On 04/17/2014 09:03 AM, Louis Lagendijk wrote:
On Wed, 2014-04-16 at 18:26 +1200, Rob Kampen wrote:
On 04/15/2014 02:42 PM, Russell Miller wrote:
On Apr 14, 2014, at 7:23 PM, John R Pierce pierce@hogranch.com wrote:
On 4/14/2014 6:06 PM, Rob Kampen wrote:
I recently received an 8GB usb stick that fails to mount on my fully patched CentOS 6.5 desktop machine.
The stick works just fine on a windoze 7 laptop (my daughter's) with no special drivers installed.
most USB sticks are formatted FAT32
file when applied /dev/sdf/(1) indicted a block device - nothing else helpful.
Try as root: dd if=/dev/sdf1 of=somefile count=100 file somefile
that gave me:
somefile: x86 boot sector, code offset 0x76
when I tried dd if=/dev/sdf of=somefile count=100 i get:
somefile: x86 boot sector, Microsoft Windows XP MBR, Serial 0xc3072e18; partition 1: ID=0x7, starthead 0, startsector 8064, 15626368 sectors, code offset 0xc0
still not much wiser I'm afraid. My understanding of the MBR is rough, certainly insufficient to debug this. the frustration is that windoze is quite happy to mount and read it just fine.
regards, Louis
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/16/2014 11:05 PM, Rob Kampen wrote:
when I tried dd if=/dev/sdf of=somefile count=100 i get:
somefile: x86 boot sector, Microsoft Windows XP MBR, Serial 0xc3072e18; partition 1: ID=0x7, starthead 0, startsector 8064, 15626368 sectors, code offset 0xc0
still not much wiser I'm afraid. My understanding of the MBR is rough, certainly insufficient to debug this. the frustration is that windoze is quite happy to mount and read it just fine.
It appears that someone took an _image_ of a full 8GB partitioned device with a standard DOS MBR and stuffed that into _one_partition_ of this USB stick. You should be able to access it in Linux by running (as root):
kpartx -a -v /dev/sdf1
That should respond with "add map sdf1p1 ...", and you can then mount device /dev/mapper/sdf1p1.
You should run "kpartx -d /dev/sdf1" to delete that mapping before removing the device.
BTW, the "file" command will look inside block devices if you use the "-s" (--special-files) flag. It doesn't do that by default because reading some types of special files can have unexpected effects. You can also use the "-k" (--keep-going) flag to get more information than the first match.
file -s -k /dev/sdf1
On 04/17/2014 12:26 PM, Robert Nichols wrote:
On 04/16/2014 11:05 PM, Rob Kampen wrote:
when I tried dd if=/dev/sdf of=somefile count=100 i get:
somefile: x86 boot sector, Microsoft Windows XP MBR, Serial 0xc3072e18; partition 1: ID=0x7, starthead 0, startsector 8064, 15626368 sectors, code offset 0xc0
still not much wiser I'm afraid. My understanding of the MBR is rough, certainly insufficient to debug this. the frustration is that windoze is quite happy to mount and read it just fine.
It appears that someone took an _image_ of a full 8GB partitioned device with a standard DOS MBR and stuffed that into _one_partition_ of this USB stick. You should be able to access it in Linux by running (as root):
kpartx -a -v /dev/sdf1That should respond with "add map sdf1p1 ...", and you can then mount device /dev/mapper/sdf1p1.
You should run "kpartx -d /dev/sdf1" to delete that mapping before removing the device.
BTW, the "file" command will look inside block devices if you use the "-s" (--special-files) flag. It doesn't do that by default because reading some types of special files can have unexpected effects. You can also use the "-k" (--keep-going) flag to get more information than the first match.
file -s -k /dev/sdf1
OUCH!! Forget most of that. I misread your "dd" command as reading from /dev/sdf1 instead of /dev/sdf, since the former was what you had been asked to do. The comment about the "file" command still applies, though. What does the "file" command have to say about /dev/sdf1 (or a copy of the beginning sectors thereof)?
On 04/18/2014 05:32 AM, Robert Nichols wrote:
On 04/17/2014 12:26 PM, Robert Nichols wrote:
On 04/16/2014 11:05 PM, Rob Kampen wrote:
when I tried dd if=/dev/sdf of=somefile count=100 i get:
somefile: x86 boot sector, Microsoft Windows XP MBR, Serial 0xc3072e18; partition 1: ID=0x7, starthead 0, startsector 8064, 15626368 sectors, code offset 0xc0
still not much wiser I'm afraid. My understanding of the MBR is rough, certainly insufficient to debug this. the frustration is that windoze is quite happy to mount and read it just fine.
It appears that someone took an _image_ of a full 8GB partitioned device with a standard DOS MBR and stuffed that into _one_partition_ of this USB stick. You should be able to access it in Linux by running (as root):
kpartx -a -v /dev/sdf1That should respond with "add map sdf1p1 ...", and you can then mount device /dev/mapper/sdf1p1.
You should run "kpartx -d /dev/sdf1" to delete that mapping before removing the device.
BTW, the "file" command will look inside block devices if you use the "-s" (--special-files) flag. It doesn't do that by default because reading some types of special files can have unexpected effects. You can also use the "-k" (--keep-going) flag to get more information than the first match.
file -s -k /dev/sdf1OUCH!! Forget most of that. I misread your "dd" command as reading from /dev/sdf1 instead of /dev/sdf, since the former was what you had been asked to do. The comment about the "file" command still applies, though. What does the "file" command have to say about /dev/sdf1 (or a copy of the beginning sectors thereof)?
# dd if=/dev/sdf1 of=somefile count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0408561 s, 1.3 MB/s
file -s somefile somefile: x86 boot sector, code offset 0x76
file -s -k somefile somefile: x86 boot sector, code offset 0x76
# file -s -k /dev/sdf1 /dev/sdf1: x86 boot sector, code offset 0x76
seems like the partition /dev/sdf1 contains an x86 boot sector - so what do I mount?? where is the data?
On 04/17/2014 08:08 PM, Rob Kampen wrote:
# file -s -k /dev/sdf1 /dev/sdf1: x86 boot sector, code offset 0x76
seems like the partition /dev/sdf1 contains an x86 boot sector - so what do I mount?? where is the data?
It's lacking a lot of the parameters I wold expect to see there, e.g.:
# file -s -k /dev/sda1 /dev/sda1: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80)
That is from Windows 7. Is the difference due to Windows 8? I don't know -- I don't have anything with Windows 8. I did run across this:
http://nodehead.com/tip-of-the-day-mount-a-windows-8-ntfs-partition-for-read...
But, the "Fast Startup" change it describes might only apply to the Windows 8 boot partition. You might try the suggestion to mount the partition with an explicit "read-only" flag.
On 04/19/2014 02:13 AM, Robert Nichols wrote:
On 04/17/2014 08:08 PM, Rob Kampen wrote:
# file -s -k /dev/sdf1 /dev/sdf1: x86 boot sector, code offset 0x76
seems like the partition /dev/sdf1 contains an x86 boot sector - so what do I mount?? where is the data?
It's lacking a lot of the parameters I wold expect to see there, e.g.:
# file -s -k /dev/sda1 /dev/sda1: x86 boot sector, code offset 0x52, OEM-ID "NTFS ",sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80)
That is from Windows 7. Is the difference due to Windows 8? I don't know -- I don't have anything with Windows 8. I did run across this:
http://nodehead.com/tip-of-the-day-mount-a-windows-8-ntfs-partition-for-read...
But, the "Fast Startup" change it describes might only apply to the Windows 8 boot partition. You might try the suggestion to mount the partition with an explicit "read-only" flag.
tried the mount with the -r (read only) flag - no difference. I also have a hard drive with windoze on it and using the file command against that I get almost exactly what you do. For some reason this usb stick is different. When I get the opportunity I'll try it on windoze system, write to it and unmount it properly, maybe it wasn't closed properly by the person I got it from, and I cannot ask them, they would have no idea what I'm talking about. Thanks all for the suggestions, I'll update this if I get any further.
On 04/19/2014 08:32 PM, Rob Kampen wrote:
On 04/19/2014 02:13 AM, Robert Nichols wrote:
On 04/17/2014 08:08 PM, Rob Kampen wrote:
# file -s -k /dev/sdf1 /dev/sdf1: x86 boot sector, code offset 0x76
seems like the partition /dev/sdf1 contains an x86 boot sector - so what do I mount?? where is the data?
It's lacking a lot of the parameters I wold expect to see there, e.g.:
# file -s -k /dev/sda1 /dev/sda1: x86 boot sector, code offset 0x52, OEM-ID "NTFS ",sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80)
That is from Windows 7. Is the difference due to Windows 8? I don't know -- I don't have anything with Windows 8. I did run across this:
http://nodehead.com/tip-of-the-day-mount-a-windows-8-ntfs-partition-for-read...
But, the "Fast Startup" change it describes might only apply to the Windows 8 boot partition. You might try the suggestion to mount the partition with an explicit "read-only" flag.
tried the mount with the -r (read only) flag - no difference. I also have a hard drive with windoze on it and using the file command against that I get almost exactly what you do. For some reason this usb stick is different. When I get the opportunity I'll try it on windoze system, write to it and unmount it properly, maybe it wasn't closed properly by the person I got it from, and I cannot ask them, they would have no idea what I'm talking about. Thanks all for the suggestions, I'll update this if I get any further.
request to epel packagers - I know this is a centos list, but many epel folk read here too. just had a look at the ntfs-3g developers site (tuxera.com) and find that significant development has occurred since 2011.4.12.5 - with 3 further stable releases. Any chance that epel can update to the latest version 2014.2.15? It may fix my problem .... my rpm build skills are very poor, only ever done it once over three years ago. TIA Rob
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
John R Pierce -
Louis Lagendijk -
Rob Kampen -
Robert Nichols -
Russell Miller