Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
On Sun, Sep 10, 2006 at 10:06:55PM -0500, Ardo van Rangelrooij wrote: Mattia Dongili ([EMAIL PROTECTED]) wrote: Hello, On Tue, Sep 05, 2006 at 06:11:23AM -0500, Ardo van Rangelrooij wrote: Mattia Dongili ([EMAIL PROTECTED]) wrote: [...] hung as in it sits there forever? oooh so sad... this is not very easy to debug then. Yep. One moment the various 'linux' processes are at the top in `top`, the next moment they're gone and nothing happens anymore. believe it or not I got my hands on an amd64 laptop (authentic AMD 3200+ something), rebuilt u-m-l and rootstrap for amd64 and tested: the rootfs image creation went totally smooth. I didn't have any problem. Interesting. Then I'm really wondering what I'm doing wrong... I've also rebooted to a kernel with no vserver stuff (in case that would matter...; one never knows) but that didn't help either. What are your settings in the rootstrap config file? Maybe something is amis in there on my side. Unfortunately I don't have such laptop anymore and (blame me for that) I didn't copy the config files I had there... sorry. Anyway I didn't anything that fancy, just configured networking (ip/netmask/dns on the guest, forwarding and masquerading on the host) and configured Sid apt sources. The host was mostly clean Etch with 2.6.16. I'm out of ideas on what could go wrong on your setup... [...] I'm quite inclined to upload the packages with the modified Architecture field, what do you think? Please go ahead. The more people get their hands on this the better... will upload asap, maybe I'll also ask the DSA if I can have rootstrap and UML installed on pergolesi once the binary packages for amd64 are available. cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Mattia Dongili ([EMAIL PROTECTED]) wrote: Hello, On Tue, Sep 05, 2006 at 06:11:23AM -0500, Ardo van Rangelrooij wrote: Mattia Dongili ([EMAIL PROTECTED]) wrote: [...] hung as in it sits there forever? oooh so sad... this is not very easy to debug then. Yep. One moment the various 'linux' processes are at the top in `top`, the next moment they're gone and nothing happens anymore. believe it or not I got my hands on an amd64 laptop (authentic AMD 3200+ something), rebuilt u-m-l and rootstrap for amd64 and tested: the rootfs image creation went totally smooth. I didn't have any problem. Interesting. Then I'm really wondering what I'm doing wrong... I've also rebooted to a kernel with no vserver stuff (in case that would matter...; one never knows) but that didn't help either. What are your settings in the rootstrap config file? Maybe something is amis in there on my side. I had some problems with threaded apps (that of TLS/NTPL stuff but on amd64 there's no /lib/tls to move away...) [...] In the cases where I got the farthest, it's the 'sync' process that hung, called from debootstrap. In other cases it was 'dpkg-deb' that hung, also these symptoms resemble a /dev/shm-too-small[1] I had here on i386 but waiting some time (a few minutes) I could see the thing go on. Well, I'm only using 30M out of 1G. Seems plenty to me... [1]: as said previously you should note /dev/shm short in available space or your computer should already be swapping... No swapping at all. I'm quite inclined to upload the packages with the modified Architecture field, what do you think? Please go ahead. The more people get their hands on this the better... Thanks, Ardo -- Ardo van Rangelrooij Debian XML/SGML Group [EMAIL PROTECTED] [EMAIL PROTECTED] http://people.debian.org/~ardo/ http://debian-xml-sgml.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Hello, On Tue, Sep 05, 2006 at 06:11:23AM -0500, Ardo van Rangelrooij wrote: Mattia Dongili ([EMAIL PROTECTED]) wrote: [...] hung as in it sits there forever? oooh so sad... this is not very easy to debug then. Yep. One moment the various 'linux' processes are at the top in `top`, the next moment they're gone and nothing happens anymore. believe it or not I got my hands on an amd64 laptop (authentic AMD 3200+ something), rebuilt u-m-l and rootstrap for amd64 and tested: the rootfs image creation went totally smooth. I didn't have any problem. I had some problems with threaded apps (that of TLS/NTPL stuff but on amd64 there's no /lib/tls to move away...) [...] In the cases where I got the farthest, it's the 'sync' process that hung, called from debootstrap. In other cases it was 'dpkg-deb' that hung, also these symptoms resemble a /dev/shm-too-small[1] I had here on i386 but waiting some time (a few minutes) I could see the thing go on. [1]: as said previously you should note /dev/shm short in available space or your computer should already be swapping... I'm quite inclined to upload the packages with the modified Architecture field, what do you think? -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Hi there Ardo! On Tue, September 5, 2006 5:20 am, Ardo van Rangelrooij said: Mattia Dongili ([EMAIL PROTECTED]) wrote: Hello! [...] Ardo: it seems very similar to your old diff (a couple of months ago), have you benn able to go further with the amd64 experiment? I played some more with this evening. I got quite a lot further, but it still didn't make it through a successful rootstrap run: It hung at the 'sync' step hung as in it sits there forever? oooh so sad... this is not very easy to debug then. in debootstrap most of the times, but occaisionally I had it hung already some time earlier during the package unpack/install/configure. Hummm... things to check/try out popping out of my head: - /dev/shm usage (use df -h), if it goes low (very low) increase it - set debug=true, put an exit 1 before debootstrap then run debootstrap manually from the provided shell (well... probably not that useful), be careful, no Ctrl-C there :) - start uml_mconsole and send a sysrq+t and see who is hung and where - add set -x to all rootstrap modules :) - strace deboostrap in the debian module I've been using the latest user-mode-linus and rootstrap 3.22. Later this week I'll try with rootstrap 3.23. Let's see whether that makes a difference. eh, I don't think it'll change that much, but let's see. I wish there was a way to get somore debugging going... me too :) Thanks a lot -- mattia :wq!
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Mattia Dongili ([EMAIL PROTECTED]) wrote: Hi there Ardo! On Tue, September 5, 2006 5:20 am, Ardo van Rangelrooij said: Mattia Dongili ([EMAIL PROTECTED]) wrote: Hello! [...] Ardo: it seems very similar to your old diff (a couple of months ago), have you benn able to go further with the amd64 experiment? I played some more with this evening. I got quite a lot further, but it still didn't make it through a successful rootstrap run: It hung at the 'sync' step hung as in it sits there forever? oooh so sad... this is not very easy to debug then. Yep. One moment the various 'linux' processes are at the top in `top`, the next moment they're gone and nothing happens anymore. in debootstrap most of the times, but occaisionally I had it hung already some time earlier during the package unpack/install/configure. Hummm... things to check/try out popping out of my head: - /dev/shm usage (use df -h), if it goes low (very low) increase it - set debug=true, put an exit 1 before debootstrap then run debootstrap manually from the provided shell (well... probably not that useful), be careful, no Ctrl-C there :) - start uml_mconsole and send a sysrq+t and see who is hung and where - add set -x to all rootstrap modules :) - strace deboostrap in the debian module I'll try these and let you know what's up. In the cases where I got the farthest, it's the 'sync' process that hung, called from debootstrap. In other cases it was 'dpkg-deb' that hung, also called from debootstrap. I've been using the latest user-mode-linus and rootstrap 3.22. Later this week I'll try with rootstrap 3.23. Let's see whether that makes a difference. eh, I don't think it'll change that much, but let's see. Yeah... I wish there was a way to get somore debugging going... me too :) Thanks a lot You're welcome. Thanks, Ardo -- Ardo van Rangelrooij Debian XML/SGML Group [EMAIL PROTECTED] [EMAIL PROTECTED] http://people.debian.org/~ardo/ http://debian-xml-sgml.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Mattia Dongili ([EMAIL PROTECTED]) wrote: Hello! On Sun, Aug 27, 2006 at 05:29:13PM +0200, David Madore wrote: Package: user-mode-linux Version: 2.6.17-1um-2 Please provide an amd64 build of user-mode-linux. AFAICS, there is no difficulty involved, the package builds correctly from the Debian source with essentially no changes (just provide a config.adm64 file). except I don't have any amd64 box and can't test it, nor create a safe config.amd64 :) I'll be happy to include the amd64 binary with some help from somebody having access to such box. As a proof of concept, see the package files in URL: ftp://quatramaran.ens.fr/pub/madore/misc/user-mode-linux-debian/ . can you confirm it works for you with configuration I extracted from the diff.gz? I mean can you at least run the UML, play some time with it and halt correctly? oh, and could you attach your config.amd64 for reference to this bug report? Ardo: it seems very similar to your old diff (a couple of months ago), have you benn able to go further with the amd64 experiment? I played some more with this evening. I got quite a lot further, but it still didn't make it through a successful rootstrap run: It hung at the 'sync' step in debootstrap most of the times, but occaisionally I had it hung already some time earlier during the package unpack/install/configure. I've been using the latest user-mode-linus and rootstrap 3.22. Later this week I'll try with rootstrap 3.23. Let's see whether that makes a difference. I wish there was a way to get somore debugging going... Thanks, Ardo -- Ardo van Rangelrooij Debian XML/SGML Group [EMAIL PROTECTED] [EMAIL PROTECTED] http://people.debian.org/~ardo/ http://debian-xml-sgml.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
Hello! On Sun, Aug 27, 2006 at 05:29:13PM +0200, David Madore wrote: Package: user-mode-linux Version: 2.6.17-1um-2 Please provide an amd64 build of user-mode-linux. AFAICS, there is no difficulty involved, the package builds correctly from the Debian source with essentially no changes (just provide a config.adm64 file). except I don't have any amd64 box and can't test it, nor create a safe config.amd64 :) I'll be happy to include the amd64 binary with some help from somebody having access to such box. As a proof of concept, see the package files in URL: ftp://quatramaran.ens.fr/pub/madore/misc/user-mode-linux-debian/ . can you confirm it works for you with configuration I extracted from the diff.gz? I mean can you at least run the UML, play some time with it and halt correctly? oh, and could you attach your config.amd64 for reference to this bug report? Ardo: it seems very similar to your old diff (a couple of months ago), have you benn able to go further with the amd64 experiment? thanks -- mattia :wq! signature.asc Description: Digital signature
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
On Sun, Aug 27, 2006 at 06:46:06PM +0200, Mattia Dongili wrote:
except I don't have any amd64 box and can't test it, nor create a safe
config.amd64 :)
Ah, sorry. (I had thought Debian provided its maintainers with access
to test boxen of all supported architectures for such cases.)
I'll be happy to include the amd64 binary with some help from somebody
having access to such box.
Well, I'm willing to help.
can you confirm it works for you with configuration I extracted from the
diff.gz?
I mean can you at least run the UML, play some time with it and halt
correctly?
I did some very superficial testing (started it with 'root=/dev/root
rootflags=/ rootfstype=hostfs init=/bin/sh'), but it seems to boot and
halt all right and I can run some simple (64-bit) programs like ls.
(See the attached typescript.) If there's something specific you'd
like me to test, please say so.
There's one possibly serious warning, though, that I don't know how to
analyse ('idr_remove called for id=6 which is not allocated', followed
by a call trace). It might be due to missing features from my host
kernel (I'm running a homebrew kernel, not a generic Debian one).
Also, a 64-bit UML does not seem to be able to execute 32-bit binaries
(I couldn't find any sort of ia32 compatibility configuration option).
I'm afraid there's no easy workaround, there.
oh, and could you attach your config.amd64 for reference to this
bug report?
Attached.
It was generated very simply: I just copied your config.i386 to
.config in a kernel source tree and then ran 'make ARCH=um oldconfig'
and was only asked one question (something about AES256 for amd64 -
might have been simply because my source tree was a bit newer). So it
should be safe enough.
Happy hacking,
--
David A. Madore
([EMAIL PROTECTED],
http://www.madore.org/~david/ )
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17
# Sun Aug 27 16:44:57 2006
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_IRQ_RELEASE_METHOD=y
#
# UML-specific options
#
# CONFIG_MODE_TT is not set
# CONFIG_STATIC_LINK is not set
CONFIG_MODE_SKAS=y
CONFIG_UML_X86=y
CONFIG_64BIT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_TOP_ADDR=0x8000
CONFIG_3_LEVEL_PGTABLES=y
CONFIG_STUB_CODE=0x7fbfffe000
CONFIG_STUB_DATA=0x7fb000
CONFIG_STUB_START=0x7fbfffe000
# CONFIG_ARCH_HAS_SC_SIGNALS is not set
# CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA is not set
CONFIG_SMP_BROKEN=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_LD_SCRIPT_DYN=y
CONFIG_NET=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_HOSTFS=y
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_NEST_LEVEL=0
CONFIG_KERNEL_STACK_ORDER=2
CONFIG_UML_REAL_TIME_CLOCK=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory
#
# Block devices
#
CONFIG_BLK_DEV_UBD=y
CONFIG_BLK_DEV_UBD_SYNC=y
CONFIG_BLK_DEV_COW_COMMON=y
# CONFIG_MMAPPER is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_ATA_OVER_ETH is not set
#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
# CONFIG_NOCONFIG_CHAN is not set
CONFIG_CON_ZERO_CHAN=fd:0,fd:1
CONFIG_CON_CHAN=xterm
CONFIG_SSL_CHAN=pty
Bug#384881: [Pkg-uml-pkgs] Bug#384881: provide amd64 build of user-mode-linux
On Sun, Aug 27, 2006 at 07:38:46PM +0200, David Madore wrote:
On Sun, Aug 27, 2006 at 06:46:06PM +0200, Mattia Dongili wrote:
except I don't have any amd64 box and can't test it, nor create a safe
config.amd64 :)
Ah, sorry. (I had thought Debian provided its maintainers with access
to test boxen of all supported architectures for such cases.)
well, it is. Unfortunately my provider somewhat sucks (15 hops in their
LAN before being able to access the internet so I often experience
timeouts...) so it's not that easy for me...
I'll be happy to include the amd64 binary with some help from somebody
having access to such box.
Well, I'm willing to help.
great, thanks
can you confirm it works for you with configuration I extracted from the
diff.gz?
I mean can you at least run the UML, play some time with it and halt
correctly?
I did some very superficial testing (started it with 'root=/dev/root
rootflags=/ rootfstype=hostfs init=/bin/sh'), but it seems to boot and
halt all right and I can run some simple (64-bit) programs like ls.
(See the attached typescript.) If there's something specific you'd
like me to test, please say so.
well, Ardo (Cc-ed) previously started testing rootstrap on amd64 to
create a full rootfs image. Don't you have any already cooked 64bit
rootfs available?
There's one possibly serious warning, though, that I don't know how to
analyse ('idr_remove called for id=6 which is not allocated', followed
by a call trace). It might be due to missing features from my host
kernel (I'm running a homebrew kernel, not a generic Debian one).
no, it's most probably due to init=/bin/sh and afaik it's harmless.
Also, a 64-bit UML does not seem to be able to execute 32-bit binaries
(I couldn't find any sort of ia32 compatibility configuration option).
I'm afraid there's no easy workaround, there.
did you try it in a 32bit chroot (inside the guest)? maybe UML-64 simply
isn't able to provide a 32bit emulation.
oh, and could you attach your config.amd64 for reference to this
bug report?
Attached.
thanks.
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
