Am 26.09.2013 13:57, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
$ file linux
linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped
$ ./linux ubd0=busybox-rootfs
[...]
Kernel panic - not syncing: No init found. Try passing init= option
to kernel. See Linux Documentation/init.txt for guidance.
I don't know that rootfs but it looks like there is no init.
Ofcourse there's an init on the busybox-rootfs, and I'm able to boot
it with an x86_64 Linux. The reason for panic is incorrect: I think
(although not sure) a 32-bit rootfs userland will work.
A 32Bit UML kernel can run 32Bit users, a 64Bit UML kernel can only
run 64Bit userland. We have no 32Bit compat layer on x86_64.
Patches are welcome.
[1] 25526 abort (core dumped) linux ubd0=busybox-rootfs
%
Rubbish.
UML core dumps at panic() by design.
On a related note, why does it screw up my terminal? I have to `reset`
to get a nice working terminal.
I really don't know. That is not by design.
Seriously, my plan is to get rid of SUBARCH, that's why I did not push your patches
upstream and I've send the rid of SUBARCH patch series.
It turned out that other archs depend on SUBARCH too therefore some more thinking is needed.
Time passed, merge window closed, $dayjob needed some attention...
Don't let some grand plan stall reasonable patches that fix immediate problems.
That said, your "arch/um: make it work with defconfig and x86_64" patch is also not perfect.
"make defconfig ARCH=um SUBARCH=x86" will create x86_64 defconfig, which is wrong and breaks existing
setups.
Wrong.
$ make defconfig ARCH=um SUBARCH=i386
*** Default configuration is based on 'i386_defconfig'
#
# configuration written to .config
#
I wrote "SUBARCH=x86" *not* SUBARCH=i386.
Again, if SUBARCH=x86 works too I'll happily merge it.
But as of now it breaks existing setups.
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
