[Novalug] Re: Pitfall in Multibooting? (was Re: CentOS/Ubuntu)

Roger W. Broseus rogerb at bronord.com
Sun Jan 20 18:51:51 EST 2008


Beartooth wrote:
> On Thu, 3 Jan 2008, RogerB wrote:
>
>     [snipperoo]
>
>> CAVEAT for dual boot Linux: if the kernel gets updated, as happened 
>> with SuSE after I had installed Ubuntu in another partition, Grub 
>> threw an error message that it could not find SuSE. That's because 
>> Ubuntu took command and, of course, SuSE didn't know about that. The 
>> fix was to learn more about Grub and edit Ubuntu's menu.txt to point 
>> to the correct version of the kernel for SuSE. Problem solved.
>
>     [snipperee]
>
>     Two questions. First, I *think* I understand you aright to be 
> saying that the problem will recur periodically, and have to be 
> re-solved. I sure wish it weren't so ...
In my experience, only when the kernel gets updated.
>     I.e., that there's no way to avoid this recurrence -- that you 
> just have to cope every time it hits you?
Yeah: don' accept kernel updates <giggle> but you don't wanna do THAT!
>     I.e., re-edit the menu.ls (or menu.txt if you really mean that) 
> that you can still boot to, probably by mounting the suddenly 
> unavailable partition and copying the new kernel designation from that 
> into the bootable one? (Aaarrgghhh ...)
It is not a matter of partitioning. It's a matter of the info that 
appears in menu.lst. If your "controlling" distro is, say, Ubuntu 
because it wrote to the mbr, then, when Ubuntu upgrades kernel, it will 
put the correct kernel version info into menu.lst. Howsomever, Ubuntu 
has no way of knowing when SuSE or Fedora updates kernel. SO, what I 
said was a bit wrong: you should keep a copy of each distro's menu.lst 
(or whatever it's called) and NOTE when a "non-controlling" distro 
changes menu.lst.

Now, if as in this example, Ubuntu is controlling and SuSE has updated 
kernel and changed ITS menu.lst, the next time you good Ubuntu, edit 
Ubuntu's menu.lst to update the kernel version info therein.

Remember: grub writes info to the mbr about WHERE to look for boot info 
and if Ubuntu was the last distro installed, it says look at Ubuntu 
/boot to find this. My sub-arachnoid brain knows of no way to "tell" 
other distros to watch to see what Ubuntu has done (same all the way 
around).

IF you fail to have foresight, you can boot Knoppix and go look at 
menu.lst for the distro that updated its kernel. The thing that tipped 
me off to this was a "failure to find" message - it was NOT failing to 
find a partition but the files that specify the (new/replaced) kernel at 
boot. I finally suspected this and verified by editing grub commands at 
boot and succeeded in booting the distro with the new kernel version. 
That done, it was a cinch to edit menu.lst for the "controlling" distro.

[snip the rest]

Good luck and have fun!

-- 
Roger W. Broseus - Linux User
    Email: RogerB at bronord.com
    Web Site: www.bronord.com




More information about the Novalug mailing list