[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-ia64-devel] RE: Progress on RHEL4, but blocked at xlilo?



With the xen4elilo patch, I am able to get much further but
am still running into a problem:

 NET: Registered protocol family 17
 Freeing unused kernel memory: 384kB freed
 Warning: unable to open an initial console.
 dm_mod: no version for "struct_module" found: kernel tainted.
 device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@xxxxxxxxxx
 cdrom: open failed.
 Kernel panic - not syncing: Attempted to kill init!

Is the kernel panic related to the other messages or is xenlinux
panic'ing for some other reason?  I tried using an /sbin/init
from RHEL3 (but did not recompile the kernel with SELinux off).

Thanks,
Dan 

> -----Original Message-----
> From: Kouya SHIMURA [mailto:kouya@xxxxxxxxxxxxxxxx] 
> Sent: Friday, November 11, 2005 4:11 AM
> To: Yang, Fred
> Cc: Magenheimer, Dan (HP Labs Fort Collins); Zhang, Xiantao; 
> takebe_akio@xxxxxxxxxxxxxx; Xu, Anthony; 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx; Yoshi. Oguchi
> Subject: RE: Progress on RHEL4, but blocked at xlilo?
> 
> I'm also trying to boot RHEL4 on Xen3.0(IA64) and encountered 
> a execution
> stuck problem in /sbin/init. It seems just the same as Akio's problem.
> 
> I'm not sure but I suspects that the SELinux feature might be
> concerned with this problem. Since there is no problem on RHEL3.
> RHEL4's /sbin/init is special and performs some work for SELinux.
> (mounting selinuxfs etc. Original SysVinit package doesn't support
> SELinux)
> 
> SELinux feature is not enabled in default Xen 3.0 setting
> (xen0_defconfig_ia64). 
> So I made a SELinux enabled Xenolinux for RHEL4 and tried it.
> As a result RHEL4 system is completely booted!
> 
> Another solution is to exchange /sbin/init. Using orignal (not patched
> for SELinux) /sbin/init I also succeeded to boot RHEL4 system. 
> It's so easy that Akio should try this solution.
> 
> But Linux kernel whose SELinux feature is not enabled can boot RHEL4
> sytem on actual machine. So non-SELinuxed Dom0 must be booted on
> Xen. That is Xen3.0 has still potential bugs.
> Akio will continue to investigate this problem.
> 
> --
> Kouya Shimura
> ARCHTECTURE LABORATORY
> FUJITSU LABORATORIES LTD.
> 
> Yang, Fred writes:
>  > Xen need to support xlilo for Linux kernel load.  But Xen 
> has already loaded Linux kernel and gives the control to it 
> per Akio's previous mail.  The key will be on why /sbin/init 
> execution stuck?
>  > -Fred
>  > Akio's previous mail =============================
>  > int switchrootCommand(char * cmd, char * end) {
>  > 
>  > snip
>  > 
>  > 
>  >     execv(initargs[0], initargs);   <----call /sbin/init 
> and hangup :-<
>  >     printf("exec of init (%s) failed!!!: %d\n", 
> initargs[0], errno);
>  >     return 1;
>  > }
>  > 
>  > Magenheimer, Dan (HP Labs Fort Collins) wrote:
>  > > Is there any progress on this?  It would be nice to
>  > > get this working prior to the Xen 3.0 freeze so
>  > > default Xen 3.0 bits can boot RHEL4.  Is a fix
>  > > required for xlilo or is it another problem?
>  > > 
>  > > Thanks,
>  > > Dan
>  > > 
>  > >> -----Original Message-----
>  > >> From: Zhang, Xiantao [mailto:xiantao.zhang@xxxxxxxxx]
>  > >> Sent: Tuesday, November 08, 2005 5:37 AM
>  > >> To: takebe_akio@xxxxxxxxxxxxxx; Yang, Fred; Xu, Anthony;
>  > >> Magenheimer, Dan (HP Labs Fort Collins);
>  > >> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>  > >> Subject: RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at
>  > >> xlilo? 
>  > >> 
>  > >> Hi Akio:
>  > >> What you did should be correct, and we also look for the
>  > >> reason which result in the error .
>  > >>         Thanks
>  > >> Zhang Xiantao
>  > >> CSD-OTC PRC Virtualization
>  > >> Intel (China) Limited
>  > >> 
>  > >> -----Original Message-----
>  > >> From: takebe_akio@xxxxxxxxxxxxxx 
> [mailto:takebe_akio@xxxxxxxxxxxxxx]
>  > >> Sent: 2005å11æ8æ 18:22 To: Zhang, Xiantao; Yang, Fred; 
> Xu, Anthony;
>  > >> Magenheimer, Dan (HP Labs Fort Collins);
>  > >> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx 
>  > >> Cc: takebe_akio@xxxxxxxxxxxxxx
>  > >> Subject: RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at
>  > >> xlilo? 
>  > >> 
>  > >> Hi Zhang,
>  > >> 
>  > >> Thank you for your infomation.
>  > >> 
>  > >>> Please make sure your vmlinux-2.6.12-xen0 from
>  > >>> .../xen-ia64-unstable.hg/ linux-2.6.12-xen0/vmlinux , not
>  > >> ".../xen-ia64-unstable.hg/dist/install/
>  > >>> vmlinux-2.6.12-xen0".
>  > >> Yes. I don't use dist/install/vmlinuz-2.6.12.6-xen0xen.
>  > >> I use linux-2.6.12-xen0/vmlinux.
>  > >> 
>  > >> I did as follows. :)
>  > >> 
>  > >> 1. make xen
>  > >> 2. make kernels
>  > >> 3. cp xen/xen.gz /boot/efi/efi/xen/
>  > >> 4. cp linux-2.6.12-xen0/vmlinux 
> /boot/efi/efi/xen/vmlinux-2.6.12-xen0
>  > >> 5. cd linux-2.6.12-xen0
>  > >> 6. make modules_install
>  > >> 7. mkinitrd -f /boot/efi/efi/xen/initrd-2.6.12-xen0.img
>  > >> 2.6.12.6-xen0xen
>  > >> 8. reboot and boot with xlilo
>  > >> 
>  > >> Best Regards,
>  > >> 
>  > >> Akio Takebe
>  > >> 
>  > >>> Hi Akio:
>  > >>> Please make sure your vmlinux-2.6.12-xen0 from
>  > >>> .../xen-ia64-unstable.hg/ linux-2.6.12-xen0/vmlinux , not
>  > >> ".../xen-ia64-unstable.hg/dist/install/
>  > >>> vmlinux-2.6.12-xen0".
>  > >>> Because  vmlinux is uncompressed and 
> vmlinux-2.6.12-xen0 from dist
>  > >>> directory is compressed in despite of its no .gz end.
>  > >>> 
>  > >>>     Zhang Xiantao
>  > >>> CSD-OTC PRC Virtualization
>  > >>> Intel (China) Limited
>  > >>> 
>  > >>> 
>  > >>> 
>  > >>> 
>  > >>> -----Original Message-----
>  > >>> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>  > >>> [mailto:xen-ia64-devel- bounces@xxxxxxxxxxxxxxxxxxx] 
> On Behalf Of
>  > >>> takebe_akio@xxxxxxxxxxxxxx Sent: 2005ãã1ãã8ãã 16:28 
> To: Yang, Fred;
>  > >>> Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins); xen-
>  > >>> ia64-devel@xxxxxxxxxxxxxxxxxxx 
>  > >>> Subject: RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at
>  > >>> xlilo? 
>  > >>> 
>  > >>> Hi Fred,
>  > >>> 
>  > >>> I used the following file.
>  > >>> I should use uncompressed linux kernel, shouldn't I?
>  > >>> 
>  > >>> # file /boot/efi/efi/xen/vmlinux-2.6.12-xen0
>  > >>> /boot/efi/efi/xen/vmlinux-2.6.12-xen0: ELF 64-bit LSB 
> executable,
>  > >>> IA-64, version 1 (SYSV), statically linked, not stripped
>  > >>> 
>  > >>> Best Regards,
>  > >>> 
>  > >>> Akio Takebe
>  > >>> 
>  > >>>> Akio,
>  > >>>> 
>  > >>>> To make sure, you are not using "compressed" 
> XenoLinux image in
>  > >>>> the configuration file 
>  > >>>> 
>  > >>>>> image=vmlinux-2.6.12-xen0  <=========== MUST not 
> compressed      
>  > >>>>>         label=xen vmm=xen.gz
>  > >>>>>         initrd=initrd-2.6.12-xen0.img
>  > >>>>>         read-only
>  > >>>> 
>  > >>>> -Fred
>  > >>>> 
>  > >>>> takebe_akio@xxxxxxxxxxxxxx wrote:
>  > >>>>> Hi Dan, Fred and Anthony,
>  > >>>>> 
>  > >>>>> Thank you for your adivece.
>  > >>>>> As you say, I used the following config file.
>  > >>>>> But I couldn't boot.
>  > >>>>> 
>  > >>>>> ------------
>  > >>>>> prompt
>  > >>>>> timeout=20
>  > >>>>> default=xen
>  > >>>>> relocatable
>  > >>>>> 
>  > >>>>> image=vmlinux-2.6.12-xen0
>  > >>>>>         label=xen
>  > >>>>>         vmm=xen.gz
>  > >>>>>         initrd=initrd-2.6.12-xen0.img
>  > >>>>>         read-only
>  > >>>>>         append="com2=115200,8n1 console=com2 
> sched=bvt -- nomca
>  > >>>>> nosmp console=tty0 rhgb root=/dev/sda2" ------------
>  > >>>>> 
>  > >>>>> I suspect registrations of SCSI drivers and so on.
>  > >>>>> I used vmlinux included "mptscsih and mptbase" now.
>  > >>>>> Should I use a initrd included "mptscsih and mptbase"
>  > >>>>> and a vmlinux not included these?
>  > >>>>> 
>  > >>>>> I will check the buffer of kernel_read() by using 
> more printk().
>  > >>>>> :-) 
>  > >>>>> 
>  > >>>>> Best Regards,
>  > >>>>> 
>  > >>>>> Akio Takebe
> 
> 
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.