Bug 6236
|
Description
tomek.fizyk
2006-03-16 14:23:38 UTC
Created attachment 7588 [details]
dmesg output
Created attachment 7589 [details]
kern.log
Judging from the logical block numbers in the error messages, it looks like the partition table on the pendrive may be messed up. What do you get from "fdisk -l /dev/sda"? "fdisk -l /dev/sda" lists a FAT partition on the pendrive But what are the sector numbers for the start and end of the the sda1 partition? And if they are okay, the next question is whether the filesystem itself has been corrupted. Have you tried running dosfsck on /dev/sda1? The point here is that your mount command failed because some software component was trying to read block 508378384, but the pendrive only contains 251904 blocks! No wonder you got an error. Created attachment 7628 [details]
output of "fdisk -l /dev/sda"
this is the output of fdisk command. I'll send the dosfsck output in a while
Created attachment 7733 [details]
"dosfsck /dev/sda1" output
This is the output of "dosfsck /dev/sda1" (at last;P). It is quite strange I
think... More strange is the fact that I've checked the same pendrive on other
computer with linux kernel 2.6.15-1 (2.6.15-1.1833_FC4 on Fedora Core 4) and it
worked... Couldn't it be some problem with other software, eg. udev? Or maby
with hardware? I also tried the original linux kernel 2.6.16-git8 and the
pendrive worked, but it was on the second computer (on Fedora, not Debian
system). I will try the newest kernel on the Debian system and send the
results. I don't know if Debian team changes something in the kernel, but if
they do - could it be the source of the problem?
Here's something that might help. Try doing this on each of the computers (or under each of the kernels): dd if=/dev/sda1 bs=512 count=1 | hexdump -C Be careful to keep track of which computer and which kernel produced which output. Normally one would expect the all outputs to be the same, but I bet they won't be. Created attachment 7772 [details]
output of "dd if=/dev/sda1..." on FC4 (kernel: 2.6.15-1.1833_FC4)
this is the output of "dd if=/dev/sda1 bs=512 count=1 | hexdump -C" on computer
with Fedora Core 4 with 2.6.15-1.1833_FC4 kernel
Created attachment 7773 [details]
output of "dd if=/dev/sda1..." on FC4 (kernel: 2.6.16.1)
And here is the ouput of the same command. The same computer, Fedora Core 4,
linux kernel 2.6.16.1 (I've installed this kernel over 2.6.16-git8, and the
pendrive also worked well). Both outputs are the same (I used diff to check
it). In few days Ill send the output from Debian installed on laptop.
Created attachment 7900 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.15-1-686-debian)
The output of dd command. Debian system on the laptop, kernel 2.6.15-1-686
compiled by Debian team
Created attachment 7901 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.16)
output from Debian on the laptop, kernel 2.6.16 from kernel.org
Created attachment 7902 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.17-rc1)
and finally from Debian on the laptop, with kernel 2.6.17-rc1 from kernel.org.
They are identical (I've checked with diff).
As one can see they are different from those from FC4 on the other machine.
It's obvious that the FC4 tests are doing what they are supposed to (reading the first sector of /dev/sda1) whereas the tests on the laptop are actually reading the first sector of /dev/sda instead of /dev/sda1. That's why the errors occur. At this point it's hard to tell if the difference is due to the system, the kernel version, or the hardware. The first thing to do is "ls -l /dev/sda*" on both machines. In particular, check to see that the major and minor numbers for /dev/sda and /dev/sda1 aren't identical. Can you copy the 2.6.17-rc1 kernel from the laptop to the other computer and run the test under it? If you do, is the output the same as from the FC4 kernels on that computer or is it the same as on the laptop? Also try this: Monitor the output from usbmon while running the "dd..." test. usbmon is described in Documentation/usb/usbmon.txt in the kernel source. You will probably have to rebuild the 2.6.17-rc1 kernel with CONFIG_USB_MON and CONFIG_DEBUG_FS set. Do this on both machines and attach the results here. Created attachment 8069 [details]
output of "ls /dev/sda*" on laptop, debian with kernel-2.6.15-1-686 (debian)
Created attachment 8070 [details]
output of "ls /dev/sda*" on laptop, debian with kernel-2.6.17-rc1 (kernel.org)
Created attachment 8071 [details]
output of usbmon on laptop while dd command (debian with linux-2.6.17-rc1)
Created attachment 8072 [details]
output of usbmon on laptop while pendrive attatch (debian with linux-2.6.17-rc1)
Created attachment 8073 [details]
output of usbmon on laptop while pendrive detatch (debian with linux-2.6.17-rc1)
On each of your two systems, what's in the file /sys/block/sda/sda1/start ? Probably on the laptop it says 0 and on the other system it says something like 512. If so, that's the root of the problem -- but we still don't know what's causing it. Created attachment 8108 [details]
output of "ls /dev/sda*" on computer, FC4 with2.6.15-1.1833_FC4 kernel
Created attachment 8109 [details]
output of usbmon on computer while dd (2.6.15-1.1833_FC4)
Created attachment 8110 [details]
output of usbmon on computer while attatch (2.6.15-1.1833_FC4)
Created attachment 8111 [details]
output of usbmon on computer while detatch (2.6.15-1.1833_FC4)
The above are the outputs of ls and usbmon on FC4 (on the desktop computer) with it's own 2.6.15-1. 1833_FC4 kernel. The content of /sys/block/sda/sda1/start on the system is 32. In a while I will send the output of the commands made on FC4 with the kernel copied from the laptop. In few days I will send the content of the /sys/block/sda/sda1/start from the laptop. Bad news... The kernel copied from laptop wouldn't run on the computer. Maby it's because the kernel is compiled for intel processor and on the computer there is an AMD64? Anyway I will send the /sys/ block/sda/sda1/start from the laptop in few days Created attachment 8152 [details]
/sys/block/sda/sda1/start from laptop with Debian
Well, that's strange. The file contains "60 480 0 0" but it should contain "32", just like on the other computer. I suspect that this was caused by a Debian modification to the kernel. Is it possible for you to install a vanilla kernel (or even a Fedora kernel) on the laptop? Or even just boot it from a live CD with a recent non-Debian kernel. If the PenDrive works then this is definitely a Debian problem and you should speak to them. If it doesn't work, then let us know which kernel you tried and show the contents of /sys/block/sda/sda1/start. Wait a minute! It looks like you posted the contents of /sys/block/sda/sda1/stat, not /sys/block/sda/sda1/start. Try doing it again. (By the way, you don't need to create a separate attachment for a 1-line file. Just include it in with your comments.) It was the correct file (/sys/block/sda/sda1/start), but after formatting the pendrive (under windows) the content of the file changed to 0. The Fedora kernel is 64bit and the laptop has 32bit processor, so it won't run. But I'm downloading some non-debian Live-CD distribution of linux so I will try it on the laptop. I have also Installed recently a Debian on the computer, so I will also try the pendrive on that system. In my first comment I wrote that the pendrive worked on laptop but under mandrake linux. My mistake... "60 480 0 0" was from stat, not from start even before formatting the pendrive... Any way i have connected the pendrive to the computer with the same debian installed and the situation was the same as in the case of laptop. So I am now sure that is Debian's fault. I'm also sure that when I run a non-debian LiveCD on the laptop the pendrive will work. I've run a non-debian Linux distribution on the laptop and the pendrive worked well. The distribution was Pingwinek GNU/Linux 1.0 preview 3. I've also tried DSL Linux 3.0 RC 1, which is, as far as I know, Knoppix based, and the pendrive did not work. Then you should mark this bug as REJECTED and file a bug report with the Debian maintainers. Let them know about this report though, so they can read through it and benefit from what we've learned. |