From: Rob L. <ro...@la...> - 2005-01-09 03:07:58
Attachments:
.config
|
I want to use UML because I'm building a little uclibc-based distro that has a problem when the system it's building on has a kernel older than the one it's building. I'm testing the build under knoppix (2.6.7 kernel) and building a C library against Maszur's 2.6.9 or 2.6.10 kernel headers, and as soon as I try to run any of the utilities linked against this under the old kernel, they segfault. Obvious solution: instead of doing a chroot for the second half of the build, fire up User Mode Linux built from the newer kernel. Unfortunately, it hasn't been that easy. Using the stock 2.6.9 and 2.6.10 kernels, I built a fairly stripped down version of UML (the config I just used for 2.6.10 is attached), and ran it against the root partition of my little "firmware linux" distro (uclibc based) like so: ./vmlinux rootfstype=hostfs rootflags=/home/knoppix/newbuild/build \ init=/bin/sh (A copy of that root partition is available on request; the bzipped tarball is about 12 megabytes. Or you could concievably build a "somewhat out of date but still shows the problem" version of it yourself from the stuff up on "http://www.landley.net/code/firmware". Yes this is a strange environment, it's a development system with gcc and binutils, but I replaced all the GNU utilities with busybox. Yes, I got it to work. Mostly. :) Under the UML built from stock 2.6.9 sources, after some tweaking I got it to sort of boot and give me a shell prompt about 1/3 of the time (the other 2/3 of the time it paniced during boot due to various race conditions, but trying it several times in a row usually got me to the shell prompt). I couldn't figure out any way to make it start with a readable hostfs by default, but "mount -o remount,rw / /" once it was up seemed to do the trick, and I can put that in an init script no problem. (And yes it worked: I could create files and have them show up in the host system.) But when trying to compile "hello world", gcc died saying it couldn't find ld. This exact filesystem worked fine chrooting into it on the host kernel, a knoppix system running 2.6.7. Gcc worked great, my whole distro can recompile itself under itself. (For the moment, I'm working around the problem that makes me want to use UML by using maszur's old 2.6.6 kernel headers to build uclibc against.) So I thought "ok, they'll fix it up in 2.6.10". My first attempt at building UML from that at work the build broke saying it had a duplicate symbol definition (even after make clean). Trying again with a clean tarball and not switching so much .config stuff off, I got a UML that worked enough to let me run it against a Red Hat Enterprise Server 2.1 partition I had lying around, which actually built a small software package successfully (if very, very slowly: a dual 3ghz pentium 4 compiling slower than my 700 mhz laptop). But it hung hard (and reproducibly, after a kill and a restart) when I tried to tab complete something in bash. Had to kill it from another window. Oh, and it always dumped a stack trace on bootup, right before it gave me a shell prompt. I don't know why. So now I'm trying it on my laptop. I compiled with the attached configuration (again, stock 2.6.10 source), ran it with a hostfs root partition pointing at my little uclibc system, and it panics on startup every time. So far, I've seen three different types of panics at different points in the boot process: mconsole (version 2) initialized on /home/knoppix/.uml/WGIHE3/mconsole audit: initializing netlink socket (disabled) audit(300.210:0): initialized Initializing Cryptographic API Kernel panic - not syncing: fix_range fixing wrong address space, current = 0xa0cb90a0 mconsole (version 2) initialized on /home/knoppix/.uml/0o1hM7/mconsole Kernel panic - not syncing: read of switch_pipe failed, errno = 9 And another one that's basically the second one with errno=0. What I haven't seen yet is the shell prompt. The host system (my laptop) has been steady as a rock for three months, it's not bad memory or anything. I'm guessing the 2.6.9 instabity might have been because I'm trying to use hostfs, but the panics I'm getting with 2.6.10 happen before it tries to mount the root partition. I'm probably doing something wrong, but I have no idea what. So my first question: Is there something other than the released kernel I should be trying? There used to be a seperate UML tree, but all I can find is 2.4, which doesn't interest me... Jeff's patch directory (which I found through his blog) is almost entirely x86-64 patches, and my laptop's x86. If I should be over on the -user list, I can do that, but I know exactly what I want to get this thing to do, and at this point expect to have to poke around in the code to get it to actually do it. I've read through tutorials on setting up virtual crossover cables and virtual hubs and it doesn't apply to me. I'm trying for a VERY simple setup: my UML doesn't need more networking than loopback, doesn't need swap, doesn't need module support... It doesn't need more than /dev/console attached to stdin and stdout, and enough of a root partition for me to compile stuff under it in a way that the syscalls made by a uclibc more recent than the kernel in the host system don't cause a problem. Rob |
From: Frank S. <fr...@tu...> - 2005-01-09 06:00:49
|
Rob Landley wrote: <snip> Rob, I may not be able to answer all your questions, but I may be able to offer a few pointers. For the UML kernel version, the stock 2.6.x kernel is getting better, but still isn't the most stable and reliable kernel. Right now, the most stable I've found is using 2.6.9 from kernel.org, with the -bb4 patches from http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/ There are several thing you can do to improve the speed at which the UML runs. When UML starts, it opens a file in /tmp (or somewhere else if TMPDIR is set), mmaps it, and uses that as its memory. To speed this up, make sure that it's located on a tmpfs-mounted filesystem (so it's real memory). fstab: none /UML/MEMORY tmpfs defaults,size=768M 0 0 Starting the UML: export TMPDIR=/UML/MEMORY /UML/linux ... Also, with an unpatched host kernel, your UML will run slower. If possible, patch the host kernel to allow UMLs to run in SKAS mode and take advantage of some SYSEMU code. These patches are also here: http://www.user-mode-linux.org/~blaisorblade/patchlist.html or you can get the 2.6.10 host patch from http://uml.tuxrocks.com/Patches/host-skas3-2.6.10-v7.patch I don't know much about hostfs, so I can't give any real ideas there. UML doesn't support TLS yet, so make sure that your UML root_fs doesn't have a /lib/tls directory. Hope this helps, Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University fr...@tu... |
From: Rob L. <ro...@la...> - 2005-01-09 23:08:30
|
On Sunday 09 January 2005 01:00 am, Frank Sorenson wrote: > I may not be able to answer all your questions, but I may be able to > offer a few pointers. > > For the UML kernel version, the stock 2.6.x kernel is getting better, > but still isn't the most stable and reliable kernel. Right now, the > most stable I've found is using 2.6.9 from kernel.org, with the -bb4 > patches from > http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/ Hmmm... Cool. Grabbed it, I'll try to look through it tonight to see what's already in 2.6.10 and what isn't... > There are several thing you can do to improve the speed at which the UML > runs. When UML starts, it opens a file in /tmp (or somewhere else if > TMPDIR is set), mmaps it, and uses that as its memory. To speed this > up, make sure that it's located on a tmpfs-mounted filesystem (so it's > real memory). Ah. Definitely a good thing to know, (and non-obvious, and not in any FAQ I've read yet). On the other hand, if I bundle up the firmware linux build process, I'm not really going to be able to control what environment it runs in. (That's kind of the point. I'm developing/testing it on knoppix as a reasonable minimal build environment.) I suppose I could mount tmpfs myself and set TMPDIR, but that assumes the script is being run as root and another benefit of using UML is getting away from the need to do that for chroot and mknod and such... I remember way way back, that there used to be a gross hack people would do to get shared memory (before shm), which was create a file somewhere, have all the processes that needed to share memory open the file, and then delete the file. That signalled the operating system to stop updating the on-disk copy. I wonder if that old hack (deleting the file signalling there's no rush about writing stuff back to the disk anymore, although it's still your backing store) still works? Why does it do this instead of just mallocing stuff, anyway? (Quick and dirty shared memory again?) > fstab: > none /UML/MEMORY tmpfs defaults,size=768M 0 0 > > Starting the UML: > export TMPDIR=/UML/MEMORY > /UML/linux ... > > > Also, with an unpatched host kernel, your UML will run slower. If > possible, patch the host kernel to allow UMLs to run in SKAS mode and > take advantage of some SYSEMU code. These patches are also here: > http://www.user-mode-linux.org/~blaisorblade/patchlist.html or you can > get the 2.6.10 host patch from > http://uml.tuxrocks.com/Patches/host-skas3-2.6.10-v7.patch I know. But once again, I'm tryng to use UML in hopes of being more portable and doing without root access. Patching the kernel defeats the point entirely, I might as well just tell people "you'll need to boot 2.6.10 to build this, and it needs to be run as root". I'm more interested in correctness than performance at the moment. As long as it WORKS, they can leave it running overnight for now... > I don't know much about hostfs, so I can't give any real ideas there. > UML doesn't support TLS yet, so make sure that your UML root_fs doesn't > have a /lib/tls directory. The knoppix host system does, but the build directory I'm giving it doesn't. Hmmm... I wonder what TLS _is_? Internationalization, I suspect. It seems unlikely knoppix would waste space on a second copy of libc for any other reason... > Hope this helps, Yes, actually. Thanks. :) > Frank Rob |
From: Blaisorblade <bla...@ya...> - 2005-01-10 14:41:24
|
On Sunday 09 January 2005 23:06, Rob Landley wrote: > On Sunday 09 January 2005 01:00 am, Frank Sorenson wrote: > > I may not be able to answer all your questions, but I may be able to > > offer a few pointers. > > > > For the UML kernel version, the stock 2.6.x kernel is getting better, > > but still isn't the most stable and reliable kernel. Right now, the > > most stable I've found is using 2.6.9 from kernel.org, with the -bb4 > > patches from > > http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/ > > Hmmm... Cool. Grabbed it, I'll try to look through it tonight to see > what's already in 2.6.10 and what isn't... > > There are several thing you can do to improve the speed at which the UML > > runs. When UML starts, it opens a file in /tmp (or somewhere else if > > TMPDIR is set), mmaps it, and uses that as its memory. To speed this > > up, make sure that it's located on a tmpfs-mounted filesystem (so it's > > real memory). > I remember way way back, that there used to be a gross hack people would do > to get shared memory (before shm), which was create a file somewhere, have > all the processes that needed to share memory open the file, and then > delete the file. Well, this is exactly what UML does... it actually deletes the file. > That signalled the operating system to stop updating the > on-disk copy. > I wonder if that old hack (deleting the file signalling there's no rush > about writing stuff back to the disk anymore, although it's still your > backing store) still works? Well, this is not simply answered... for *any* file, deleted or not, Linux caches the write requests... and it still needs to write the datas out to the disk, when the system has little memory. I also think that if the system is idle, Linux could write out the datas anyway (I don't know this well, but it's reasonable that the data are sync'd after enough time). Now, your question reduces to only this one: "Will Linux, without memory pressure but with CPU / disk pressure, start the cache writeout or not? " At this point, I don't know > Why does it do this instead of just mallocing stuff, anyway? (Quick and > dirty shared memory again?) Yes, as Henrik Nordstrom said. > > fstab: > > none /UML/MEMORY tmpfs defaults,size=768M 0 0 > > > > Starting the UML: > > export TMPDIR=/UML/MEMORY > > /UML/linux ... > > Also, with an unpatched host kernel, your UML will run slower. If > > possible, patch the host kernel to allow UMLs to run in SKAS mode and > > take advantage of some SYSEMU code. These patches are also here: > > http://www.user-mode-linux.org/~blaisorblade/patchlist.html or you can > > get the 2.6.10 host patch from > > http://uml.tuxrocks.com/Patches/host-skas3-2.6.10-v7.patch > I know. But once again, I'm tryng to use UML in hopes of being more > portable and doing without root access. Patching the kernel defeats the > point entirely, I might as well just tell people "you'll need to boot > 2.6.10 to build this, and it needs to be run as root". > I'm more interested in correctness than performance at the moment. As long > as it WORKS, they can leave it running overnight for now... Well, be careful... using TT mode can mean experiencing more UML bugs. > > I don't know much about hostfs, so I can't give any real ideas there. > > UML doesn't support TLS yet, so make sure that your UML root_fs doesn't > > have a /lib/tls directory. > The knoppix host system does, but the build directory I'm giving it > doesn't. He referred to the root_fs, i.e. in your case the directory you have as the root of the virtual system. > Hmmm... I wonder what TLS _is_? Internationalization, I suspect. Not at all! > It > seems unlikely knoppix would waste space on a second copy of libc for any > other reason... Well, the 1st copy on glibc runs with any kernel (2.4 and 2.6) and uses LinuxThreads for threading support. The 2nd copy, the one in /lib/tls, requires a 2.6 kernel, uses NPTL for threading support, and can give problems to some apps (including sometimes UML - but to get those problems, you need to link UML dinamically, while when TT mode is active it will link statically, and usually static link is done against non-NPTL glibc). Note: TLS = Thread Local Storage (one var, with TLS, can have a different value for each thread) NPTL = Next Generation Posix Threading. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Rob L. <ro...@la...> - 2005-01-11 07:12:04
|
On Monday 10 January 2005 09:43 am, Blaisorblade wrote: > I also think that if the system is idle, Linux could write out the datas > anyway (I don't know this well, but it's reasonable that the data are > sync'd after enough time). > > Now, your question reduces to only this one: > > "Will Linux, without memory pressure but with CPU / disk pressure, start > the cache writeout or not? " > At this point, I don't know There was some discussion of this on linux-kernel a few years back. That's where I first heard about it. There was an optimization in the linux kernel for this, but whether they were arguing to preserve the optimization or whether they were arguing to rip it out now that shm was in there, I don't remember... > > I know. But once again, I'm tryng to use UML in hopes of being more > > portable and doing without root access. Patching the kernel defeats the > > point entirely, I might as well just tell people "you'll need to boot > > 2.6.10 to build this, and it needs to be run as root". > > > > I'm more interested in correctness than performance at the moment. As > > long as it WORKS, they can leave it running overnight for now... > > Well, be careful... using TT mode can mean experiencing more UML bugs. I've noticed. :) On the other hand, I have a honking big test script to exercise it and a comparison case with stable behavior, and I'm happy to isolate differences between the two. I'll even happily attempt fixing them, which is not the same as knowing what I'm doing but when have I ever let that stop me? > > It > > seems unlikely knoppix would waste space on a second copy of libc for any > > other reason... > > Well, the 1st copy on glibc runs with any kernel (2.4 and 2.6) and uses > LinuxThreads for threading support. > > The 2nd copy, the one in /lib/tls, requires a 2.6 kernel, uses NPTL for > threading support, and can give problems to some apps (including sometimes > UML - but to get those problems, you need to link UML dinamically, while > when TT mode is active it will link statically, and usually static link is > done against non-NPTL glibc). > > Note: > TLS = Thread Local Storage (one var, with TLS, can have a different value > for each thread) > NPTL = Next Generation Posix Threading. Ah, that makes sense. NTPL, futexes, and all Ingo's new 2.6 threading work. (Various people keep threatening to glue NTPL to uclibc if we ever actually have another release. I still need to send Eric a cake for the one year anniversary of 0.9.26.) And knoppix is still going through a 2.4 kernel/2.6 kernel identity crisis, hence two libraries. Got it. (I also have a suse test environment on another machine, and upstairs there's an old fedora core I install, but right now I'm just trying to get it all to work on my laptop...) Rob |
From: Michael R. <mc...@sa...> - 2005-01-10 00:27:52
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Landley <ro...@la...> writes: Rob> I want to use UML because I'm building a little uclibc-based Rob> distro that has a problem when the system it's building on has Rob> a kernel older than the one it's building. I'm testing the I think you have a serious problem to begin with. Probably, you aren't building with the cross-compile headers, but rather with the host's headers, and maybe you are using the kernel headers rather than the uClibc headers. When building for a different libc, you'd be best to pretend that you are in fact building for a different CPU. I.e. build a whole cross-compile environment. Rob> Under the UML built from stock 2.6.9 sources, after some Rob> tweaking I got it to sort of boot and give me a shell prompt Rob> about 1/3 of the time (the other 2/3 of the time it paniced Rob> during boot due to various race conditions, but trying it Rob> several times in a row usually got me to the shell prompt). I 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 Rob> problem. (And yes it worked: I could create files and have Rob> them show up in the host system.) I use hostfs root all the time. I have no such problems. Rob> But when trying to compile "hello world", gcc died saying it Rob> couldn't find ld. This exact filesystem worked fine chrooting Rob> into it on the host kernel, a knoppix system running 2.6.7. Well, was ld actually there? Rob> mconsole (version 2) initialized on Rob> /home/knoppix/.uml/WGIHE3/mconsole audit: initializing netlink Rob> socket (disabled) audit(300.210:0): initialized Initializing Rob> Cryptographic API Kernel panic - not syncing: fix_range fixing Rob> wrong address space, current = 0xa0cb90a0 It sounds like your builds are really what is broken, not the root file system. Rob> cables and virtual hubs and it doesn't apply to me. I'm trying Rob> for a VERY simple setup: my UML doesn't need more networking Rob> than loopback, doesn't need swap, doesn't need module Yes, it does need swap if you intend to run gcc. 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. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mc...@xe... http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeHGxYqHRg3pndX9AQHxbwQAkZEnFOz0z4xxSB4XLVl6XXKJAk/vw4/w 48HCyCv/guKdwmZcwCYd3MFVyMood8aNSjlzfpETSjYvGTKqGR/cqJEn+4Urtara NX2N7kcN3DYPs3yW1g5QZ/kWoTQc/+sTV3BOC4mw2vGRga2W0VTRblCShnuvV/N2 v/szXnInqK4= =O7w2 -----END PGP SIGNATURE----- |
From: Henrik N. <um...@hn...> - 2005-01-10 01:53:57
|
On Sun, 9 Jan 2005, Rob Landley wrote: > I wonder if that old hack (deleting the file signalling there's no rush about > writing stuff back to the disk anymore, although it's still your backing > store) still works? Probably not. > Why does it do this instead of just mallocing stuff, anyway? (Quick and dirty > shared memory again?) It needs to be able to remap (including temporarily unmap) the memory freely, not only share it among several processes. > I'm more interested in correctness than performance at the moment. As long as > it WORKS, they can leave it running overnight for now... Just to give you alternatives, an alternative to UML is to use a emulator such as qemu. Personally I prefer UML, but using an emulator eleminates the need of the user to even have Linux to start with as the same image also works on Windows. Regards Henrik |
From: Rob L. <ro...@la...> - 2005-01-10 07:21:27
|
On Sunday 09 January 2005 07:05 pm, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Rob" == Rob Landley <ro...@la...> writes: > > Rob> I want to use UML because I'm building a little uclibc-based > Rob> distro that has a problem when the system it's building on has > Rob> a kernel older than the one it's building. I'm testing the > > I think you have a serious problem to begin with. > > Probably, you aren't building with the cross-compile headers, but > rather with the host's headers, and maybe you are using the kernel > headers rather than the uClibc headers. No, I'm using maritz maszur's kernel headers. Before I build uclibc I move the linux, sound, and asm (actually asm-$ARCH) directories from that into the uclibc source's include directory and then truncating extra/scripts/fix_includes.sh to zero bytes. As I said earlier, I have to use maszur's old 2.6.6 headers for this, even when the kernel I'm building is 2.6.9 or 2.6.10, because if I use newer ones the binaries linked with the resulting uclibc segfault when run under the 2.6.7 kernel in my knoppix host system. In case the web page I linked earlier was too much to wade through, here are the direct links to my build scripts from the end of the page. The first script does the equivalent of a heavily modified Linux From Scratch chapter 5, and the second one no longer has that much to do with chapter 6 but you can still sort of see it if you squint. http://www.landley.net/code/firmware/mktools.sh http://www.landley.net/code/firmware/build.sh > When building for a different libc, you'd be best to pretend that you > are in fact building for a different CPU. I.e. build a whole > cross-compile environment. Maybe I wasn't clear. My uclibc system works just fine as long as I chroot into it or boot into it with a normal (2.6) linux kernel. It can even recompile itself, entirely from source, under itself. Using user mode linux with it is what causes problems. If I run user mode linux with that exact same directory a hostfs root partition, it either hangs or malfunctions in numerous different ways, some of which seem to be race conditions and others are reproducible bad behavior which I have never once seen those exact same binaries exhibit when I chroot from the host kernel. Clear? This directory works just fine with chroot. It does not work with UML. > Rob> Under the UML built from stock 2.6.9 sources, after some > Rob> tweaking I got it to sort of boot and give me a shell prompt > Rob> about 1/3 of the time (the other 2/3 of the time it paniced > Rob> during boot due to various race conditions, but trying it > Rob> several times in a row usually got me to the shell prompt). I > 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 > Rob> problem. (And yes it worked: I could create files and have > Rob> them show up in the host system.) > > I use hostfs root all the time. > I have no such problems. Cool. I'd love to figure out what you're doing that I'm not, or vice versa. > Rob> But when trying to compile "hello world", gcc died saying it > Rob> couldn't find ld. This exact filesystem worked fine chrooting > Rob> into it on the host kernel, a knoppix system running 2.6.7. > > Well, was ld actually there? Did you read second sentence in the bit you just quoted? How, exactly, could I chroot into there and compile stuff if ld isn't there? I did, of course, check and make sure that ls and cat and such found ld in the UML environment, which they did. (The error message is actually collect2 can't find ld, although apparently gcc can find collect2.) I tried running gcc -v to see if I could get it to tell me what it was doing that didn't work (thinking possibly some environment variable was set wrong), and uclibc hung so badly I had to kill it from another window. "ld" is in both /bin/ld and /usr/bin/ld, since /bin is a symlink to /usr/bin. (And /sbin is a symlink to /usr/sbin, and /lib is a symlink to /usr/lib, and yes I needed to rip the gratuitous extra hardwired path out of collect2.c to make a unified lib directory work. That was months ago. And it works fine under the host kernel.) > Rob> mconsole (version 2) initialized on > Rob> /home/knoppix/.uml/WGIHE3/mconsole audit: initializing netlink > Rob> socket (disabled) audit(300.210:0): initialized Initializing > Rob> Cryptographic API Kernel panic - not syncing: fix_range fixing > Rob> wrong address space, current = 0xa0cb90a0 > > It sounds like your builds are really what is broken, not the root > file system. Yes. I agree with this. I'm not building user mode linux properly. The root filesystem works when I chroot into it instead of running uclibc against it. I would very much like to be able to build uclibc such that it works properly. I like the concept of this project, and want to use it. I just don't seem to know how to get it to work for me. There seems to be more to it than untar, make ARCH=um menuconfig, make ARCH=um, use resulting binary. Doing so sort of worked for me under 2.6.9: I got a shell prompt, at least the 1/3 of the time that the UML boot process survived the various race conditions, but when it did the applications (reliably and reproducibly) malfunctioned. Doing the same build under 2.6.10, I have yet to see a shell prompt on my laptop. I was hoping someone would see something obviously wrong from my .config... > Rob> cables and virtual hubs and it doesn't apply to me. I'm trying > Rob> for a VERY simple setup: my UML doesn't need more networking > Rob> than loopback, doesn't need swap, doesn't need module > > Yes, it does need swap if you intend to run gcc. A) Not to compile hello world it doesn't. I'm fairly certain that can still be done in 16 megs, even with a modern gcc. B) On my work machine, without swap, I compiled a whole c++ project. C) I've compiled this project on a machine with 32 megs of ram and no swap, and my laptop actually has 128 megs so if UML isn't giving itself at least 32 it's making a bad decision... And it isn't: Memory: 27808k available according to the bootup message. Hmmm... Interesting. Somebody said earlier that it's using /tmp instead of /dev/shm in hopes of getting shared memory. On knoppix, /tmp is a ramdisk. I wonder if that's confusing it...? (dmesg doesn't say the out of memory killer's getting triggered...) Interesting. Running it with "TMPDIR=." at the start of the command line, I got the same old panics the first three times (and it didn't try to allocate any more memory than before, presumably I need to tell it mem= for that), but on the fourth attempt it got farther than it ever has before, and instead of panicing it just hung. (Still didn't get my shell prompt, but oh well.) The tee output of four consecutive runs is attached. All I did each time was ctrl-c out of the hang, cursor up, change the number on out.txt, and hit return again. This is not the full range of failures to boot I've seen from this thing, by the way... The command line was: TMPDIR=. ../uml.sh 2>&1 | tee out.txt And uml.sh is (wordwrapped here, but not in the original): ./vmlinux rootfstype=hostfs rootflags=/home/knoppix/newbuild/build init=/bin/bash > 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. Is this a binary, or a build script? (Do you have a URL?) I'd really like to compile this thing from source since I already have the linux source tarball in my build processs anyway, to make the kernel for the final system. I'll happily applying patches for this different use if they fix the problems I'm having. Right now, it dosn't seem like anybody else has been seeing these problems, though, so I'd like to figure out what I'm doing wrong... Rob |
From: Rob L. <ro...@la...> - 2005-01-10 07:42:24
|
On Monday 10 January 2005 01:20 am, Rob Landley wrote: > I did, of course, check and make sure that ls and cat and such found ld in > the UML environment, which they did. (The error message is actually > collect2 can't find ld, although apparently gcc can find collect2.) I > tried running gcc -v to see if I could get it to tell me what it was doing > that didn't work (thinking possibly some environment variable was set > wrong), and uclibc hung so badly I had to kill it from another window. Ahem: uml is what hung so badly I had to kill it from another window. (Possibly just that ctrl-c doesn't work from an fd console. I've set it up like that to be scriptable, but I need to get it to work before I can script it...) I admit I may be hard to understand here. I'm relatively new to UML, and among other things I keep typing "uclibc" when I mean "UML". (Acronym overload, as usual. Never was that good with names...) Rob |
From: Henrik N. <um...@hn...> - 2005-01-10 08:48:22
|
On Mon, 10 Jan 2005, Rob Landley wrote: > Did you read second sentence in the bit you just quoted? How, exactly, could > I chroot into there and compile stuff if ld isn't there? Is the permissions on your hostfs tree set correctly? Can you execute ld manually? And again, have you tried with the -bb UML kernels? http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/ > C) I've compiled this project on a machine with 32 megs of ram and no swap, > and my laptop actually has 128 megs so if UML isn't giving itself at least 32 > it's making a bad decision... UML gives itself as much memory as you tell it to on the kernel command line. Default to 32 MB IIRC. Regards Henrik |
From: Rob L. <ro...@la...> - 2005-01-11 07:00:23
Attachments:
.config
|
On Monday 10 January 2005 03:48 am, Henrik Nordstrom wrote: > On Mon, 10 Jan 2005, Rob Landley wrote: > > Did you read second sentence in the bit you just quoted? How, exactly, > > could I chroot into there and compile stuff if ld isn't there? > > Is the permissions on your hostfs tree set correctly? Yup. I tried chown -R all the files to knoppix, and I tried running uml as root. No major difference I could spot. And again, it works fine via chroot. > Can you execute ld manually? Yes. > And again, have you tried with the -bb UML kernels? Just did. The result is much more stable than the previous one: it seems to boot up without error and give me a shell prompt reliably. Nice work. Attempting to actually _use_ still fails the same way: can't find ld. My first attempt I forgot to remount the hostfs rw and it went into an endless loop eating CPU until I killed it. I admit I had it set up wrong, but an endless loop probably isn't the correct behavior there... The second time I tried adding rw to the command line. Nice trick that, I was trying ,rw appended to the rootfs flags and it didn't work. Here's what happened then (with gratuitous wordwrap of long vmlinux command line provided by kmail): root@ttyp3[linux-2.6.9]# ./vmlinux rootfstype=hostfs rootflags=/home/knoppix/newbuild/build rw init=/bin/bash ... All bugs added by David S. Miller <da...@re...> SCTP: Hash tables configured (established 512 bind 1024) Initializing stdio console driver VFS: Mounted root (hostfs filesystem). bash-2.05b# ld ld: no input files bash-2.05b# gcc hello.c collect2: cannot find `ld' bash-2.05b# exit Then I chrooted into the directory: root@ttyp3[linux-2.6.9]# chroot ~knoppix/newbuild/build bash-2.05b# gcc hello.c bash-2.05b# ls -l a.out -rwxr-xr-x 1 root root 3447 Jan 10 23:41 a.out bash-2.05b# strip a.out bash-2.05b# ls -l a.out -rwxr-xr-x 1 root root 2164 Jan 10 23:41 a.out bash-2.05b# ./a.out Hello world! bash-2.05b# > http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/ Yup. Applied the big patch. It definitely helped stabilize things, just didn't fix this problem. > > C) I've compiled this project on a machine with 32 megs of ram and no > > swap, and my laptop actually has 128 megs so if UML isn't giving itself > > at least 32 it's making a bad decision... > > UML gives itself as much memory as you tell it to on the kernel command > line. Default to 32 MB IIRC. Of which 28 megs or so are free after the kernel grabs its structures, that matches what I'm seeing. That should definitely be enough to compile hello.c, and probably enough to run my whole build process. Here, try it for yourself. I just uploaded "http://www.landley.net/build.tar.bz2", which is 10.2 megabytes. It's what my build process from the earlier website results in. (Okay, a slightly more up to date version than the one on the website, but the differences don't matter for this.) There are a few other miscelanous components, but the bulk of it is uclibc, busybox, gcc, and binutils. "tar xvjpf build.tar.bz2" (as root) should extract the build directory with all the permissions intact, then you can chroot into it, drop a hello world executable in there (it's got busybox vi) and compile it with gcc. This should work. Then try doing the same thing with uml (as root, so as not to worry about permissions, or chown to taste if you're not up for that). This doesn't work for me. Attached is the config I used to build 2.6.9-bb4. The command line I used to run it was mentioned earlier in this message. > Regards > Henrik Rob |
From: Michael R. <mc...@sa...> - 2005-01-10 15:22:37
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Landley <ro...@la...> writes: Rob> My uclibc system works just fine as long as I chroot into it or Rob> boot into it with a normal (2.6) linux kernel. It can even Rob> recompile itself, entirely from source, under itself. Rob> Using user mode linux with it is what causes problems. If I Rob> run user mode linux with that exact same directory a hostfs Rob> root partition, it either hangs or malfunctions in numerous Rob> different ways, some of which seem to be race conditions and Rob> others are reproducible bad behavior which I have never once Rob> seen those exact same binaries exhibit when I chroot from the Rob> host kernel. Does it work with ./linux root=... init=/bin/sh ?? 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 $* Rob> But when trying to compile "hello world", gcc died saying it Rob> couldn't find ld. This exact filesystem worked fine chrooting Rob> into it on the host kernel, a knoppix system running 2.6.7. >> Well, was ld actually there? Rob> Did you read second sentence in the bit you just quoted? How, Rob> exactly, could I chroot into there and compile stuff if ld Rob> isn't there? Yes, but you are missing my point. It *COULD* be that due to a bug in hostfs that ld wasn't where it was supposed to be. Rob> I did, of course, check and make sure that ls and cat and such Rob> found ld in the UML environment, which they did. (The error Rob> message is actually collect2 can't find ld, although apparently Rob> gcc can find collect2.) I tried running gcc -v to see if I Yes, okay. 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. >> 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. ) >> 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 quickly. 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. 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. 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? >> 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. www.openswan.org/code/ 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. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mc...@xe... http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeKdjoqHRg3pndX9AQHKZwP/WgLnAry9eH6zWDvvnJ12obewUjNGe5X/ PZE+rrnHMhc67C2npNVF2DkiTv9KwCHAyx1aQPgaNmr/PjyCEES2YrbCxPPP42ed UG9lFmxAjyexlhuDEHbsA0UoOY4d1ILrOAEJOAKokWTwUhGLCq2yhlTUreEwHqvz GI51yz4ErXk= =ZzcU -----END PGP SIGNATURE----- |
From: Rob L. <ro...@la...> - 2005-01-10 07:35:28
|
On Sunday 09 January 2005 08:53 pm, Henrik Nordstrom wrote: > On Sun, 9 Jan 2005, Rob Landley wrote: > > I wonder if that old hack (deleting the file signalling there's no rush > > about writing stuff back to the disk anymore, although it's still your > > backing store) still works? > > Probably not. Might be worth a shot, though. (If I delete the file from userspace after launching UML, will it screw up anything?) > > I'm more interested in correctness than performance at the moment. As > > long as it WORKS, they can leave it running overnight for now... > > Just to give you alternatives, an alternative to UML is to use a emulator > such as qemu. Personally I prefer UML, but using an emulator eleminates > the need of the user to even have Linux to start with as the same image > also works on Windows. Yeah, I thought about that. Higher memory requirements, higher disk usage (need to feed it a partition or loopback file or something, not a shared directory like hostfs -- my high water mark of disk usage during the build is just under 370 megabytes, but I really don't want to have to depend on knowing that), dog slow, I'd need to build the kernel twice anyway (once on the parent system to have something for the emulator to run and once with the final system), more source code in the tarball, harder to integrate into the existing build process (with UML I can fire up a child that runs a script that can shutdown at the end so the parent script continues)... It's an option. I'd much rather figure out how to get UML to work... > Regards > Henrik Rob |
From: Blaisorblade <bla...@ya...> - 2005-01-10 13:45:17
|
On Monday 10 January 2005 07:34, Rob Landley wrote: > On Sunday 09 January 2005 08:53 pm, Henrik Nordstrom wrote: > > On Sun, 9 Jan 2005, Rob Landley wrote: > > > I wonder if that old hack (deleting the file signalling there's no rush > > > about writing stuff back to the disk anymore, although it's still your > > > backing store) still works? > > > > Probably not. > > Might be worth a shot, though. (If I delete the file from userspace after > launching UML, will it screw up anything?) You won't be able to delete it, because UML deletes the file by itself... (See my other mail for more details). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Nix <ni...@es...> - 2005-01-10 17:08:27
|
On Mon, 10 Jan 2005, Rob Landley yowled: > On Sunday 09 January 2005 08:53 pm, Henrik Nordstrom wrote: >> On Sun, 9 Jan 2005, Rob Landley wrote: >> > I wonder if that old hack (deleting the file signalling there's no rush >> > about writing stuff back to the disk anymore, although it's still your >> > backing store) still works? >> >> Probably not. > > Might be worth a shot, though. (If I delete the file from userspace after > launching UML, will it screw up anything?) UML does that itself. -- `Blish is clearly in love with language. Unfortunately, language dislikes him intensely.' --- Russ Allbery |
From: Rob L. <ro...@la...> - 2005-01-11 07:38:17
|
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 system). 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 > quickly. *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 started. 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. > www.openswan.org/code/ > > 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. Rob |
From: Henrik N. <um...@hn...> - 2005-01-11 11:27:46
|
On Tue, 11 Jan 2005, Rob Landley wrote: > 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. You are likely to experience less bugs using ubd than hostfs. > /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 > started. OK. You won't have any easy way of sending Control-C then. Try booting with the standard stdio console. Regards Henrik |
From: Michael R. <mc...@sa...> - 2005-01-11 21:34:42
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Landley <ro...@la...> writes: Rob> Chapter 5 of current variants of LFS uses the host system to Rob> create a toolchain you can chroot into and build the final Rob> system with. Then in chapter 6, you build the final system in I think the use of chroot is a cop-out. Rob> This requires root access (as does creating device nodes, Rob> mounting /proc or loopback devices... A rather large number of I use "fakeroot" to do all of that for embedded work that I do... all: mkdir -p ${ROOTDIR} fakeroot ${MAKE} EDTUDIR=${EDTUDIR} realall realall: echo Updating Symlinks @mkdir -p ${ROOTDIR} @mkdir -p ${ROOTDIR}/bin ${ROOTDIR}/sbin ${ROOTDIR}/etc ${ROOTDIR}/targa ${ROOTDIR}/dev ... echo Updating Binaries (cd ${EDTUDIR} && ${MAKE} PREFIX=${PREFIX} ROOTDIR=${ROOTDIR} EDTUDIR=. install ) ${MKFSJFFS2} --squash --eraseblock=128 --root=${ROOTDIR} --output=jffs2/jffs2.image --cvs-exclude -x rtime --big-endian Since the "mkfsjffs2" runs under the fakeroot as well, it gets all of the permissions and dev nodes, etc. Works like a charm, once one remembers to install fakeroot. (This customer has all of their stuff on SuSE 9.1. I use Debian) Rob> The second reason to use UML is that I compile a new C library Rob> (uclibc), link applications against it, and then run those Rob> applications. Even before the chroot, I'm running the new yes, it is good for testing. What I'm trying to get at, is that I strongly disagree with any "embedded" system that requires that you build "on" it. If you are trying to build GNOME 2.3 apps for RH 7.2... by ALL MEANS, UML is the tool for you.... Rob> difficult. If you're not careful, you suck in libm or libgcc Rob> and bang, they link in glibc. Even statically linking won't Yup. That's why I wouldn't want to run the build environment on the "target" >> 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 quickly. Rob> *shrug*. How much memory I need to build correctly is an Rob> interesting thing to find out later, but right now it won't Rob> compile hello world and 32 megs should be plenty for that. (I Rob> can try mem=64M if you think that'll help.) dd if=/dev/zero bs=1024k count=64 of=MYSWAP ./linux ubd1=./MYSWAP 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? Rob> /dev/console attaches to fd0 and fd1. These are not ttys/ptys Rob> but file descriptors, hence they controlling tty sends the kill Well, usually, once the system is properly initialized, ^C does nothing. If you get a kernel panic/hang, I usually have to use kill from another window. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mc...@xe... http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeRGXoqHRg3pndX9AQGUDQQA0dPnJzBz/5ifSpGjmaTcfNNNtYlugzUE 7m2hb0DXUb2kKgrrLrawXxckSh2NFLclgA2h29k8SQHFD1JWTl/AmPT52tmcIVhD hW3YBqh+hm0wuuckBZ4B2vsoobLtfvMxTRROLs5OXaZvMjxg7fwLfdmDEM1g4S4E fbcuI/S8FoM= =5OC4 -----END PGP SIGNATURE----- |
From: Blaisorblade <bla...@ya...> - 2005-01-11 23:21:01
|
On Tuesday 11 January 2005 22:34, Michael Richardson wrote: > >>>>> "Rob" == Rob Landley <ro...@la...> writes: > > Rob> Chapter 5 of current variants of LFS uses the host system to > Rob> create a toolchain you can chroot into and build the final > Rob> system with. Then in chapter 6, you build the final system in > > I think the use of chroot is a cop-out. > > Rob> This requires root access (as does creating device nodes, > Rob> mounting /proc or loopback devices... A rather large number of > > I use "fakeroot" to do all of that for embedded work that I do... What's this? > dd if=/dev/zero bs=1024k count=64 of=MYSWAP Please add a "mkswap MYSWAP" here (or even inside the guest, mkswap /dev/ubd1). > ./linux ubd1=./MYSWAP > > 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? > Rob> /dev/console attaches to fd0 and fd1. These are not ttys/ptys > Rob> but file descriptors, hence they controlling tty sends the kill > Well, usually, once the system is properly initialized, ^C does > nothing. If you get a kernel panic/hang, I usually have to use kill from > another window. Yes, that's because it turns the console to raw mode (don't ask me why). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Michael R. <mc...@sa...> - 2005-01-12 16:55:11
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Blaisorblade" == Blaisorblade <bla...@ya...> writes: Rob> Chapter 5 of current variants of LFS uses the host system to Rob> create a toolchain you can chroot into and build the final Rob> system with. Then in chapter 6, you build the final system in >> I think the use of chroot is a cop-out. Rob> This requires root access (as does creating device nodes, Rob> mounting /proc or loopback devices... A rather large number of >> I use "fakeroot" to do all of that for embedded work that I do... Blaisorblade> What's this? A tool which LD_PRELOAD's a library that intercepts all calls that require root, and "emulates" them. I.e. if a program does "chown(2)", it just remembers that this occured, and when a stat() is made, it returns the "right" answer. (so tar/mkjffs, etc. get the right answer) Used in debian a lot. http://packages.debian.org/testing/utils/fakeroot Blaisorblade> Yes, that's because it turns the console to raw mode (don't ask me why). Because, you'd like to have ^C get passed to the program being run under the UML :-) - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeVWY4qHRg3pndX9AQEH/wQA1Hkp7/41q61Oh4razESw6WHAmLMiXseB I8TGHI10/o55F8iqN0ePZHOzKFnOxw75/8J10RiPdTWWGnqn3wUh3Fx4LXyzG0Hy /T/YWIErJwc8G7Y5aJrltehTHdtudEKei0Wei99EiCo65JPczSVBY8ZHFYae/wLR 2ueRvZlyZzs= =VIrB -----END PGP SIGNATURE----- |
From: Blaisorblade <bla...@ya...> - 2005-01-12 17:07:11
|
On Wednesday 12 January 2005 17:55, Michael Richardson wrote: > >>>>> "Blaisorblade" == Blaisorblade <bla...@ya...> writes: > > Rob> Chapter 5 of current variants of LFS uses the host system to > Rob> create a toolchain you can chroot into and build the final > Rob> system with. Then in chapter 6, you build the final system in > >> I think the use of chroot is a cop-out. > Rob> This requires root access (as does creating device nodes, > Rob> mounting /proc or loopback devices... A rather large number of > >> I use "fakeroot" to do all of that for embedded work that I do... > Blaisorblade> What's this? > A tool which LD_PRELOAD's a library that intercepts all calls that > require root, and "emulates" them. > I.e. if a program does "chown(2)", it just remembers that this > occured, and when a stat() is made, it returns the "right" answer. > (so tar/mkjffs, etc. get the right answer) Ah, ok... this means it cannot work onto UML, actually (unless you dinamically link it - which is not the common case...). > Used in debian a lot. > http://packages.debian.org/testing/utils/fakeroot > Blaisorblade> Yes, that's because it turns the console to raw mode > (don't ask me why). > Because, you'd like to have ^C get passed to the program being run > under the UML :-) Ah, well, yes, but that happens when you use /dev/tty0 as console inside UML (and I don't do it). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |