You are not logged in.

#1 2010-09-16 11:12:14

starfry
Member
From: Surrey, UK
Registered: 2010-08-18
Posts: 230

Kernel mismatches when dual-booting

Is there a reason why the kernel images under Arch have a generic name (i.e. kernel26/vmlinuz26) ?

I have multiple dual boot images running off the same /boot. All other volumes are under LVM, including the root filesystems.

Under Ubuntu each kernel release has a unique name and therefore each system refers to a specific kernel image - one of many potentially stored on /boot.

Under Arch there is only ever one kernel image. If an Arch system is updated to a new kernel it can cause problems with another dual-booting Arch system that has not yet been updated to the new kernel.

If the other system is booted it will use the new kernel but its libraries and modules, etc, will not have been updated and this will lead to problems.

I have worked around the issue by using subdirectories of /boot to contain separate kernel images for each system. I bind mount the relevant subdirectory on top of /boot so each system update its own kernel images.

Just mentioning it because dual booting like this has never been a problem on any other distro that I have used. It isn't a massive issue because I have a work around but I did waste a couple of days trying to troubleshoot a problem before I realised what was going on.

Offline

#2 2010-09-16 11:26:56

vacant
Member
From: downstairs
Registered: 2004-11-05
Posts: 816

Re: Kernel mismatches when dual-booting

There are other options.

I altered the image names in /etc/mkinitcpio.d/kernel26.preset on one of my systems ( once done, that sorts it)

You could manually copy the new /lib/modules/2.6.35-* each time to the other system so it boots OK with the new kernel, then update with pacman overriding any errors.

I bet there are a dozen other solutions people have come up with.

Last edited by vacant (2010-09-16 11:27:53)

Offline

#3 2010-09-16 11:35:27

wonder
Developer
From: Bucharest, Romania
Registered: 2006-07-05
Posts: 5,941
Website

Re: Kernel mismatches when dual-booting

if you want to have a kernel as a backup, install kernel26-lts

https://bugs.archlinux.org/task/16702


Give what you have. To someone, it may be better than you dare to think.

Offline

#4 2010-09-16 11:35:47

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: Kernel mismatches when dual-booting

Just a question, why would you want to dual-boot Arch with Arch and share boot? Sounds specialist enough to just about REQUIRE that you manually adjust various things, as you obviously already have.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#5 2010-09-16 12:29:48

vacant
Member
From: downstairs
Registered: 2004-11-05
Posts: 816

Re: Kernel mismatches when dual-booting

ngoonee wrote:

Just a question, why would you want to dual-boot Arch with Arch and share boot?

On my lowly radeon hd3200 laptop, catalyst runs much cooler with less fan noise but when I want to send HD video to the TV, fglrx tears video sometimes. Then I boot an arch partition with xf86-video-ati & vlc.

Offline

#6 2010-09-16 15:29:54

starfry
Member
From: Surrey, UK
Registered: 2010-08-18
Posts: 230

Re: Kernel mismatches when dual-booting

ngoonee wrote:

Just a question, why would you want to dual-boot Arch with Arch and share boot? Sounds specialist enough to just about REQUIRE that you manually adjust various things, as you obviously already have.

One reason is that I like to have two root partitions to allow fall back to a second one if an update to the first borks my system. It's something I've always done. I keep application data on partitions that both roots would mount and am able to boot either root to use effectively the same system. The only time they really differ is when upgrading.

The reason why there is a single /boot is that everything else is under LVM control.

Like I said, I have a solution that works for me but I never needed one for other distributions so was just curious why Arch does what it does. It did throw me recently when the kernel updated and appeared to break Xorg which is why I devised the solution that I now have.

Last edited by starfry (2010-09-16 15:30:44)

Offline

#7 2010-09-16 17:30:56

RJQ
Member
From: Los Angeles
Registered: 2010-06-25
Posts: 70
Website

Re: Kernel mismatches when dual-booting

Just a comment, I multi-boot 4 arch systems, unlike your issue I don't have to share other than the home partition among them, but my guess (granted I do NOT know what LVM control is) is that systems with out shared directories require less hacking around, and since booting nowadays is quite fast why not boot into complete separate ones. all my systems keep a copy of the previous kernel "rescue mode" by default, to me the branding of the kernel with one name is a feature. smile

Last edited by RJQ (2010-09-16 17:33:33)


Natural Spanish speaker person babbling English...
Natural Linux user babbling Archlinux...

Offline

#8 2010-09-16 18:18:50

codycarey
Member
Registered: 2009-08-21
Posts: 154

Re: Kernel mismatches when dual-booting

RJQ wrote:

Just a comment, I multi-boot 4 arch systems, unlike your issue I don't have to share other than the home partition among them.

I do the same thing, except that I share /opt as well as /home. I tend to have at least 3 installs at any given time. A stable environment for work-related development and such, a [testing] environment, and an experimentation environment (custom kernels, etc.).

Offline

#9 2010-09-16 23:36:57

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: Kernel mismatches when dual-booting

starfry wrote:
ngoonee wrote:

Just a question, why would you want to dual-boot Arch with Arch and share boot? Sounds specialist enough to just about REQUIRE that you manually adjust various things, as you obviously already have.

One reason is that I like to have two root partitions to allow fall back to a second one if an update to the first borks my system. It's something I've always done. I keep application data on partitions that both roots would mount and am able to boot either root to use effectively the same system. The only time they really differ is when upgrading.

The reason why there is a single /boot is that everything else is under LVM control.

Like I said, I have a solution that works for me but I never needed one for other distributions so was just curious why Arch does what it does. It did throw me recently when the kernel updated and appeared to break Xorg which is why I devised the solution that I now have.

I would suggest either keeping kernel26-lts installed (easier) or writing a small script to keep versioned copies of /boot/vmlinuz26, /lib/modules/$kernel_name, and /usr/src/linux-$kernel_name.

This script would probably be bash and re-useable on all your systems. Presto, no more surprises with regards to kernel updates, just load the latest versioned copy and you'd have your kernel and all available modules....

Of course, if you're going to go that route some people just keep multiple installed kernels (I use kernel26-ice and kernel26-rt-ice from the AUR personally). Less scripting, more compiling.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#10 2010-09-17 00:11:01

.:B:.
Forum Fellow
Registered: 2006-11-26
Posts: 5,819
Website

Re: Kernel mismatches when dual-booting

ngoonee wrote:

I would suggest either keeping kernel26-lts installed (easier) or writing a small script to keep versioned copies of /boot/vmlinuz26, /lib/modules/$kernel_name, and /usr/src/linux-$kernel_name.

This script would probably be bash and re-useable on all your systems. Presto, no more surprises with regards to kernel updates, just load the latest versioned copy and you'd have your kernel and all available modules....

That would only work for patchlevel upgrades (.34 to .35 for example), or for keeping simultaneously installed kernels with different $(uname -r) strings. Arch does not keep anything below the patch level in the kernel's name string (2.6.35-ARCH), so the module path will be identical between 2.6.35, 2.6.35.1, 2.6.35.2, etc. - the path is /lib/modules/$(uname -r)/ and uname -r will always return 2.6.35-ARCH. Since the name string is hardcoded at compilation time, you can't move the kernel modules to another tree or path - it will break your kernel.


Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy

Offline

#11 2010-09-17 03:33:58

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: Kernel mismatches when dual-booting

.:B:. wrote:
ngoonee wrote:

I would suggest either keeping kernel26-lts installed (easier) or writing a small script to keep versioned copies of /boot/vmlinuz26, /lib/modules/$kernel_name, and /usr/src/linux-$kernel_name.

This script would probably be bash and re-useable on all your systems. Presto, no more surprises with regards to kernel updates, just load the latest versioned copy and you'd have your kernel and all available modules....

That would only work for patchlevel upgrades (.34 to .35 for example), or for keeping simultaneously installed kernels with different $(uname -r) strings. Arch does not keep anything below the patch level in the kernel's name string (2.6.35-ARCH), so the module path will be identical between 2.6.35, 2.6.35.1, 2.6.35.2, etc. - the path is /lib/modules/$(uname -r)/ and uname -r will always return 2.6.35-ARCH. Since the name string is hardcoded at compilation time, you can't move the kernel modules to another tree or path - it will break your kernel.

Well, considering that the OP was concerned about having a 'fallback' if things don't work, my idea was that he could keep versioned copies of his own somewhere else and just bring them back if things stop booting.

Of course, now that I read it again I don't explain it all that well....


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

Board footer

Powered by FluxBB