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

[Beartooth]

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 ...

 	I.e., that there's no way to avoid this recurrence -- 
that you just have to cope every time it hits you?

 	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 ...)

 	You seemed to be saying as much in your post a little 
later on Jan 3 :

> In menu.txt, probably in /root/grub, there will be a line for 
> SuSE (as well as Windows and Ubuntu. In my case it had a SuSE 
> entry that included "2.6.16.20" as part of the text. So, AS 
> ROOT (root owns menu.txt), one edits menu.txt to change the 
> text from "2.6.16.20" to "2.6.16.2."

> If you end up in this fix, foreknowledge is great: Say, again, 
> that SuSE is updating the kernel. As part of the process, 
> SuSE's menu.lst will be updated. Take a look at IT before you 
> reboot.

 	A shrewd move! (If I can manage to remember to do it ...)

> Compare it to what you see in the older version of menu.lst (I 
> keep one around just for such purposes).

 	Ditto my previous comment. <sigh>

> That gives additional info about what should be in, e.g., 
> Ubuntu's menu.lst.

 	Second, if that's *not* what you mean -- or if anyone 
here knows a better way -- how do you figure out what to tell 
grub to get it to observe updates to kernels? After all, it does 
observe them on one OS ...

 	I do notice, on the machine that I occasionally boot to 
XP, that booting back into F8 may make trouble with my display 
(usually fixable by commanding "metacity --replace," logging out, 
and back in).

 	But I haven't (thank God!) had to use XP to fix the grub 
entry for Fedora. Of course, Fedora is the default; and I never 
update XP itself, but only things like ZoneAlarm and my other 
defenses. (Ten to one M$ would manage to disimprove XP somehow if 
I did update it ...)

 	On the current testbed, however, I expect to shift OSs 
every week or three till I have a favorite -- and do at least yum 
update or equivalent, including kernels, on every reboot.

 	Iow, two times out of three, there's a good chance a 
kernel will change in an OS which is not the default boot.

 	I do have a /boot partition. According to gparted, it's 
the first (i.e., /dev/hda1), with 102 MB, 21% used.

 	Subtechnoid that I am, and unsure how many /boot 
directories three OSs may have or what they look like, I checked 
-- I think. Running Centos, doing ls /boot gets the same list as 
doing the following :

[root at localhost ~]# mount -t ext3 /dev/hda1 /TEST
[root at localhost ~]# cd /TEST
[root at localhost TEST]# ls

 	Namely :

[root at localhost TEST]# ls
config-2.6.18-53.1.4.el5xen      System.map-2.6.18-53.1.4.el5xen
config-2.6.18-53.el5xen          System.map-2.6.18-53.el5xen
grub                             vmlinuz-2.6.18-53.1.4.el5xen
initrd-2.6.18-53.1.4.el5xen.img  vmlinuz-2.6.18-53.el5xen
initrd-2.6.18-53.el5xen.img      xen.gz-2.6.18-53.1.4.el5
lost+found                       xen.gz-2.6.18-53.el5
message                          xen-syms-2.6.18-53.1.4.el5
symvers-2.6.18-53.1.4.el5xen.gz  xen-syms-2.6.18-53.el5
symvers-2.6.18-53.el5xen.gz
[root at localhost TEST]#

 	I also double-checked the two grub directories :

[root at localhost TEST]# ls /boot/grub
device.map     grub.conf.save    minix_stage1_5     ufs2_stage1_5
e2fs_stage1_5  grub.conf.save.1  reiserfs_stage1_5 
vstafs_stage1_5
fat_stage1_5   iso9660_stage1_5  splash.xpm.gz      xfs_stage1_5
ffs_stage1_5   jfs_stage1_5      stage1
grub.conf      menu.lst          stage2
[root at localhost TEST]# ls grub
device.map     grub.conf.save    minix_stage1_5     ufs2_stage1_5
e2fs_stage1_5  grub.conf.save.1  reiserfs_stage1_5 
vstafs_stage1_5
fat_stage1_5   iso9660_stage1_5  splash.xpm.gz      xfs_stage1_5
ffs_stage1_5   jfs_stage1_5      stage1
grub.conf      menu.lst          stage2
[root at localhost TEST]#

 	I don't see any mention in there of F8 or U7. Should I?? 
Could it be made to take notice of them???

-- 
Beartooth Staffwright, Neo-Redneck Double Retiree,
Not Quite Clueless Linux Power User, with precious 
(very precious) little idea where up is.