boot up fails with mount root problem...

From: Ben Russo (ben_at_muppethouse.com)
Date: 05/19/05

  • Next message: Ben Russo: "Re: Configuring RAID 10 with RedHat ES 4 (64 bit)"
    To: redhat-list@redhat.com
    Date: Thu, 19 May 2005 13:07:37 -0400
    
    

    I have a RHEL-2.1ES OS running just fine on a standard PC (with an IDE
    disk).

    I wanted to migrate that system to a new box with a SCSI disk.

    I used a 3rd box running RHEL-3 to mount the new SCSI disk,
    used fdisk to create all the partitions, and mkfs.ext3 to create the
    filesystems, e2label to label them, and then I mounted them all up
    and used rsync -avzH <oldserver>:/* . -exclude "proc/*"

    Everything seemed to work fine.

    Then I chroot'd into the new filesystem

    I then edited the /etc/modules.conf and added a line for the scsi
    hostadaptor, and deleted the /etc/mtab, and edited the /etc/fstab
    and modified it appropriately.

    I created new initrd files, and edited grub.conf

    I put the SCSI disk in the new box, booted from RHEL-3 CD in rescue
    mode, chrooted into /mnt/sysimage edited the /boot/grub/devices.map
    and then ran grub-install.

    Rebooted off the SCSI disk. Worked up until I get:

    ...
    Partition check:
      sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 >
    Loading jbd module
    Journalled Block Device driver loaded
    Loading ext3 module
    Mounting /proc filesystem
    Creating root device
    Mountin root filesystem
    mount: error 19 mounting ext3
    pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
    Freeing unused kernel memory: 228k freed
    Kernel panic: No init found. Try passing init= option to kernel

    I checked that /dev/sd* devices are all there, and they have the right
    perm's and ownership. I also can boot from rescue CD and mount up all
    the filesystems as ext3 (they are clean). I triple checked my grub.conf
    file and devices.map and initrd stuff. All the modules seem to have
    loaded fine, and it can see the disk (as evidenced by the partition
    check). I also have another box with identical hardware and I confirmed
    that it has the same devices.map and grub.conf config...

    What gives? What does this error "error 19 mounting ext3" mean then?

    Thanks in advance,
    -Ben.

    -- 
    redhat-list mailing list
    unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
    https://www.redhat.com/mailman/listinfo/redhat-list
    

  • Next message: Ben Russo: "Re: Configuring RAID 10 with RedHat ES 4 (64 bit)"

    Relevant Pages

    • Re: what to do about "cannot dump to dumpdev hd(1/41): space for
      ... The brand new SCSI disk does the exact same thing the old one did. ... Divvy looks the same, the same 3 bad blocks were complained about when I added the disk with mkdev hd the first time, when I do fsck -ofull on /dev/part4 and /dev/part5 they both have the same warning about the filesystem being larger than the filesystem it is currently in etc. so at this point it looks like a good copy of the original disk. ... Then investigate the remaining tapes. ...
      (comp.unix.sco.misc)
    • SCSI disk I/O errors!!! verifying/patching/recovering filesystem?
      ... - Is this a disk or SCSI bus problem? ... after using an external SCSI HP scanner. ... I am running kernel 2.4.20 ... - What is the easiest way to verify my filesystem integrity? ...
      (comp.os.linux.hardware)
    • Weird harddisk behaviour
      ... A couple of weeks ago my 400Gb SATA disk crashed. ... Partition Table for /dev/sda ... # Type Sector Sector Offset Length Filesystem Type Flag ... Superblock backups stored on blocks: ...
      (Linux-Kernel)
    • Re: [patch] ext2/3: document conditions when reliable operation is possible
      ... the data on the filesystem has not been horribly mangled. ... further writes to the disk can trash unrelated existing data because it's ... disk can trash unrelated existing data _anyway_, because the flash block ... Today we have cheap plentiful USB keys that act like hard drives, ...
      (Linux-Kernel)
    • Strange case of root filesystem corruption
      ... Yesterday GRUB would suddenly not display the boot menu anymore. ... Looking at filesystems on the disk with the free ufs2tools program, ... Subfolders of / on the same filesystem are affected as well. ... sectors/track: 63 ...
      (freebsd-questions)