A bad scare: root file system recovery [SOLVED]

Llama · 2008-04-23 06:17:38

Hi, everybody,

The trouble began with an odd message: KDE Daemon: new storage detected (hard disk): open in a new window, ignore. Unfortunately, the hard disk in question is statically mounted via /etc/fstab; should have been mounted all along.

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0


/dev/cdrom /mnt/cdrom   iso9660   ro,user,noauto,unhide,iocharset=utf8   0      0
/dev/dvd /mnt/dvd   udf   ro,user,noauto,unhide,iocharset=utf8   0      0
/dev/fd0 /mnt/fd0   vfat   user,noauto   0      0
/dev/sdb1 swap swap defaults 0 0
/dev/sdb2 / ext3 defaults 0 1
/dev/sdb3 /home ext3 defaults 0 1
#/dev/sda1 /home/alexey/mnt/a ext3 defaults 0 1

It's /dev/sda1, now commented. Real trouble began when I tried to reboot. The kernel told me there's no root file system on sdb2; it checked the disks unsuccessfully, with scary messages about bad device names and device blocks, advised me to use rootfstype=kernel option, etc. sda1 turned out "bad" too. In fallback mode the system booted, but with file systems mounted read only; not much use... Using some recovery disk I commented out the /dev/sda1 line in /etc/fstab on suspicion that sda is the real offender; tried to reboot, without much success, then rebooted again, and something clicked into place; the system is back to normal, but I fear to approach sda1 . What happened? Any suggestion/link is going to be appreciated. It was pure luck; next time it could be much worse.

Edit:
Looks like 'clicked into place' is just the fallback kernel; kernel-related issue? It ran smoothly after the initial upgrade for a couple of weeks.

Edit:
A relevant snippet from kernel.log:

Apr 23 19:52:25 stovepipebox ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Apr 23 19:52:25 stovepipebox ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
Apr 23 19:52:25 stovepipebox ata2.00: ATAPI: _NEC DVD_RW ND-4550A, 1.06, max UDMA/33
Apr 23 19:52:25 stovepipebox ata2.00: configured for UDMA/33
Apr 23 19:52:25 stovepipebox scsi 1:0:0:0: CD-ROM            _NEC     DVD_RW ND-4550A  1.06 PQ: 0 ANSI: 5
Apr 23 19:52:25 stovepipebox sata_nv 0000:00:0e.0: version 3.5
Apr 23 19:52:25 stovepipebox ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
Apr 23 19:52:25 stovepipebox ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
Apr 23 19:52:25 stovepipebox PCI: Setting latency timer of device 0000:00:0e.0 to 64
Apr 23 19:52:25 stovepipebox scsi2 : sata_nv
Apr 23 19:52:25 stovepipebox scsi3 : sata_nv
Apr 23 19:52:25 stovepipebox ata3: SATA max UDMA/133 cmd 0xe800 ctl 0xe480 bmdma 0xe000 irq 16
Apr 23 19:52:25 stovepipebox ata4: SATA max UDMA/133 cmd 0xe400 ctl 0xe080 bmdma 0xe008 irq 16
Apr 23 19:52:25 stovepipebox ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr 23 19:52:25 stovepipebox ata3.00: ATA-6: ST3120827AS, 3.42, max UDMA/133
Apr 23 19:52:25 stovepipebox ata3.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32)
Apr 23 19:52:25 stovepipebox ata3.00: model number mismatch 'ST3120827AS' != '3120827AS                             '
Apr 23 19:52:25 stovepipebox ata3.00: revalidation failed (errno=-19)
Apr 23 19:52:25 stovepipebox ata3: limiting SATA link speed to 1.5 Gbps
Apr 23 19:52:25 stovepipebox ata3.00: limiting speed to UDMA/133:PIO3
Apr 23 19:52:25 stovepipebox ata3: failed to recover some devices, retrying in 5 secs
Apr 23 19:52:25 stovepipebox ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Apr 23 19:52:25 stovepipebox ata3.00: configured for UDMA/133
Apr 23 19:52:25 stovepipebox ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr 23 19:52:25 stovepipebox ata4.00: ATA-7: ST3320620AS, 3.AAK, max UDMA/133
Apr 23 19:52:25 stovepipebox ata4.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
Apr 23 19:52:25 stovepipebox ata4.00: configured for UDMA/133
Apr 23 19:52:25 stovepipebox scsi 2:0:0:0: Direct-Access     ATA      ST3120827AS      3.42 PQ: 0 ANSI: 5
Apr 23 19:52:25 stovepipebox scsi 3:0:0:0: Direct-Access     ATA      ST3320620AS      3.AA PQ: 0 ANSI: 5

This "model number mismatch 'ST3120827AS' != '3120827AS " looks like a result of a corrupted config (at least, I suspect so ). Any questions/suggestions?

Last edited by Llama (2008-05-02 20:20:04)

Llama · 2008-04-23 06:48:16

Yes, sda1 is certainly corrupt:

----

[root@stovepipebox alexey]# fsck /dev/sda1
fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
fsck.ext2: No such file or directory while trying to open /dev/sda1

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/sda1

makes no difference. What further action can be taken?

Llama · 2008-04-24 05:36:56

Sorry that my posts could be a bit unclear, but the description of the trouble somewhat grew over time (look at the edits in the initial post). The question is: can I renew my kernel configuration, which seems to be a bit garbled, without full reinstall? I assume that the hard drive with the root partition is physically OK, because once booted, the system runs without a hitch.

Llama · 2008-04-25 04:54:17

There is an idea, based on the assumption that some kernel configuration needs to be restored:

# pacman -Sf kernel26

Is it worth trying?

Llama · 2008-04-26 06:38:49

Am I asking too much, or the question's too dumb?

tigrmesh · 2008-04-26 15:09:11

Llama wrote:

There is an idea, based on the assumption that some kernel configuration needs to be restored:
# pacman -Sf kernel26
Is it worth trying?

Maybe. I have no experience with disk corruption problems, however. If it were me, I would reinstall. I would cp (NOT dd) my /etc and /home directories somewhere safe first.

Llama · 2008-05-02 14:23:12

# pacman -Sf kernel26

solved the root file system problem

gparted restored the sda drive without any loss of data. All is well except the residual scare . Now the situation looks like a nasty kernel glitch. Such glitches aren't supposed to happen, are they?

Last edited by Llama (2008-05-02 14:34:53)

jacko · 2008-05-02 17:23:49

I had this same damn thing happen. The problem is in the way the kernel gets its info from the bios. The bios has a nasty habit of switching the drives around even when sda is connected to sata1. This became a problem when libata came about and changed all drives to sdxX naming convention.

To fix the no booting problem and the stupid rootfstype= error thing, u need to use Persistent block naming device scheme. Here on the wiki is a page dedicated to this... http://wiki.archlinux.org/index.php/Per … ice_naming

Try it and see if it helps. I used the /dev/by-uuid.

Llama · 2008-05-02 20:18:14

Thank you very much! I'll try the persistent naming, though it may not be urgent. Instinctively I left the sda disk normally unmounted and out of harm's way . Or I hope so...

Arch Linux

#1 2008-04-23 06:17:38

A bad scare: root file system recovery [SOLVED]

#2 2008-04-23 06:48:16

Re: A bad scare: root file system recovery [SOLVED]

#3 2008-04-24 05:36:56

Re: A bad scare: root file system recovery [SOLVED]

#4 2008-04-25 04:54:17

Re: A bad scare: root file system recovery [SOLVED]

#5 2008-04-26 06:38:49

Re: A bad scare: root file system recovery [SOLVED]

#6 2008-04-26 15:09:11

Re: A bad scare: root file system recovery [SOLVED]

#7 2008-05-02 14:23:12

Re: A bad scare: root file system recovery [SOLVED]

#8 2008-05-02 17:23:49

Re: A bad scare: root file system recovery [SOLVED]

#9 2008-05-02 20:18:14

Re: A bad scare: root file system recovery [SOLVED]

Board footer