x86_64 builder; 32-bit LiveCD issues

[Toshio Kuratomi]

I've tried to create a 32bit LiveCd with a 32-bit repository on an
x86_64 system a couple times and run into an error.  After the isolinux
prompt I get this:

Uncompressing Linux... Ok, booting the kernel.
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(9,1)

This is under vmware which works for running 32bit images created on a
32bit system.  I haven't burned one of these disks to a CD yet.  The
first two lines are normal in that environment (running a LiveCD image
generated on a 32bit box brings up those two lines.)  But the next line
is a sign that something is really not happy.

I suspect that something in the 64 bit environment is being copied from
the builder's hard drive to the LiveCd instead of coming from the 32bit
packages in my repository.

Is anyone else attempting to create 32bit ISOs on x86_64?  Success or
failure reports would help me zero in on the problems.

-Toshio

[J. Hartline]

Toshio Kuratomi wrote:

> Uncompressing Linux... Ok, booting the kernel.
> powernow-k8: BIOS error - no PSB or ACPI _PSS objects
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(9,1)
> [snip]
> Success or
> failure reports would help me zero in on the problems.
>   
>  
Try the debug option, it should show you at which point it is failing.
9,0 is /dev/md0 here though.

[Toshio Kuratomi]

On Sun, 2006-04-02 at 04:05 -0500, J. Hartline wrote:
>  Try the debug option, it should show you at which point it is
> failing.
>  9,0 is /dev/md0 here though. 
ACPI: (supports S0 S1 S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
EXT2-fs: unable to read superblock
isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(9,1)

Am I correctly interpreting that the failure is in mounting the initrd?

-Toshio

[Chitlesh GOORAH]

On 4/2/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  I've tried to create a 32bit LiveCd with a 32-bit repository on
> an
>  x86_64 system a couple times and run into an error.  After the isolinux
>  prompt I get this:
>
>  Uncompressing Linux... Ok, booting the kernel.
>  powernow-k8: BIOS error - no PSB or ACPI _PSS objects
>  Kernel panic - not syncing: VFS: Unable to mount root fs on
>  unknown-block(9,1)
>
>  This is under vmware which works for running 32bit images created on a
>  32bit system.  I haven't burned one of these disks to a CD yet.  The
>  first two lines are normal in that environment (running a LiveCD image
>  generated on a 32bit box brings up those two lines.)  But the next line
>  is a sign that something is really not happy.
>
>  I suspect that something in the 64 bit environment is being copied from
>  the builder's hard drive to the LiveCd instead of coming from the 32bit
>  packages in my repository.
>
>  Is anyone else attempting to create 32bit ISOs on x86_64?  Success or
>  failure reports would help me zero in on the problems.
>
>  -Toshio 
Vmplayer do sometimes behave like a fool.
I'm experiencing randomly some failures during the booting process of
the livecds.
But when I burnt those isos, they worked just perfect.

This is ofcourse my experience :)

Chitlesh
--
http://clunixchit.blogspot.com

[Chitlesh GOORAH]

>  Try the debug option, it should show you at which point it is
> failing.
>  9,0 is /dev/md0 here though. 
Ill try to optimise the debug option, in a few months (<2), along its
related documentation

Chitlesh
--
http://clunixchit.blogspot.com

[Chitlesh GOORAH]

On 4/3/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  On Sun, 2006-04-02 at 04:05 -0500, J. Hartline wrote:
>  > Try the debug option, it should show you at which point it is failing.
>  > 9,0 is /dev/md0 here though.
>
>  ACPI: (supports S0 S1 S5)
>  md: Autodetecting RAID arrays.
>  md: autorun ...
>  md: ... autorun DONE.
>  RAMDISK: Compressed image found at block 0
>  VFS: Mounted root (ext2 filesystem).
>  EXT2-fs: unable to read superblock
>  isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32
>  Kernel panic - not syncing: VFS: Unable to mount root fs on
>  unknown-block(9,1)
>
>  Am I correctly interpreting that the failure is in mounting the initrd?
>
>  -Toshio
>  

Talking about this, Ive a question!!

Hyperthreading !!!
I know that during an install, when Fedora identifies a system with
hyperthreading option, It will choose the smp kernel.

Does a Livecd built with Kadischi stall if it identifies this
hyperthreading capability in a system ?


--
http://clunixchit.blogspot.com

[J. Hartline]

Toshio Kuratomi wrote:

> ACPI: (supports S0 S1 S5)
> md: Autodetecting RAID arrays.
> md: autorun ...
> md: ... autorun DONE.
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> EXT2-fs: unable to read superblock
> isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(9,1)
>
> Am I correctly interpreting that the failure is in mounting the initrd?
>   
>  
What kernel is this?
Is it a Fedora kernel, if so what kernel release?

[J. Hartline]

Chitlesh GOORAH wrote:

> Talking about this, Ive a question!!
>
> Hyperthreading !!!
> I know that during an install, when Fedora identifies a system with
> hyperthreading option, It will choose the smp kernel.
>
> Does a Livecd built with Kadischi stall if it identifies this
> hyperthreading capability in a system ?
>   
>  
It shouldn't.
It would be different if say, you installed an SMP kernel on a single 
processor or non HT
machine.

[Jane Dogalt]

--- Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:

>  On Sun, 2006-04-02 at 04:05 -0500, J. Hartline wrote:
>  > Try the debug option, it should show you at which point it is failing.
>  > 9,0 is /dev/md0 here though.
>  
>  ACPI: (supports S0 S1 S5)
>  md: Autodetecting RAID arrays.
>  md: autorun ...
>  md: ... autorun DONE.
>  RAMDISK: Compressed image found at block 0
>  VFS: Mounted root (ext2 filesystem).
>  EXT2-fs: unable to read superblock
>  isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32
>  Kernel panic - not syncing: VFS: Unable to mount root fs on
>  unknown-block(9,1)
>  
>  Am I correctly interpreting that the failure is in mounting the initrd? 
Certainly looks like it mounted the ext2, then was unable to read the
superblock?

Here are a couple thoughts I had while skimming livecd-mkinitrd.sh.

1) inst /sbin/busybox.anaconda should probably be inst
$rootdir/sbin/busybox.anaconda (which would require it to be installed on the
target system)

2) inst $INSTALLDIR/initrd/find-live-cd

makes me think this could be your problem.  I.e. this would appear to me to be
(in your case) installing a find-live-cd binary which was compiled on a x86_64
system into an initrd which is meant to be run on a 32-bit system.

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Toshio Kuratomi]

On 4/3/06, Jane Dogalt <jdogalt(a)yahoo.com&gt; wrote:
>  --- Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  > VFS: Mounted root (ext2 filesystem).
>  > EXT2-fs: unable to read superblock
>  > isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32
>  > Kernel panic - not syncing: VFS: Unable to mount root fs on
>  > unknown-block(9,1)
>  >
>  > Am I correctly interpreting that the failure is in mounting the initrd?
>
>  Certainly looks like it mounted the ext2, then was unable to read the
>  superblock?
>  
Err.. Right.  That's what I meant :-)

>  Here are a couple thoughts I had while skimming livecd-mkinitrd.sh.
>
>  1) inst /sbin/busybox.anaconda should probably be inst
>  $rootdir/sbin/busybox.anaconda (which would require it to be installed on the
>  target system)
>  
Bah -- Since kadischi knows the location of the repository, how about
extracting busybox.anaconda from the repository rpm and inst'ing it?

>  2) inst $INSTALLDIR/initrd/find-live-cd
>
>  makes me think this could be your problem.  I.e. this would appear to me to be
>  (in your case) installing a find-live-cd binary which was compiled on a x86_64
>  system into an initrd which is meant to be run on a 32-bit system.
>  
Well, you and AutOPSY both had the same idea.  Unfortunately, it's not
the problem.  I replaced both find-live-cd and scanswap with i386
versions and I still get the same error.

I've also burned an actual ISO and tried to boot that on a 32bit
computer and received the same error.  I'll try hacking something
together for the busybox issue sometime tomorrow and see if that gets
things resolved.

In the meantime, I've filed the story thus far in bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187858

[Jane Dogalt]

--- Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:

 
>  > Here are a couple thoughts I had while skimming
> livecd-mkinitrd.sh.
>  >
>  > 1) inst /sbin/busybox.anaconda should probably be inst
>  > $rootdir/sbin/busybox.anaconda (which would require it to be installed on
>  the
>  > target system)
>  >
>  Bah -- Since kadischi knows the location of the repository, how about
>  extracting busybox.anaconda from the repository rpm and inst'ing it? 
Yup, an rpm -i --nodeps --noscripts --root=/tmppath oughtta do it.

>  
>  > 2) inst $INSTALLDIR/initrd/find-live-cd
>  >
>  > makes me think this could be your problem.  I.e. this would appear to me to
>  be
>  > (in your case) installing a find-live-cd binary which was compiled on a
>  x86_64
>  > system into an initrd which is meant to be run on a 32-bit system.
>  >
>  Well, you and AutOPSY both had the same idea.  Unfortunately, it's not
>  the problem.  I replaced both find-live-cd and scanswap with i386
>  versions and I still get the same error. 
Yup, I think the answer here, would possibly be requiring a kadischi rpm to be
available for the target arch in addition to the target arch's repository. 
Then an rpm call like the one above could be used to pull it.

>  
>  I've also burned an actual ISO and tried to boot that on a 32bit
>  computer and received the same error.  I'll try hacking something
>  together for the busybox issue sometime tomorrow and see if that gets
>  things resolved. 
As you can guess, I chalk the above issues up to the same issue I've been
harping on about the installer having many bugs(as I call them) pertaining to
it's incorporating the host system's state (system files, hardware status) into
the target system.

I.e, I seriously doubt that enough (if any) focus has been put into seeing just
how well behaved anaconda --rootpath will be when it is run on an x86_64
system, but with a 32bit repository intended for a 32bit system.  Just
speculation for now though.

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com