[SOLVED] Keeping both i686 and x86_64 kernels

schivmeister · 2010-09-08 01:07:33

Related subjects:

https://bbs.archlinux.org/viewtopic.php?pid=822147
https://bbs.archlinux.org/viewtopic.php?id=66660

The situation:

I have a 32GB USB Flash Drive.
I have Arch Linux on a partition.
I use it as a truly promiscuous system.
It is i686.

The intention:

To keep only one (32-bit) userland.
To keep both 32-bit and 64-bit kernels using the prebuilt packages (so no recompiling must be involved).
This is an example of how I would _like_ it to be: http://paste.pocoo.org/show/259415/

The problem:

As far as the kernel package name is concerned, it's the same for both architectures.
Using the above-cited script does not update the kernel's internal information about the system.
"Unable to determine major/minor number root device $device"
In particular, the config still refers to the original module directory.
As such, "uname -r" resolves to the original as well.
There are plenty of gotchas I'm missing here, probably.

The question:

Could there be a way to override "uname -r" in very early userspace? I've played around with hooking but it does not seem to work even if I backup and replace the original module directory with the contents of the one from the recreated package, i.e:

mv linux-2.6.35-ARCH linux-2.6.35-ARCH32
mv linux-2.6.35-ARCH64 linux-2.6.35-ARCH

I then noticed the obvious; udevd misses the modules because of "uname -r" (used by modprobe), and this is before any hooks are run. I could probably edit init to make the necessary (conditional) moving/symlinking of the directories (or not), but shouldn't there be an escape hatch for me in this story?

edit: Apparently, modprobe uses the uname syscall. I found this out when I remembered that there is no uname binary in the image (later on I realised busybox provides it), and then Google gave me more information.

edit2: See post #9.

Last edited by schivmeister (2010-09-09 18:40:35)

djgera · 2010-09-08 01:43:48

Maybe the most simple way is to replace uname by shell wrapper script. This script can read a kernel command line parameter, so the output of uname -r can be tunable.

EDIT: of course this only works if uname command is executed, if something call to uname(2), or read osrelease from procfs will fail.

Last edited by djgera (2010-09-08 01:45:05)

falconindy · 2010-09-08 01:51:34

the linux32 and linux64 shortcuts for setarch are your friend.

http://allanmcrae.com/2010/02/transpare … -userland/

edit: I tried this for a day. Initial setup wasn't terrible, but it made for some serious "fun" when it came time to dealing with some external kernel modules and I eventually scrapped it. You might benefit from a script that I wrote to facilitate installing 64 bit packages onto the 32 bit userland.

http://paste.pocoo.org/show/259426/

Last edited by falconindy (2010-09-08 01:53:50)

djgera · 2010-09-08 02:00:24

@falconindy: schivmeister want to keep both kernels on the same partition, both kernels have the same osrelease. The commands linux32 and linux64 does not change osrelease.

falconindy · 2010-09-08 02:07:21

Right. I knew that... I suppose my 32-bit kernel when I did this was custom and the 64 was stock... The sane solution is to recompile. Barring that, consult a witch doctor.

Seriously, why the stringent requirement on no recompiling?

schivmeister · 2010-09-08 14:01:19

There are a couple of reasons behind this scenario:

Target: No secondary x86_64 system
Reason: Flash-based system; space constraints

Target: No compilation
Reason: Promiscuous system; time constraints

Moreoever, I'd be rebuilding the kernel only to change its unique suffix, so that would suck. As for wrapping executables, I don't want to be that invasive unless there really is no other way out, but it's more reasonable than tainting /lib/initcpio/init I guess.

yejun · 2010-09-08 16:08:36

Use one lts kernel and one not. Is that simple enough?

Last edited by yejun (2010-09-08 16:09:14)

schivmeister · 2010-09-08 20:06:36

yejun wrote:

Use one lts kernel and one not. Is that simple enough?

It's not even part of the equation.

schivmeister · 2010-09-09 18:38:14

I'm pretty sure by now that there's no "simpler" way to handle this, so I'm marking this as "solved". The wrapping is too much work for what it's worth. With modprobe -S or modprobe wrapping, both require conditional statements to seamlessly change between kernels of any kind, and that would slow down udev.

..and so I went with a rather simple hack to init:

--- init-orig   2010-07-11 18:02:42.000000000 +0800
+++ init        2010-09-09 18:11:33.246667139 +0800
@@ -29,6 +29,16 @@
 # set default mount handler
 mount_handler="default_mount_handler"

+# make adjustments for hybrid system
+(
+cd /lib/modules
+if [ `/bin/uname -m` = x86_64 ]; then
+    /bin/ln -s 2.6.35-ARCH64 2.6.35-ARCH
+else
+    /bin/ln -s 2.6.35-ARCH32 2.6.35-ARCH
+fi
+)
+
 # if available, start udevd at this stage
 if [ -x /sbin/udevd ]; then
     msg ":: Starting udevd..."

It's not exactly "seamless", but all I need to do is create the symlink for what I want to boot next time (or most of the time). It could've been, but sysinit stage is read-only so I can't create symlinks there.

Arch Linux

#1 2010-09-08 01:07:33

[SOLVED] Keeping both i686 and x86_64 kernels

#2 2010-09-08 01:43:48

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#3 2010-09-08 01:51:34

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#4 2010-09-08 02:00:24

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#5 2010-09-08 02:07:21

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#6 2010-09-08 14:01:19

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#7 2010-09-08 16:08:36

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#8 2010-09-08 20:06:36

Re: [SOLVED] Keeping both i686 and x86_64 kernels

#9 2010-09-09 18:38:14

Re: [SOLVED] Keeping both i686 and x86_64 kernels

Board footer