[SOLVED] Disc/partittion problem after upgrading from 13.0 to 13.1

Mellar · 06-05-2010, 05:18 AM

I have two harddrives in the computer and both are the old P-ATAs.

When upgrading to the new Slackware 13.1, I had no problems with the first hardrive, but I get some problems with the second one.

This is my fdisk -l

Code:

root@Muspellsheim:~# fdisk -l

........

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       13544   102392608+   7  HPFS/NTFS
/dev/sda2           13545       14222     5116702+  83  Linux
/dev/sda3           14222       14899     5116702+  83  Linux
/dev/sda4           14899       41346   199936957+   5  Extended
/dev/sda5           14899       15576     5116671   83  Linux
/dev/sda6           15576       17201    12289693+  83  Linux
/dev/sda7           17201       17340     1052226   82  Linux swap
/dev/sda8           17341       41346   181478241   83  Linux

........

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       12748   102398278+  83  Linux
/dev/sdb2           12749       25496   102398310   83  Linux
/dev/sdb3           25497       36481    88237012+  83  Linux

This is my /etc/fstab

Code:

/dev/sda7       swap             swap        defaults         0   0
/dev/sda2        /                xfs         defaults         1   1
/dev/sda3        /var             xfs         defaults         1   2
/dev/sda5        /tmp             xfs         defaults         1   2
/dev/sda6        /usr             xfs         defaults         1   2
/dev/sda8        /home            xfs         defaults         1   2
#/dev/hda2        /mnt/windows     ntfs        ro               1   0
/dev/sdb2        /mnt/musikk      xfs        defaults         1   2
/dev/sdb1        /mnt/filmer      xfs         defaults         1   2
/dev/sdb3        /mnt/annet       xfs         defaults         1   2
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro  0   0
#/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0

and ls /dev/sdb* give me this

Code:

root@Muspellsheim:~# ls /dev/sdb*
/dev/sdb  /dev/sdb1

mounting /dev/sdb1 gives me an error

Code:

root@Muspellsheim:~# mount /dev/sdb1 /mnt/filmer/
mount: /dev/sdb1: can't read superblock

I haven't had any problems with the harddrive until upgrading to 13.1, so my guesses there's some driver problem with the new kernel. There are three partitions on the harddrive (sdb1), I can see all three on fdisk -l, but one partition only when trying to list the partitions with ls /dev/sdb*

Do you guys have any tips for helping me out with this problem?

GazL · 06-05-2010, 06:12 AM

"Can't read the superblock" is usually a sign of filesystem damage. You might want to see what xfs_check tells you about /dev/sdb1

Also read the xfs_check man-page as it gives you some detail on how to recover from damage.

One thing I do notice is that your /dev/sdb1 has the boot ('*') flag set. What concerns me about this is that if I remember rightly, xfs filesystems start from block 0, and if you install a bootloader to an xfs partition, it'll overwrite the first few blocks of the filesystem. I hope that's not what's happened here. You can check whether that's the case with:

Code:

dd if=/dev/sdb1 bs=512 count=1 | hexdump -C

If you see the string 'LILO' on the first line of the output, then that's probably what's happened.

Mellar · 06-05-2010, 07:09 AM

I'll bost the output from xfs_check

Code:

root@Muspellsheim:~# xfs_check /dev/sdb1
XFS: totally zeroed log
can't seek in filesystem at bb 106134576
can't read btree block 8/467038
extent count for ino 172 data fork too low (0) for file format
bad nblocks 1063569 for inode 172, counted 0
bad nextents 66 for inode 172, counted 0
can't seek in filesystem at bb 66644728
can't read inode block 5/330726
can't seek in filesystem at bb 67362776
can't read inode block 5/420482
can't seek in filesystem at bb 76798704
can't read superblock for ag 6
can't seek in filesystem at bb 89598488
can't read superblock for ag 7
can't seek in filesystem at bb 102398272
can't read superblock for ag 8
can't seek in filesystem at bb 115198056
can't read superblock for ag 9
can't seek in filesystem at bb 127997840
can't read superblock for ag 10
can't seek in filesystem at bb 140797624
can't read superblock for ag 11
can't seek in filesystem at bb 153597408
can't read superblock for ag 12
can't seek in filesystem at bb 166397192
can't read superblock for ag 13
can't seek in filesystem at bb 179196976
can't read superblock for ag 14
can't seek in filesystem at bb 191996760
can't read superblock for ag 15

I'm happy there's no LILO on the first line, but the other lines doesn't look too promising either.

Just to decide wether it's a Slackware 13.1 problem or a filesystem failure, I booted the old Slackware 13.0 installation CD. I was able to mount all three partiotions, list the directories and files with no errors what so ever. This makes me pretty sure there's no filesystem failure, but rather a driver problem in Slackware 13.1.

When upgrading to 13.1 there were some new changes, where I had to rename my harddrives from hda and hdb to sda and sdb. I also had to delete /etc/udev/rules.d/70-persistent-cd.rules according to CHANGES_AND_HINTS.TXT, but this is related to cdrom-devices and not harddrives...

GazL · 06-05-2010, 08:10 AM

Well I'm glad it's not the lilo issue. And as you say going back to 13.0 the filesystem is still there so it's clearly still intact.

If you're sure that sdb is indeed the correct device name for the drive after the hd-->sd renaming then I don't have any other ideas. Does running "blkid" from your 13.1 system show anything that might suggest a naming mismatch?

Mellar · 06-05-2010, 10:33 AM

blkid lists only one partiton on sdb, and that's the sdb1
/dev/sdb1: UUID="a81ab032-35cf-4375-939b-65e5a9304e9c" TYPE="xfs"

It says XFS which is correct.

GazL · 06-05-2010, 10:54 AM

Can you post the output(in full) of the following please

cat /proc/partitions

ls -l /dev/sd*

Mellar · 06-05-2010, 11:14 AM

Code:

root@Muspellsheim:~# cat /proc/partitions 
major minor  #blocks  name

   7        0    4217344 loop0
   8        0  312571224 sda
   8        1  102392608 sda1
   8        2    5116702 sda2
   8        3    5116702 sda3
   8        4          1 sda4
   8        5    5116671 sda5
   8        6   12289693 sda6
   8        7    1052226 sda7
   8        8  181478241 sda8
   8       16   33027624 sdb
   8       17   33027592 sdb1

Code:

root@Muspellsheim:~# ls -l /dev/sd*
brw-rw---- 1 root disk 8,  0 2010-06-05 15:50 /dev/sda
brw-rw---- 1 root disk 8,  1 2010-06-05 15:50 /dev/sda1
brw-rw---- 1 root disk 8,  2 2010-06-05 15:50 /dev/sda2
brw-rw---- 1 root disk 8,  3 2010-06-05 15:50 /dev/sda3
brw-rw---- 1 root disk 8,  4 2010-06-05 15:50 /dev/sda4
brw-rw---- 1 root disk 8,  5 2010-06-05 15:50 /dev/sda5
brw-rw---- 1 root disk 8,  6 2010-06-05 15:50 /dev/sda6
brw-rw---- 1 root disk 8,  7 2010-06-05 15:50 /dev/sda7
brw-rw---- 1 root disk 8,  8 2010-06-05 15:50 /dev/sda8
brw-rw---- 1 root disk 8, 16 2010-06-05 15:50 /dev/sdb
brw-rw---- 1 root disk 8, 17 2010-06-05 15:50 /dev/sdb1

Looks like fdisk is the only tool being able to see sdb2 and sdb3

GazL · 06-05-2010, 11:34 AM

Yes, that's most definitely 'weird'. I was curious to see whether the major/minor numbers were ok, but that all looks right. Even if udev was getting it wrong, I'd have expected your missing partitions to show up in /proc/partitions.

The only time I've seen anything like this was on a very large disk where the partitions were going past the 2TB partition size limit, but from the sizes on your fdisk, that doesn't look to be the case here either.

Anything unusual show up in your 'dmesg'? I'm pretty much out of ideas at this stage.

afterthought:
If you're still using the 'huge' kernel, it might be worth trying to swap to 'generic' + initrd and see if that helps.

syvy · 06-05-2010, 02:12 PM

I had the same problem: http://www.linuxquestions.org/questi...13-1-a-812293/ and finally got it: My harddisk was jumpered as a slave and i just removed the jumper.

Mellar · 06-05-2010, 02:17 PM

You are right, GazL. The disc is probably 300GB and each partition about 100GB.

I'm trying to post the interesting parts from dmesg

Code:

root@Muspellsheim$ dmesg 
...
libata version 3.00 loaded.
....
ata_piix 0000:00:1f.1: version 2.13
ata_piix 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
......
ata1.00: ATA-8: WDC WD3200AAJB-00J3A0, 01.03E01, max UDMA/133
ata1.00: 625142448 sectors, multi 16: LBA48 
ata1.01: HPA detected: current 66055248, native 586072368
ata1.01: ATA-7: SAMSUNG HD300LD, WK100-12, max UDMA/100
ata1.01: 66055248 sectors, multi 16: LBA48 
ata2.00: ATAPI: Hewlett-Packard DVD Writer 300, 3.11, max UDMA/33
ata2.01: ATAPI: HL-DT-STDVD-ROM GDR8162B, 0019, max UDMA/33
ata1.00: configured for UDMA/100
ata2.00: configured for UDMA/33
ata1.01: configured for UDMA/100
scsi 0:0:0:0: Direct-Access     ATA      WDC WD3200AAJB-0 01.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 625142448 512-byte logical blocks: (320 GB/298 GiB)
scsi 0:0:1:0: Direct-Access     ATA      SAMSUNG HD300LD  WK10 PQ: 0 ANSI: 5
ata2.01: configured for UDMA/33
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:1:0: [sdb] 66055248 512-byte logical blocks: (33.8 GB/31.4 GiB)
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
scsi 1:0:0:0: CD-ROM            HP       DVD Writer 300n  3.11 PQ: 0 ANSI: 5
 sda:sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
 sda1 sda2 sda3 sda4 <
scsi 1:0:1:0: CD-ROM            HL-DT-ST DVD-ROM GDR8162B 0019 PQ: 0 ANSI: 5
 sda5
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda6 sda7sr1: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
 sda8 >
 sdb:
sr 1:0:1:0: Attached scsi CD-ROM sr1
 sdb1 sdb2 sdb3
sd 0:0:0:0: [sda] Attached SCSI disk
sdb: p1 size 204796557 exceeds device capacity, limited to end of disk
sdb: p2 ignored, start 204796620 is behind the end of the disk
sdb: p3 ignored, start 409593240 is behind the end of the disk
sd 0:0:1:0: [sdb] Attached SCSI disk
registered taskstats version 1
Freeing unused kernel memory: 484k freed
Write protecting the kernel text: 4072k
Write protecting the kernel read-only data: 1292k
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem sda2
Ending clean XFS mount for filesystem: sda2
udev: starting version 153
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sr 1:0:0:0: Attached scsi generic sg2 type 5
........
Adding 1052216k swap on /dev/sda7.  Priority:-1 extents:1 across:1052216k 
fuse init (API version 7.13)
lp0: using parport0 (interrupt-driven).
lp0: console ready
XFS mounting filesystem sda3
Ending clean XFS mount for filesystem: sda3
XFS mounting filesystem sda5
Ending clean XFS mount for filesystem: sda5
XFS mounting filesystem sda6
Ending clean XFS mount for filesystem: sda6
XFS mounting filesystem sda8
Ending clean XFS mount for filesystem: sda8
attempt to access beyond end of device
sdb1: rw=0, want=204796544, limit=66055185
I/O error in filesystem ("sdb1") meta-data dev sdb1 block 0xc34f27f       ("xfs_read_buf") error 5 buf count 512
XFS: size check 2 failed
...........
attempt to access beyond end of device
sdb1: rw=0, want=204796544, limit=66055185
I/O error in filesystem ("sdb1") meta-data dev sdb1 block 0xc34f27f       ("xfs_read_buf") error 5 buf count 512
XFS: size check 2 failed

Especially the «attempt to access beyond end of device» caught my eye. But perhaps nothing new, when fdisk thought the disc was no larger than 38GB.

Mellar · 06-05-2010, 02:22 PM

Thanks for sharing your solution syvy. sdb is my secondary disc though (slackware installed on sda), but I'll surely check my bumpers. Strange this issue didn't affect the older versions of Slackware.

syvy · 06-05-2010, 02:27 PM

I think the new libata subsystem is handling those things different.

GazL · 06-06-2010, 09:52 AM

Code:

sd 0:0:1:0: [sdb] 66055248 512-byte logical blocks: (33.8 GB/31.4 GiB)
sdb: p1 size 204796557 exceeds device capacity, limited to end of disk
sdb: p2 ignored, start 204796620 is behind the end of the disk
sdb: p3 ignored, start 409593240 is behind the end of the disk

Well, there's the cause. For some reason the kernel on slackware 13.1 thinks your disk is only 32ish GiB so it disables the partitions it thinks go beyond that. I've never seen that before. I have no idea why it's happening.

Mellar · 06-07-2010, 05:42 PM

Quote:

Originally Posted by syvy

I think the new libata subsystem is handling those things different.

You are absolutely right. Removing the jumper from sdb solved the problem.

Thanks, syvy and GazL.