[Fedora-xen] Re: can't boot xen kernel

Sun Feb 19 14:38:50 UTC 2006

On 2/19/06, Justin Conover <justin.conover at gmail.com> wrote:
>
>
>
> On 2/19/06, Justin Conover <justin.conover at gmail.com> wrote:
> >
> >
> >
> > On 2/18/06, Justin Conover < justin.conover at gmail.com> wrote:
> > >
> > >
> > >
> > > On 2/18/06, Justin Conover < justin.conover at gmail.com> wrote:
> > > >
> > > > I can't boot the kernel-xen-hypervisor on one of my systems.  It
> > > > bombs out when it wants to mount my /home
> > > > Which is a RAID 5 with LVM, "can't find superblock", however a
> > > > normal kernel boots fine.
> > > >
> > > >
> > > >
> > > > lsmod | egrep 'ata|raid'
> > > > raid5                  27585  1
> > > > xor                    18249  1 raid5
> > > > raid1                  24513  2
> > > > sata_sil               13641  4
> > > > libata                 58189  1 sata_sil
> > > > scsi_mod              129257  5
> > > > sg,aic7xxx,scsi_transport_spi,libata,sd_mod
> > > >
> > > >
> > > ls initrd-2.6.15-1.1955_FC5smp/lib/
> > > aic7xxx.ko    dm-snapshot.ko  jbd.ko     sata_sil.ko
> > > sd_mod.ko
> > > dm-mirror.ko  dm-zero.ko      libata.ko  scsi_mod.ko
> > > dm-mod.ko     ext3.ko         raid1.ko   scsi_transport_spi.ko
> > >
> > > ls initrd-2.6.15-1.1955_FC5hypervisor/lib/
> > > aic7xxx.ko    dm-snapshot.ko  jbd.ko     sata_sil.ko
> > > sd_mod.ko
> > > dm-mirror.ko  dm-zero.ko      libata.ko  scsi_mod.ko
> > > dm-mod.ko      ext3.ko         raid1.ko   scsi_transport_spi.ko
> > >
> > >
> > > Same stuff is being loaded
> > >
> >
> >
> > I thought it might have been just a bad raid5 when I built it after the
> > install so I re-installed it.  Same problem
> >
> > fsck.ext3: Invalid argument while trying to open /dev/md2
> > /dev/md2:
> > 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>
> >
> >
> >
> > Any ideas?  Both md0/md1 boot fine and they are raid1's is there
> > something about raid5 the xen kernel might not like?
> >
>
> Some stuff from dmesg about md2 with the normal kernel booting it.
>
> md: considering sdd1 ...
> md:  adding sdd1 ...
> md:  adding sdc1 ...
> md:  adding sdb1 ...
> md:  adding sda1 ...
> md: created md2
> md: bind<sda1>
> md: bind<sdb1>
> md: bind<sdc1>
> md: bind<sdd1>
> md: running: <sdd1><sdc1><sdb1><sda1>
> md: personality for level 5 is not loaded!
> md: do_md_run() returned -22
> md: md2 stopped.
> md: unbind<sdd1>
> md: export_rdev(sdd1)
> md: unbind<sdc1>
> md: export_rdev(sdc1)
> md: unbind<sdb1>
> md: export_rdev(sdb1)
> md: unbind<sda1>
> md: export_rdev(sda1)
> md: ... autorun DONE.
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
>
> <SNIP>
>
> md: Autodetecting RAID arrays.
> md: autorun ...
> md: considering sda1 ...
> md:  adding sda1 ...
> md:  adding sdb1 ...
> md:  adding sdc1 ...
> md:  adding sdd1 ...
> md: created md2
> md: bind<sdd1>
> md: bind<sdc1>
> md: bind<sdb1>
> md: bind<sda1>
> md: running: <sda1><sdb1><sdc1><sdd1>
> raid5: automatically using best checksumming function: pIII_sse
>    pIII_sse  :  1733.000 MB/sec
> raid5: using function: pIII_sse (1733.000 MB/sec)
> md: raid5 personality registered for level 5
> md: raid4 personality registered for level 4
> raid5: device sda1 operational as raid disk 0
> raid5: device sdb1 operational as raid disk 1
> raid5: device sdc1 operational as raid disk 2
> raid5: device sdd1 operational as raid disk 3
> raid5: allocated 4206kB for md2
> raid5: raid level 5 set md2 active with 4 out of 4 devices, algorithm 2
> RAID5 conf printout:
>  --- rd:4 wd:4 fd:0
>  disk 0, o:1, dev:sda1
>  disk 1, o:1, dev:sdb1
>  disk 2, o:1, dev:sdc1
>  disk 3, o:1, dev:sdd1
> md: ... autorun DONE.
>
> <SNIP>
>
> EXT3 FS on md2, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> SELinux: initialized (dev md2, type ext3), uses xattr
>
>
Normal kernel

dumpe2fs /dev/md2 | grep Backup
dumpe2fs 1.38 (30-Jun-2005)
  Backup superblock at 32768, Group descriptors at 32769-32812
  Backup superblock at 98304, Group descriptors at 98305-98348
  Backup superblock at 163840, Group descriptors at 163841-163884
  Backup superblock at 229376, Group descriptors at 229377-229420
  Backup superblock at 294912, Group descriptors at 294913-294956
  Backup superblock at 819200, Group descriptors at 819201-819244
  Backup superblock at 884736, Group descriptors at 884737-884780
  Backup superblock at 1605632, Group descriptors at 1605633-1605676
  Backup superblock at 2654208, Group descriptors at 2654209-2654252
  Backup superblock at 4096000, Group descriptors at 4096001-4096044
  Backup superblock at 7962624, Group descriptors at 7962625-7962668
  Backup superblock at 11239424, Group descriptors at 11239425-11239468
  Backup superblock at 20480000, Group descriptors at 20480001-20480044
  Backup superblock at 23887872, Group descriptors at 23887873-23887916
  Backup superblock at 71663616, Group descriptors at 71663617-71663660
  Backup superblock at 78675968, Group descriptors at 78675969-78676012
  Backup superblock at 102400000, Group descriptors at 102400001-102400044

 fsck.ext3 /dev/md2
e2fsck 1.38 (30-Jun-2005)
/dev/md2: clean, 11/91586560 files, 2925310/183146928 blocks

e2fsck -b 32768 /dev/md2
e2fsck 1.38 (30-Jun-2005)
/dev/md2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/md2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/md2: 11/91586560 files (9.1% non-contiguous), 2925310/183146928 blocks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-xen/attachments/20060219/16e93686/attachment.htm>