Menu
▾
▴
[Fwd: Re: [uml-user] x86_64 UML won't boot on IBM x336]
|
From: Phill W. <um...@we...> - 2005-07-18 22:36:20
|
Oops sent it directly to you. Here it is via the list... Cheers Phill. -------- Forwarded Message -------- > From: Phill Wombat <um...@we...> > To: Blaisorblade <bla...@ya...> > Subject: Re: [uml-user] x86_64 UML won't boot on IBM x336 > Date: Tue, 19 Jul 2005 08:27:50 +1000 >=20 > Hi Paolo, >=20 > Firstly, allow me to compliment you on the quality of your English, I > assume you're a native Italian speaker. I'm sure there's a story just > there... >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FC4 under UML on 32 bit: >=20 > Firstly, I removed (renamed) all */tls to */tls.001. i.e. cd /; find . > -name tls* and then rename them. (possibly not required but I did it > anyway). >=20 > Secondly, do surgery to rc.sysinit. Cut out all lines that refer to > fsck. Turns out fsck uses threads and wants NPTL working. Just cut all > the lines out (it feels painful, but just do it). You can still fsck > your disks from the host by using e2fsck filename (with the UML shutdow= n > obviously). >=20 > Thirdly, comment out: >=20 > #session required pam_loginuid.so >=20 > in /etc/pam.d/login. Not sure why this is so (possibly NPTL again) but > if you don't then you cannot log in because the PAM backend can't creat= e > a session for you. >=20 > I also fixed inittab commenting out all terminals and only leaving tty0 > so the console comes out the session you started the UML from. I use > this in conjunction with the screen program to provide root console > access for maintenance. >=20 > That's where I am right now. I have really run anything with it yet, bu= t > so far so good. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The kernel on x86_64: >=20 > I think you've put your finger on it. I am pretty certain now that I'm > trying to run an x86_64 kernel against a 32 bit rootfs. I did not use > the SUBARCH=3Di386. I tried it but it wouldn't compile, so I sort of ho= ped > it would just be a 32 bit kernel hosted on x86_64 :( >=20 > This is what I did: >=20 > #!/bin/bash >=20 > VERSION=3D2.6.12 > PATCHVERSION=3D2.6.13-rc3 > UML=3Duml-2.6.12-bs7.patch >=20 > cd /home/phill > rm -rf linux-$VERSION > echo "Unzip linux-$VERSION.tar.bz2" > tar -jxf /home/phill/download/linux-$VERSION.tar.bz2 > #echo "Copy patch-$PATCHVERSION.bz2" > #cp /home/phill/download/patch-$PATCHVERSION.bz2 /home/phill/linux-$VER= SION > echo "Copy uml-$PATCHVERSION.bz2" > cp /home/phill/download/$UML.bz2 /home/phill/linux-$VERSION >=20 > cd /home/phill/linux-$VERSION > echo "Unzip $UML into /home/phill/linux-$VERSION" > bunzip2 $UML.bz2 >=20 > patch -p1 < $UML >=20 > make mrproper ARCH=3Dum > make menuconfig ARCH=3Dum > make linux ARCH=3Dum SUBARCH=3Di386 >=20 > I just exit and save the menuconfig. >=20 > This is what I get if I compile with SUBARCH=3Di386. >=20 > # > # using defaults found in arch/um/defconfig > # >=20 >=20 > *** End of Linux kernel configuration. > *** Execute 'make' to build the kernel or try 'make help'. >=20 > CHK include/linux/version.h > UPD include/linux/version.h > SYMLINK include/asm -> include/asm-um > SPLIT include/linux/autoconf.h -> include/config/* > HOSTCC scripts/basic/fixdep > In file included from /usr/include/features.h:337, > from /usr/include/sys/types.h:27, > from scripts/basic/fixdep.c:105: > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > directory > scripts/basic/fixdep.c: In function =E2=80=98parse_config_file=E2=80=99= : > scripts/basic/fixdep.c:245: warning: pointer targets in passing argumen= t > 1 of =E2=80=98use_config=E2=80=99 differ in signedness > scripts/basic/fixdep.c: In function =E2=80=98parse_dep_file=E2=80=99: > scripts/basic/fixdep.c:299: warning: pointer targets in passing argumen= t > 1 of =E2=80=98__builtin_strchr=E2=80=99 differ in signedness > scripts/basic/fixdep.c:299: warning: pointer targets in assignment > differ in signedness > make[1]: *** [scripts/basic/fixdep] Error 1 > make: *** [scripts_basic] Error 2 >=20 > Essentially, this is what I get if I add SUBARCH=3Di386 at any of the > earlier stages (make menuconfig ARCH=3Dum SUBARCH=3Di386...) >=20 > It seems pretty clear from your post that I have to have a clean compil= e > with SUBARCH=3Di386. >=20 > If I just take the working UML kernel from the 32 bit machine and just > run it, should it work? It seems to start the init process and just > hangs there. Seems to indicate that the 32 bit kernel can tell the CPU > is different and does different things. >=20 > Cheers and thanks for the help > Phill. >=20 > On Mon, 2005-07-18 at 20:33 +0200, Blaisorblade wrote: > > On Monday 18 July 2005 13:45, Phill Wombat wrote: > > > Further to the previous post, > >=20 > > > I noticed, after posting, that the SKAS3 patch is not recognized by= the > > > kernel compiled on the x336. > > For 64-bit host kernels, SKAS is still a work in progress. With that = patch I'm=20 > > able to run some simple test programs, but not UML itself, so you sho= uld for=20 > > now pass mode=3Dtt on the command line. > >=20 > > Where SKAS mode isn't recognised the SKAS patch is already implied. > >=20 > > > However, here are a couple of lines from the linux kernels from RH7= 3 and > > > FC4/32 booting up (both of which recognize SKAS3 on FC4-x86_64). I = just > > > copied the binaries over and ran them: > >=20 > > > > I've compiled up a kernel using FC4 x86_64 patched with > > > > skas-2.6.12-rc4-v9-pre4 after jigging the FC4 rpm spec file. > > > > > > > > I think it should be OK because I can run an FC4 UML (with a few > > > > things *fixed* in the rootfs) > > How did you do that? There was a thread about that but I didn't see a= ny "ACK,=20 > > it works" (there was a suggestion about avoiding nash being called). > >=20 > > > > on the 32 bit version of the FC4. (NPTL=20 > > > > can be worked around for the moment in FC4). > >=20 > > > > While I can get the UML booting and working on 32 bit, the 64 bit > > > > machine produces: > >=20 > > > > VFS: Mounted root (ext3 filesystem) readonly. > > > > request_module: runaway loop modprobe binfmt-464c > >=20 > > This is interesting and clear, however I've resumed this below: > >=20 > > http://lists.debian.org/debian-amd64/2004/01/msg00132.html > >=20 > > However there's something I've not clear: are you trying to run a 32 = or 64-bit=20 > > UML ? I'm not referring to the filesystem, but to the UML kernel itse= lf.=20 > > I.e., do you get that with the same UML binary? > >=20 > > > > So I Google about somewhat and all I can find is some references = to > > > > ELF files not being recognized. This in turn causes the OS to mod= probe > > > > for the above mentioned module which is meant to gobble up the EL= F and > > > > load it. > >=20 > > > > More Googling produces references to AMD x86_64 Opterons not havi= ng 32 > > > > bit mode compiled in.... Anyway it's somewhat beyond my understan= ding > > > > at this stage. The IBM x336 is a Xeon with EM64T. > > It's not an hardware problem, it's not related to the processor, just= to the=20 > > kernel configuration (both host and guest). > >=20 > > Make sure CONFIG_IA32_EMULATION is enabled on the host, and that you'= re=20 > > running a 32-bit UML kernel (to compile it on x86_64 host, replace AR= CH=3Dum=20 > > with ARCH=3Dum SUBARCH=3Di386). > >=20 > > And explain what was the configuration, I'm just curious how you got = this=20 > > situation... |