On Monday 10 January 2005 10:21 am, Michael Richardson wrote:
> Does it work with
> ./linux root=... init=/bin/sh
Don't have a real partition to mount it on, unless I want to cannibalize the
host system's swap. I could try ubd if you think it would help.
> Rob> couldn't figure out any way to make it start with a readable
> Rob> hostfs by default, but "mount -o remount,rw / /" once it was up
> Rob> seemed to do the trick, and I can put that in an init script no
> You want to add the 'rw' flag to your boot line.
> This is what "make uml" on the openswan tree creates:
> /mara4/openswan-2/asyncklips/UMLPOOL/east/linux root=/dev/root
> rootfstype=hostfs rootflags=/mara4/openswan-2/asyncklips/UMLPOOL/east/root
> rw umid=east $net $UML_DEBUG_OPT $UML_east_OPT $*
Neat trick. As I mentioned earlier, I tried it and it worked. (I was using
rootflags=blah/blah/blah,rw thinking it was like remount. Gave an
interesting panic that took a lot of printfs to figure out, but the ability
to stick printfs into the kernel is half the fun of UML...)
> Rob> could get it to tell me what it was doing that didn't work
> Rob> (thinking possibly some environment variable was set wrong),
> Rob> and uclibc hung so badly I had to kill it from another window.
> I suggest you might want to build a static copy of "strace" to run
> under the build environment.
Yeah, that's a to-do item of mine. I was a bit concerned about running strace
under a ptraced emulation environment, but guess it all has to nest and stack
nicely or it would never work in the first place. (Just as long as I'm not
the one who has to keep it all straight... :)
> >> It sounds like your builds are really what is broken, not the
> >> root file system.
> Rob> Yes. I agree with this. I'm not building user mode linux
> Rob> properly. The root filesystem works when I chroot into it
> Rob> instead of running uclibc against it.
> As I understand it, you are building a rootfs so that you can
> "natively" build for your target environment.
> (I do not understand why this is necessary. )
A previous incarnation of my build script started life years ago as a big
shell script automating a Linux From Scratch installation (back around LFS
3.0 or so). The current version is sort of based on LFS 5.0, heavily
mutated. (Another to-do item of mine is to rebase it on 6.0, or at least
update all the packages and figure out how to shoehorn udev into this thing).
Chapter 5 of current variants of LFS uses the host system to create a
toolchain you can chroot into and build the final system with. Then in
chapter 6, you build the final system in a chroot environment that contains
just the toolchain you build in chapter 5.
My build script currently drops a "here" document into a directory and runs it
when it needs the chroot environment. This requires root access (as does
creating device nodes, mounting /proc or loopback devices... A rather large
number of system administration things you kind of have to do to make a linux
The first reason to use UML is to get away from the need to run build.sh (a
large complicated script that does many dangerous things) as root. But in
theory, I could use the fakeroot package for that.
The second reason to use UML is that I compile a new C library (uclibc), link
applications against it, and then run those applications. Even before the
chroot, I'm running the new applications I compile because I put them at the
start of the path. (This is intentional, the new compiler naturally links
against the new c library, and getting the old compiler to link against the
correct libraries (not just the C library itself but other libraries that
link to the C library) is chronically difficult. If you're not careful, you
suck in libm or libgcc and bang, they link in glibc. Even statically linking
won't always help here because glibc dlopens libnss at runtime, at which
point things just get ugly...)
The problem is that I want to compile the new C library against new kernel
headers. If I'm building a 2.6.10 kernel for the final system, I want the
libc to use maszur's cleaned up 2.6.10 kernel headers. But the available
features of the kernel (not just the syscalls the C library can make but all
sorts of details like 16 bit or 32 bit uids) are defined in the kernel
headers. Linux is backwards compatible in that old application binaries can
run on new systems, but it does NOT go the other way. And thus applications
that link against the new libc, with new kernel headers, segfault if you run
them on a system that uses an older kernel than the headers the libc was
built against. (Because they try to use new kernel features that don't exist
in that kernel.)
> >> Yes, it does need swap if you intend to run gcc.
> Rob> A) Not to compile hello world it doesn't. I'm fairly certain
> Rob> that can still be done in 16 megs, even with a modern gcc. B)
> well, I run into this problem regularly whenever I do anything
> complicated. I don't build with swap by default, and I run out very
*shrug*. How much memory I need to build correctly is an interesting thing to
find out later, but right now it won't compile hello world and 32 megs should
be plenty for that. (I can try mem=64M if you think that'll help.)
> Rob> Interesting. Somebody said earlier that it's using /tmp
> Rob> instead of /dev/shm in hopes of getting shared memory. On
> Rob> knoppix, /tmp is a ramdisk. I wonder if that's confusing
> Rob> it...? (dmesg doesn't say the out of memory killer's getting
> Rob> triggered...)
> I have /tmp be a ramdisk all the time.
This laptop only has 128 megs and I've got a desktop up with a web browser.
It'll get a little unhappy. But if I left the swap file do its job and don't
try to do anything while it runs, it shouldn't be too bad...
> Rob> Interesting. Running it with "TMPDIR=." at the start of the
> Rob> command line, I got the same old panics the first three times
> Rob> (and it didn't try to allocate any more memory than before,
> Rob> presumably I need to tell it mem= for that), but on the fourth
> Rob> attempt it got farther than it ever has before, and instead of
> Rob> panicing it just hung. (Still didn't get my shell prompt, but
> Rob> oh well.)
> Hmm. random huh.
Reverting to 2.6.9-bb4 at least made the randomness go away. This is a good
thing. (I could probably debug it from here myself given a few weeks...)
> Rob> The tee output of four consecutive runs is attached. All I did
> Rob> each time was ctrl-c out of the hang, cursor up, change the
> You could hit ^C from a hang?
/dev/console attaches to fd0 and fd1. These are not ttys/ptys but file
descriptors, hence they controlling tty sends the kill signal to the running
process still attached to that terminal, which is the vmlinux instance I
Once UML starts init, it seems to register a signal handler or something...
As I said, good for scripting, not so good for debugging. Some of the hangs
I'm seeing are almost certainly a stuck process I can't ctrl-C out of and
have to kill from another window...
> >> I suggest that you might want to try the UML image system in the
> >> Openswan builds. It generates everything you need. It has been
> >> used with 2.6.9+ guests, on 2.4 and 2.6 hosts.
> Rob> Is this a binary, or a build script? (Do you have a URL?)
> Build script.
> Get yourself 500Mb of disk space,
> cp testing/utils/umlsetup-sample.sh umlsetup.sh
> vi umlsetup.sh
> make uml
> You need to set "KERN=26" if using a 2.6 kernel.
Sounds cool. On the to-do list. Thanks.