On Tuesday 19 July 2005 00:36, Phill Wombat wrote: > Oops sent it directly to you. Here it is via the list... > > Cheers > Phill. > > -------- Forwarded Message -------- > > > From: Phill Wombat <[EMAIL PROTECTED]> > > To: Blaisorblade <[EMAIL PROTECTED]> > > Subject: Re: [uml-user] x86_64 UML won't boot on IBM x336 > > Date: Tue, 19 Jul 2005 08:27:50 +1000 > > > > Hi Paolo, > > > > Firstly, allow me to compliment you on the quality of your English, I > > assume you're a native Italian speaker. Thanks a lot, but sadly it isn't so bad when it's spoken English, especially when I try to understand... I'm experiencing this right now at the KernelSummit. > > I'm sure there's a story just > > there... > > > > ====================================== > > FC4 under UML on 32 bit: > > > > 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). > > > > 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 shutdown > > obviously). > > > > Thirdly, comment out: > > > > #session required pam_loginuid.so > > > > 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 create > > a session for you. > > > > 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. > > > > That's where I am right now. I have really run anything with it yet, but > > so far so good. > > ==================================== > > > > The kernel on x86_64: > > > > 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=i386. I tried it but it wouldn't compile, so I sort of hoped > > it would just be a 32 bit kernel hosted on x86_64 :(
> > It seems pretty clear from your post that I have to have a clean compile > > with SUBARCH=i386. Ok, now everything is clear... that message didn't make sense a lot of sense in a situation other than this, which I supposed you weren't using. UML/64 will support in some future moment 32-bit fs but it doesn't right now. About compilation, that command should work starting from 2.6.12-bs3 (but for other issues go directly to -bs7), but before you should clean the tree with mrproper (after saving the .config). Also, it may work or not depending on the host distro, and on whether compatibility headers are installed... > > 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. Yes, it should work. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
