From: Robbie D. <ro...@mi...> - 2003-12-11 19:27:51
|
Hi all, I would like to report some problems I have been having with UML and a work around I discovered when using a root filesystem based on a SuSE distribution. I am sorry this mail is so long. I have been sucessfully using UML for some time, but with a rather old kernel based on 2.4.20 . I wanted to try a more recent kernel, preferably one that doesn't suffer from the recent security problems. I can't remember exactly what sources the working 2.4.20 kernel was based on, but it might be http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.4.20-6.bz2 However I have had problems finding a more recent kernel that I can use, either pre-compiled, or one that I compile myself. I have two root file system images that I use. They are both based on SuSE distributions. One is based on SuSE 8.1 and was 'hand crafted' by me. The other is based on SuSE 9.0 and and was built using the uml-install-suse script supplied by SuSE in their uml-utilities-20030903-12 RPM package (actually it might be an improved version provided by Gerr Knorr). I build the SuSE 9.0 based image like so: $ uml-install-suse --selection Minimal \ --media /media/cdrom/ --languages en_GR From what I can tell, there does not seem to be any difference in behaviour between the two root images. I carry out a test with one image, then repeat the test with the other image, there does not seem to be much difference between the two. I first tried to use the precompiled UML kernel provided by SuSE in the host-k_um-2.4.21-144 RPM . I am running on a host using the SuSE 9.0 with a 2.4.21-144 host (not user mode) kernel. The user mode kernel hung during boot. I run the UML on the host like so: /usr/bin/linux-2.4.21-144-um root=/dev/ubd0 \ ubd0=root.img ubd1=swap.img \ eth0=tuntap,tap1,fe:fd:0a:07:ad:fc,10.7.230.34 \ con0=fd:0,fd:1 con=null ssl=null mem=128M \ umid=robbie 1 The last few lines that were printed on the console are: --------------------------- Partition check: ubda: unknown partition table ubdb: unknown partition table Initializing stdio console driver Netdevice 0 (fe:fd:0a:07:ad:fc) : TUN/TAP backend - IP = 10.7.230.34 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 16384) Linux IP multicast router 0.06 plus PIM-SM VFS: Mounted root (ext2 filesystem) readonly. ---------------------------- At this point one of the UML processes on the host machine is eating 99% of the CPU cycles. I can run up uml_mconsole and do a sysrq to do a print of the running processes like so ---------------------------- robbie@linux:~> uml_mconsole robbie (robbie) sysrq t OK (robbie) ---------------------------- This produces the following output to the console con0 ---------------------------- SysRq : Show State free sibling task PC stack pid father child younger older init R current 8572 1 0 8 (NOTLB) keventd S A0169691 13336 2 1 3 (L-TLB) ksoftirqd_CPU S A0169691 13368 3 1 4 2 (L-TLB) kswapd S A0169691 13384 4 1 5 3 (L-TLB) bdflush S A0169691 13304 5 1 6 4 (L-TLB) kupdated S A0169691 13320 6 1 7 5 (L-TLB) kinoded S A0169691 13352 7 1 8 6 (L-TLB) mdrecoveryd S A0169691 13332 8 1 7 (L-TLB) ---------------------------- If I type into the uml_mconsole program, the UML kernel keeps running and the uml_mconsole program hangs. I have to kill off each of the UML processes on the host and the uml_mconsole with a kill -9 <pid>. At this point I abandoned trying the prebuilt kernel and tried the latest patch available from the UML sourceforge site: http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.4.22-6.bz2 I applied the above patch, then edited the top level Makefile in two places to change CFLAGS from -O2 to -O1 . (I read in a HOWTO, possibly writen by Gerr Knorr (?), that changing CFLAGS to -O1 was a good idea, but I have no idea why.) Then I did a make ARCH=um menuconfig make ARCH=um dep linux When configuring the kernel, I choose to disable modules. I use this new 2.4.22-6 user mode kernel like so: ~/bin/linux-2.4.22-6um root=/dev/ubd0 \ ubd0=root.img ubd1=swap.img \ eth0=tuntap,tap1,fe:fd:0a:07:ad:fc,10.7.230.34 \ con0=fd:0,fd:1 con=null ssl=null mem=128M \ umid=robbie s Note I start the UM kernel in single user mode (s). The machine comes up and I get a root shell prompt (yes !) But then I run telinit 3 on the UML machine and the machine hangs while trying to change run level. There are lots of spare CPU cycles, 99% _idle_. Here are the last few lines printed on the console: ------------------------------- Give root password to login: linux-uml:~ # telinit 3 INIT: Switching to runlevel: 3 INIT: Sending processes the TERM signal INIT: Sending processes the KILL signal ------------------------------- At this point I can type a 'sysrq t' command at the uml_mconsole program. I get the following printed on the UML console: ------------------------------- SysRq : Show State free sibling task PC stack pid father child younger older init S 40029836 9992 1 0 281 (NOTLB) keventd S 40029836 13272 2 1 3 (L-TLB) ksoftirqd_CPU S 40029836 13352 3 1 4 2 (L-TLB) kswapd S 40029836 13352 4 1 5 3 (L-TLB) bdflush S 40029836 13336 5 1 6 4 (L-TLB) kupdated S 40029836 11816 6 1 266 5 (L-TLB) rc S 40029836 10408 266 1 304 281 6 (NOTLB) blogd S 40029836 4 281 1 283 266 (NOTLB) blogd S 40029836 2588 283 281 287 (NOTLB) blogd S 40029836 10780 287 283 (NOTLB) S05network S 40029836 916 304 266 (NOTLB) -------------------------------- Ok, here is the work around I promised. You halt the UML machine using the uml_mconsole program and restart it in single user mode You make the root filesystem read/write, new do: $ mv /sbin/blogd /sbin/blogd.disable Now you can start the UML machine with any runlevel and it comes up without hanging. I have no idea why this works. I am not even sure what blogd does, I arrived here by a process of trial and error. If anyone can offer any incite, I would appreciate it. Robbie Dinn (robbie at microbus dot com ) |
From: Jeff D. <jd...@ad...> - 2003-12-18 21:17:09
|
On Thu, Dec 11, 2003 at 07:27:40PM +0000, Robbie Dinn wrote: > I have two root file system images that I use. They are both > based on SuSE distributions. One is based on SuSE 8.1 and was > 'hand crafted' by me. The other is based on SuSE 9.0 and and > was built using the uml-install-suse script supplied by SuSE in > their uml-utilities-20030903-12 RPM package (actually it might be > an improved version provided by Gerr Knorr). Can you put one of the failing images somewhere so I can grab it and see this for myself? Jeff |
From: roland <for...@gm...> - 2003-12-18 21:29:48
|
i`m interested in an 8.1 root_fs image for testing purpose, too. regards roland ----- Original Message ----- From: "Jeff Dike" <jd...@ad...> To: "Robbie Dinn" <ro...@mi...> Cc: <use...@li...> Sent: Thursday, December 18, 2003 10:32 PM Subject: Re: [uml-user] troubles with recent uml kernels > On Thu, Dec 11, 2003 at 07:27:40PM +0000, Robbie Dinn wrote: > > I have two root file system images that I use. They are both > > based on SuSE distributions. One is based on SuSE 8.1 and was > > 'hand crafted' by me. The other is based on SuSE 9.0 and and > > was built using the uml-install-suse script supplied by SuSE in > > their uml-utilities-20030903-12 RPM package (actually it might be > > an improved version provided by Gerr Knorr). > > Can you put one of the failing images somewhere so I can grab it and see > this for myself? > > Jeff > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Robbie D. <ro...@mi...> - 2003-12-19 16:18:49
|
Jeff, Roland STOP PRESS I have just realised I have made an idiot of myself. What I was reporting as a SuSE 9.0 image is in fact an image based on SuSE 8.2 . Sorry. Otherwise what I have said still stands. I can make a 9.0 image if you need one. STOP PRESS I have put the disk images and a few other relevant files in: http://downloads.microbus.com/uml-user-list-stuff/suse-9.0/ http://downloads.microbus.com/uml-user-list-stuff/suse-8.1/ There is a SuSE 9.0 image (one single root image) The SuSE 8.1 images are root image + /usr image There are also a script that I used to create a SuSE-8.1 image from the distribution media. Both these images have '/sbin/blodg' moved out of the way, so to see the fault you want to run '/sbin/blogd.disable' I found that it was instructive to run the folllowing on the UML machine: strace /sbin/blogd.disable From the strace, it seems to involve /dev/ptmx and files in /dev/pts/ but I don't really understand what is going on. Here is what the strace looks like on SuSE 9.0 ... ---------------------------------------------- Welcome to SuSE Linux 8.2 (i586) - Kernel 2.4.22-6um (console). ^^^ ahhhh! I thought this was 9.0 ! - robbie linux-uml login: root Password: Last login: Fri Dec 19 13:28:14 on console Have a lot of fun... linux-uml:~ # strace -ff /sbin/blogd.disable execve("/sbin/blogd.disable", ["/sbin/blogd.disable"], [/* 35 vars */]) = 0 uname({sys="Linux", node="linux-uml", ...}) = 0 brk(0) = 0x805d360 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=7443, ...}) = 0 old_mmap(NULL, 7443, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\16\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=11004, ...}) = 0 old_mmap(NULL, 10700, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000 mprotect(0x40019000, 2508, PROT_NONE) = 0 old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x100 0) = 0x40019000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pY\1\000"..., 1024) = 10 24 fstat64(3, {st_mode=S_IFREG|0755, st_size=1491599, ...}) = 0 old_mmap(NULL, 1268004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001a000 mprotect(0x40149000, 26916, PROT_NONE) = 0 old_mmap(0x40149000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12 f000) = 0x40149000 old_mmap(0x4014d000, 10532, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON YMOUS, -1, 0) = 0x4014d000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0 x40150000 munmap(0x40015000, 7443) = 0 ioctl(0, TCGETS, {B9600 opost isig icanon echo ...}) = 0 brk(0) = 0x805d360 brk(0x805e360) = 0x805e360 brk(0) = 0x805e360 brk(0x805f000) = 0x805f000 readlink("/proc/self/fd/0", "/dev/console", 4095) = 12 rt_sigaction(SIGTTIN, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTTOU, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x8049500, [INT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x8049500, [QUIT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8049500, [TERM], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, NULL, {0x8049500, [INT], SA_RESTART|0x4000000}, 8) = 0 rt_sigaction(SIGINT, {0x8049500, [INT], SA_RESTART|0x4000000}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {0x8049500, [QUIT], SA_RESTART|0x4000000}, 8) = 0 rt_sigaction(SIGQUIT, {0x8049500, [QUIT], SA_RESTART|0x4000000}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {0x8049500, [TERM], SA_RESTART|0x4000000}, 8) = 0 rt_sigaction(SIGTERM, {0x8049500, [TERM], SA_RESTART|0x4000000}, NULL, 8) = 0 getppid() = 369 getpid() = 370 ioctl(0, 0x80045432, 0xbffff6b8) = -1 EINVAL (Invalid argument) write(2, "blogd.disable: Warning: the ioct"..., 70blogd.disable: Warning: the io ctl TIOCGDEV is not known by the kernel ) = 70 ioctl(0, TCGETS, {B9600 opost isig icanon echo ...}) = 0 readlink("/proc/self/fd/0", "/dev/console", 4095) = 12 getpgid(0x172) = 369 getpgid(0x171) = 369 open("/proc/370/stat", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, FIONREAD, [0]) = 0 select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0}) read(3, "370 (blogd.disable) R 369 369 35"..., 256) = 182 close(3) = 0 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory ) open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=61440, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 brk(0) = 0x805f000 brk(0x8060000) = 0x8060000 brk(0) = 0x8060000 brk(0x8061000) = 0x8061000 getcwd("/root", 4096) = 6 chdir("/dev") = 0 getdents64(0x3, 0x805e3e8, 0x1000, 0x16) = 4080 lstat64("3dfx", {st_mode=S_IFCHR|0660, st_rdev=makedev(107, 0), ...}) = 0 lstat64(":0", {st_mode=S_IFLNK|0777, st_size=4, ...}) = 0 readlink(":0", "tty0", 4096) = 4 lstat64("tty0", {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 0), ...}) = 0 getcwd("/dev", 4091) = 5 chdir("/root") = 0 close(3) = 0 open("/dev/tty0", O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 3 fcntl64(3, F_GETFL) = 0x8801 (flags O_WRONLY|O_NONBLOCK|O_LA RGEFILE) fcntl64(3, F_GETFL) = 0x8801 (flags O_WRONLY|O_NONBLOCK|O_LA RGEFILE) ioctl(3, TCGETS, {B9600 opost isig icanon echo ...}) = 0 ioctl(3, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0 open("/dev/ptmx", O_RDWR) = 4 statfs("/dev/pts", {f_type="DEVPTS_SUPER_MAGIC", f_bsize=1024, f_blocks=0, f_bfr ee=0, f_files=0, f_ffree=0, f_namelen=255}) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(4, TIOCGPTN, [0]) = 0 stat64("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 statfs("/dev/pts/0", {f_type="DEVPTS_SUPER_MAGIC", f_bsize=1024, f_blocks=0, f_b free=0, f_files=0, f_ffree=0, f_namelen=255}) = 0 ioctl(4, TIOCSPTLCK, [0]) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(4, TIOCGPTN, [0]) = 0 stat64("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 open("/dev/pts/0", O_RDWR|O_NOCTTY) = 5 ioctl(5, TCSETSF, {B38400 opost isig icanon echo ...}) = 0 ioctl(5, TIOCSWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(0, TIOCCONS) = 0 ioctl(5, TIOCCONS ^ | hung here ----------------------------------------------------------- For what it is worth, my host kernel is 2.4.21-rc3 with ebtables and netfilter patch-o-matic patches applied. roland wrote: > i`m interested in an 8.1 root_fs image for testing purpose, too. > regards > roland > > > ----- Original Message ----- > From: "Jeff Dike" <jd...@ad...> > To: "Robbie Dinn" <ro...@mi...> > Cc: <use...@li...> > Sent: Thursday, December 18, 2003 10:32 PM > Subject: Re: [uml-user] troubles with recent uml kernels > > > >>On Thu, Dec 11, 2003 at 07:27:40PM +0000, Robbie Dinn wrote: >> >>>I have two root file system images that I use. They are both >>>based on SuSE distributions. One is based on SuSE 8.1 and was >>>'hand crafted' by me. The other is based on SuSE 9.0 and and >>>was built using the uml-install-suse script supplied by SuSE in >>>their uml-utilities-20030903-12 RPM package (actually it might be >>>an improved version provided by Gerr Knorr). >> >>Can you put one of the failing images somewhere so I can grab it and see >>this for myself? >> >>Jeff >> |