Find the answer to your Linux question:
Results 1 to 5 of 5
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,18)

    I'm not a newbie per se, as I've been using Linux exclusively for over a year and have experience with various other *NIXes. However I've lead a charmed life and things have always "just worked" for me in the past. This is my first kernel panic and I'm stymied.

    My memory is poor, but I'll attempt to recall some installation details:

    Dell 3-ish gig
    512MB ram
    two 160gig SATA harddrives:
    sda: XP, Dell recovery partition
    sdb: SuSE Linux 9.2 Professional

    All was chugging along nicely until I moved to a new apartment. Upon firing up the machine to SuSE, I get a kernel panic. Booting to XP works fine, unfortunately. To the best of my knowledge I had not changed anything important prior to booting down before the move. All cables have been checked and are well-seated where they should be.

    I have manually transcribed here as much of the boot.msg as I can see on the screen. Please pardon any typos ("sbd" for "sdb", for instance).

        Vendor: ATA    Model: WDC WD1600JD-75H    Rev: 08.0
        Type: Direct-Access        ANSI SCSI revision: 05
    SCSI device sda: 312500000 512-byte hdwr sectors (160000 MB)
    SCSI devive sda: drive cache: write back
        sda: sda1 sda2 sda3
    Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
        Vendor: ATA    Model: Maxtor ^Y160M0    Rev: YAR5
        Type: Direct-Access        ANSI SCSI revision: 05
    SCSI device sdb: 320173056 512-byte hdwr sectors (163929 MB)
    SCSI device sbd: drive cache: write back
        sbd: sbd1 sbd2
    Attached scsi disk sbd at scsi0, channel 0, id 1 lun 0
    Loading kernel/fs/reiserfs/reiserfs.ko
    Waiting for device /dev/sbd2 to appear: . ok
    rootfs:  major=8 minor=18 devn=2066
    ReiserFS: sdb2: found reiserfs format "3.6" with standard journal
    ata1: status=0x51 { DriveReady SeekComplete Error }
    ata1: error=0x40 { UncorrectableError }
    ata1: status=0x51 { DriveRead SeekComplete Error }
    ata1: error=0x40 { UncorrectableError }
    ata1: status=0x51 { DriveReady SeekComplete Error }
    ata1: error=0x40 { UncorrectableError }
    ata1: status=0x51 { DriveReady SeekComplete Error }
    ata1: error=0x40 { UncorrectableError }
    scsi0: ERROR on channel0, id1, lun 0, CBD: Read (10) 00 03 47 9f 41 00 00 08 00
    Current sbd: sense key Medium Error
    Additional sense: Unrecovered read error - auto reallocate failed
    end_request: I/O error, dev sbd, sector 55025473
    ata1: status=0x51 { DriveReadySeekComplete Error }
    ata1: error=0x40 { UncorrectableError }
    Current ...
    ata1: error ...  (five times)
    ReiserFS: sbd2: warning: sh-2029: reiserfs read_bitmaps: bitmap block (#6619136) reading failed
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,18)
    I am able to access the Rescue system on the SuSE 9.2 installation discs, but I must admit that I don't know what to do with it. My suspicion about what's going on here is that despite the fact that it seems like it's trying to boot from sdb2, the boot info is actually contained on sda1. That's only a suspicion. How can I check this?

    Many thanks in advance for any assistance the community can give.


  2. #2
    Linux Engineer
    Join Date
    Jan 2005
    Chicago (USA)
    1. Run fsck /dev/sdb2 from the rescue CD.
    2. Show us /boot/grub/grub.conf, or lilo.conf (I'm not sure where that's located since I use GRUB).

  3. #3

    fsck, no luck

    Thank you for the assistance so far. Here's what I get when I run `fsck /dev/sdb2`:

    Rescue: # fsck /dev/sdb2
    fsck 1.35 (28-Feb-2004)
    reiserfsck 3.6.18 (2003
    [ snip 'send report if bug' message ]
    Will read-only check consistency of the filesystem on /dev/sdb2
    Will put log info to 'stdout'
    Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
    reiserfsck --check started at Thu Aug  4 18:43:18 2005
    Replaying journal..
    The problem has occurred looks like a hardware problem.  If you have bad blocks, we advise you to get a new hard drive, because once you get one bad block  that the disc drive internals cannot hide from your sight, the chances of getting more are generally said to become much higher (precise statistics are unknown to us), and this disk drive is probably not expensive enough for your to risk your time and data on it.  If you don't want to follow that follow that advice then if you have just a few bad blocks, try writing to the bad blocks and see if the drive remaps the bad blocks (that means it takes a block it has in reserve and allocates it for use for of that block number).  If it cannot remap the block, use badblock option (-B) with  reiserfs utils to handle this block correctly.
    bread: Cannot read the block (3844): Input/output error).
    Warning... fsck.reiserfs for device /dev/sdb2 exited with signal 6.
    fsck.reiserfs /dev/sdb2 failed (status 0x8). Run manually!
    Ignoring the fact that the able authors of fsck.reiserfs need an editor, things don't seem to be too promising. I'm about to go cozy up with the laptop, a glass of wine and the man page for fsck (and perhaps a well-placed Google search or two), but if anyone has any more advice it would be very welcome and highly appreciated.


  4. $spacer_open
  5. #4

    God Bless Google

    My problem is not solved yet, but at least some sort of progress is being made. I'll detail it here because I hate it when I search for info in forums only to find "yeah, I did some stuff after looking at some sites and it still doesn't work." Or worse yet, a thread where someone is dealing with the same problem as you and it ends with a triumphant yet unhelpful post of "Hurrah! It works! Thanks for all the help!" with no further details on how the problem was solved.

    I performed a Google search for these terms: reiserfsck bread "cannot read the block". That led me to this webpage discussing how to handle bad blocks on reiserfs, brought to you by the fine folks at namesys (whence reiserfs):

    Currently, I'm running the following badblocks command:
    Rescue: # /sbin/badblocks -b 4096 /dev/sdb2 >> badblocks.txt
    So far it's found 38 bad blocks. Drat. Time to roll up the sleeves and get a bit down and dirty with this one.

    /dev/sdb2 is a Maxtor drive, so what better place to turn than the Maxtor PowerMax utility for a helping hand. Their knowledge base is full of references to creating/using a PowerMax floppy. Unfortunately for me, this is the new millennium and floppies are going the way of the dodo. A little searching turned up this kb page containing instructions on where to get the .iso:
    Maxtor KB Article

    Once badblocks is done running (and I've captured that list somewhere safe), PowerMax will probably be my next step before I go unleashing a 'reiserfsck --badblocks ... --rebuild-tree' on the thing.

    Hopefully this info will be handy for other newbies.


  6. #5

    The prognosis is not good

    Well, it looks like this harddrive might be a lost cause. The low-level disk utility (PowerMax) provided by the manufacturer kept freezing at "Searching for Disks.." This was a good hint that perhaps I should start shopping for a new drive...

    But first, I wanted to make sure I had all of my bases covered. So I ran badblocks again. This time it found 268 blocks which were no good. In an attempt to "fix" the drive:

    Rescue:~ # fsck.reiserfs --fix-fixable --badblocks badblocks.txt /dev/sdb2
    Do you want to run this program?[N/Yes]: Yes
    create_badblock_bitmap: block number (3840) belongs to system reiserfs area.  It cannot be relocated.
    So my system blocks are hosed. It looks like the option with the least headache potential now is to buy a new drive and use ddrescue to try and salvage some of the data from this one.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts