Bug#399328: linux-patch-skas: user-mode-linux seems to not work on 2.6.18 patched with this package
On Friday 24 November 2006 15:50, Peder Chr. Nørgaard wrote: I have a correction to the original report; well, the report is correct, but I had made a mistake, which I corrected with no effect to the problem. I am not running this on a -686 CPU, but on an AMD Athlon, so I should really use -k7 kernels all the way through. So I switched to a mainstream -k7 kernel and a home-built -k7 kernel with SKAS; no changes, works fine on mainstream kernel, but the bug is still when SKAS patch is added to host system. So the problem *may* theoretically be local to the fact that I am using an AMD Athlon CPU; I just don't think that is very likely. If I can, I will try it out on a Pentium-based computer. Hello. I have now got my hands on a Pentium-based computer, and, to my big surprise, the problem is *not* manifest on the Pentium-based PC. Let me recapture: the problem is, that linux 2.6.18 kernel patched with the skas patch distributed by Debian package linux-patch-skas (which is really just the skas patch from blaisorblade's workshop) does not work with the (x86-variant agnostic) user-mode-linux distributed by Debian. The user-mode-linux hangs consistently somewhere in the boot process, described in a little more detalins in my original report. But I have only observed the problem on my AMD Athlon XP 2200+; today, when I try to do the same thing on an Intel Pentium (it is a Pentium M) it works just fine. Whether it works on the AMD or not has nothing to do with whether I build the host kernel as -686 or -k7 - the problem is manifest in both cases. So it is related to the chip rather than to the compilation, I think. So it seems that the problem is local to both 2.6.18 *and* the AMD Athlon CPU; I realize that this does not exactly makes it easier to figure out what happens. Please, if I can be of any assistance, tell me how. The problem is easy to reproduce, and even though I don't know much about the internals of user-mode-linux - I am just a happy user of user-mode-linux for testing and similar purposes - I do now a little about how to drive a gdb around in a guest kernel. If someone would tell me what to look for, I might be able to figure out at least where in the boot sequence the guest is hanging best regards -- Peder Chr. Nørgaard e-mail: [EMAIL PROTECTED] Gefionsvej 19 spejder-e-mail: [EMAIL PROTECTED] DK-8230 Åbyhøj tel: +45 87 44 11 99 Denmark mob: +45 30 91 84 31
Bug#399328: linux-patch-skas: user-mode-linux seems to not work on 2.6.18 patched with this package
On Friday 24 November 2006 14:54, Stefano Melchior wrote: On Sun, Nov 19, 2006 at 11:34:43AM +0100, Peder Chr.N�rgaard wrote: Dear Peder, : : at first sigh it seems a problem related to rootstrap, not with linux-patch-skas. To affirm it I need to investigate a bit more. Did you test the just-compiled kernel (with SKAS patch) with an pre-build uml instance to check if it works? If I remember well you can find here, in http://uml.nagafix.co.uk/, some uml instances. Anyway what is your rootstrap.conf configuration? Cheers SteX Hello Stefano, thanks for your answer. Yes, suspecting rootstrap is a natural thought, but I think it is not the case. First, I did also try to start user-mode-linux directly, with the parameters derived from rootstrap. Second, I did also try a root_fs successfully built with rootstrap under the non-SKAS kernel; starting user-mode-linux under the SKAS kernel it also hang at precisely the mentioned place. Third, since writing the report, I have found time to pick up the Debian 2.6.17-9 source package and perform the same exercise with that. And under my just-compiled 2.6.17-9 + SKAS kernel user-mode-linux runs just fine! Same guest user-mode-linux (2.6.18-1um-2), same rootstrap, even same linux-patch-skas package, fortunately, as it holds patches for all older kernel sources, too. So the problem is clearly related to 2.6.18 - either the kernel source (linux-source-2.6.18 version 2.6.18-2) or the patch. I have a correction to the original report; well, the report is correct, but I had made a mistake, which I corrected with no effect to the problem. I am not running this on a -686 CPU, but on an AMD Athlon, so I should really use -k7 kernels all the way through. So I switched to a mainstream -k7 kernel and a home-built -k7 kernel with SKAS; no changes, works fine on mainstream kernel, but the bug is still when SKAS patch is added to host system. So the problem *may* theoretically be local to the fact that I am using an AMD Athlon CPU; I just don't think that is very likely. If I can, I will try it out on a Pentium-based computer. Anyway, please find attached my rootstrap.conf - not that I think it is the cause of the problem. The conf is based on having a squid running on the host system, with the lines acl user-mode-linux src 172.16.0.0/255.240.0.0 http_access allow user-mode-linux added suitable places in the squid.conf. Also a stanza in /etc/network/interfaces: auto tap0 iface tap0 inet static address 172.16.0.1 netmask 255.255.255.0 tunctl_user uml-net up /sbin/ip -4 route add to 172.16.1.0/24 via 172.16.0.2 up /sbin/ip -4 route add to 172.16.2.0/24 via 172.16.0.2 best regards -- Peder Chr. Nørgaard e-mail: [EMAIL PROTECTED] Gefionsvej 19 spejder-e-mail: [EMAIL PROTECTED] DK-8230 Åbyhøj tel: +45 87 44 11 99 Denmark mob: +45 30 91 84 31 # # Global settings, these are passed on to all modules # [global] fstype=ext3 # How large to create the initial image (MB). Be generous, as image # creation will fail if it is too small, and it will be created as a # sparse file, making it relatively inexpensive initialsize=1024 # Will be resized to leave this much free space (MB) when building is # complete. Leave unset or set to 0 to disable resizing. freespace=256 # Which modules to invoke. Each module can have its own section # below, with module-specific settings modules=network mkfs mount debian uml umount # Global environment variables PATH=/bin:/sbin:/usr/bin:/usr/sbin # Use of a caching proxy is highly recommended where a local mirror is # not available, so that packages are not fetched many times # unnecessarily. I use squid. http_proxy=http://172.16.0.1:3128 # UML supplemental arguments # uncomment the following if you're running heavy processes in the # image creation, such as creating locales umlargs=mem=96M # Debugging stuff, if a rootstrap module fails spawn a shell to allow # investigating. Set the following variable to true if you want # such behaviour. #debug=true # # Networking # # required unless you have a local copy of all packages to be installed # these settings are only used during installation [network] hostname=pcnhuml # TUN/TAP configuration # For proxy ARP, use host=your host's LAN IP address and # uml=a free LAN IP address for UML's use # For a routing configuration, or if the installation process does not # need to reach anywhere except the host, use a separate RFC1918 # subnet for the virtual network between the host and UML. #interface=eth0 #transport=tuntap #host=192.168.10.1 #uml=192.168.10.2 #netmask=255.255.255.252 # For a preconfigured tap device (see tunctl(1)) #host_if=tap0 # Use this for slirp #interface=eth0 #transport=slirp #host= #uml=10.0.2.15 #nameserver=10.0.2.3 #gateway=10.0.2.2 #netmask=255.255.0.0 #slirp=slirp-fullbolt # Use this
Bug#399328: linux-patch-skas: user-mode-linux seems to not work on 2.6.18 patched with this package
Package: linux-patch-skas Version: 3-2 Severity: important I apologize in advance if this should have been reported on user-mode-linux, or perhaps not at all, if it turns out to be my own fault. But I don't know how to proceed. User-mode-linux seems to run quite well on latest debian sid kernel, 2.6.18-2-686. But I want to use the SKAS3 patch for speed and correctness, and have done so earlier with success (during 2005, with kernels 2.6.9/10/11/12). This is how I build the modified kernel: tar xfvj /usr/src/linux-source-2.6.18.tar.bz2 cd linux-source-2.6.18 cp /boot/config-2.6.18-2-686 .config make-kpkg --append-to-version -pcn --subarch 686 --revision 1 --initrd --added-patches skas --config menuconfig --rootcmd fakeroot configure make-kpkg --append-to-version -pcn --subarch 686 --revision 1 --initrd --added-patches skas --config menuconfig --rootcmd fakeroot clean make-kpkg --append-to-version -pcn --subarch 686 --revision 1 --initrd --added-patches skas --config menuconfig --rootcmd fakeroot kernel-image When this kernel is installed and user-mode-linux started (I start it from rootstrap) it correctly notes that SKAS3 is active: : Checking for the skas3 patch in the host: - /proc/mm...found - PTRACE_FAULTINFO...found - PTRACE_LDT...found UML running in SKAS3 mode : but then it hangs at end of startup: : Initializing software serial port version 1 ubda: unknown partition table ubdb: unknown partition table VFS: Mounted root (hostfs filesystem) readonly. where it hangs forever, spending all the CPU power available on the host system. At this point, when using the official debian kernel, with no SKAS3, it would continue with builder running... (from the rootstrap builder script) I am using debian sid, here are a few noteworthy packages: ii linux-image-2.6.18-2-686 2.6.18-5 Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4 ii linux-source-2.6.18 2.6.18-5 Linux kernel source for version 2.6.18 with Debian patches ii rootstrap0.3.24-1 A tool for building complete Linux filesystem images ii user-mode-linux 2.6.18-1um-2 User-mode Linux (kernel) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-pcn Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-patch-skas depends on: ii bash 3.1dfsg-7 The GNU Bourne Again SHell ii grep-dctrl2.9.3 Grep Debian package information - ii patch 2.5.9-4Apply a diff file to an original linux-patch-skas recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
