single *_grub_* partition for many distros

[Joe(theWordy)Philbrook]

It would appear that on Sep 26, Goh Lip did say:

> Joe, I think you had inadvertently sent to my direct email rather than 
> the mailing list. So I copied and add as subject matter your proposed 
> subject header.

Well yes & no! Something odd happened. But thank you for fixing the intent
of my posting... ;-)

Seriously though, I normally use gmane's nntp mirrors for most of my
mailing list activities. (It keeps my inbox from choking if I don't
get to download my mail for a few days...) And Since I use Alpine it's
possible to send the same message to both Email addresses AND the
newsgroup. The SUB-thread we were using only had three participants,
and I was using the e-mail To: (and Cc:) to insure that both of the
other participants noticed the intended move to the new thread...

I just checked my outbox, my message with a "Subject:" of:
"grub2, And how to survive it... (OR is lilo still a viable option?<snicker>)"
did have the header line "Newsgroups: gmane.linux.ubuntu.user.kubuntu"
Which should have caused it to be posted to the list via gmane's
gateway... I really don't think alpine screwed up. I think I remember
getting alpines confirmation prompt about sending it to the newsgroup.
So since it didn't post (And since I don't think I could have fat
fingered "N"o while aiming for "Y"es) I have to figure that either 
gmane's gateway, Or the Kubuntu listserver didn't like the Attached
"Content-Type: MULTIPART/DIGEST" of the two (not directly quoted):
"Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII" That dealt specifically with
grub2... That I included in case someone who hadn't been following/nor
archiving a thread about partition problems but WAS interested in grub2
would have the full context of the grub2 discussion to refer to... 

> Joe Philbrook wrote:
> 
> > I think this grub2 discussion has gotten far enough off topic from
> > a thread about "Partition problems" That it was time to move the discussion
> > to a New thread... And no, I doubt I'd really want to switch back to lilo.
> > But some of the changes their making for grub2 makes it amusing to think
> > about. Like something I gleaned from another thread, that your not
> > "supposed" to edit the grub.cfg... Wasn't one of the things grub used to
> > brag about was how simple it was to just edit grubs configuration file???
> > 
> 
> I guess it would be simple for people who can write in xml. :) Seems 
> that the modules in /etc/grub.d are in xml. But I think editing grub.cfg 
> is no different than editing menu.lst. Just that methods for handling 
> grub2 is different than in grub-legacy. It's always more of a hassle 
> when we relearn changes in stuff we know than just learning a new stuff.
> 

I did once take a beginners course in html, So I don't think I'd have a
problem with that part either... ;-7 

I was actually trying to reference something about that method you mentioned
in that other thread about making changes in some default file someplace so
that the next automatic update of karmic's grub.cfg wouldn't undo all your
changes. And the sequence of system commands you suggested to do to verify
it resulted in a "good" grub.cfg before someone who didn't have a "first
boot" partition should reboot, verses the old grub claim that it was better
than lilo because you didn't need to do a simple scary "lilo -b bootdev"
command before any changes in the lilo.conf took effect...

> > It would appear that on Sep 25, Goh Lip did say:
> >> > Joe(theWordy)Philbrook wrote:
> >>> > > 
> >>> > > Does that mean that "grub legacy" is incapable of booting Karmic without
> >>> > > chainloading??? 
> >> > 
> >> > Yes, Joe, that is correct; you need chainload.
> > 
> > I really hope your wrong about that. But I suppose I'll just have to live
> > with it if your right. Certainly the chanloaded boot will be at least,
> > easier...
> 
> Yes, you can always keep your 'grub partition' (sda3) in grub-legacy and 
> boot karmic by chainloading.

Which I shall until I'm comfortable enough with grub2...

> >> > Thanks for sharing, I'll append my example below.
> > 
> > THANK YOU! those examples may just keep me from pulling what little hair I
> > have left out by the roots...
> 
> Guess i still have a full head of hair to afford. :)
> 

Lucky you!

> > Which reminds me, If it can boot an iso to correctly run something that
> > "thinks" it's a livecd, would it not also work to actually install a linux
> > directly from said iso" (that is, as long as the install doesn't disturb
> > the partition that grub2 is using, nor the partition the iso itself is on?)
> > 
> > Because THAT would be a good reason to switch...
> 
> Again Joe, I have no experience with this. Let us know when you do.
> I have been thinking, just thinking only, whether it is necessary to 
> have the iso in the same partition as the boot/grub. Then this menu 
> entry should be in the 2nd grub and the iso in that 2nd grub partition, 
> as my 'first grub partition' is only 150 MB. Let us know when you do, ya?

Of course, I'll have to actually install karmic first, And since I
currently ONLY have the laptop to work with, that would mean replacing
Jaunty... (Karmic is still beta right?) My basic plan would be to use the
usb drive to make a tarball of jaunty, then try to edit the
/etc/apt/sources.list, and "apt-get dist-upgrade" In hopes that I won't
have to fight my way through as many configuration and user set-up chores
(including adding and configuring the E17 window manager) as I would with
a clean install... (though as I recall when I tried to do that to move from
intrepid to jaunty, I broke so many things (I think it was mostly the kde3
vs kde4 differences) that I gave up and did a disk install instead)

But thanks to you, when I do upgrade to karmic, grub2 won't cause me nearly
so much grief... And No doubt, when I get ready to replace my outdated
OpenSuSE partition, (most likely with Elive) I'll try to install via that
grub2 iso booting technique, And then I'll try to remember to haunt you
with the results...

> > But if they stopped hiding the choice in the "advanced" options so that the
> > uninitiated might figure out that there is a choice, then I'd forgive them
> > for a lot more than a "cute" scolding...
> 
> Yes, it is still hidden under 'advanced'.
> 

---<sigh>--- Still this isn't as bad as the other aggravating thing that
most distro's still do of making sure that the uninitiated won't know that
the advanced "manual" partitioning options aren't that hard, and worse
still making the default assume linux is getting the whole disk... 
Which of course leads to many new users getting ticked because they didn't
want to lose their windows installation (yet)...
 
> > would I be able to use something like this??? :
> > 
> > menuentry "Karmic" {
> >   	set root=(hd0,5)
> >   	linux	/boot/vmlinuz-2.6.31-10-generic root=/dev/sda5 ro vga=normal
> >   	initrd	/boot/initrd.img-2.6.31-10-generic
> >   }
> 
> 
> I would think so, just that I just copied the same stuff from Karmic. I 
> also understand why you want to this. Before doing it, make a copy of 
> old, just in case.
> 

I'd be frightened if I thought there was the slightest chance I'd forget
to make a back-up of the working copy of something like this before
tinkering with it.

> 
> > I've never used insmod...  Does the "insmod ext2" in your example mean
> > grub2 needs such a line to work with the classic ext2 filesystem???
> 
> No, it is not necessary; just that it was generated in karmic grub and I 
> just copied over. My karmic is in ext4, yet the grub generated "insmod 
> ext2". What purpose it served? I haven't figured that out yet.
> 

Good!

> > Also, in YOUR karmic example, you specify which partition grub2
> > thinks of as root with the "set root=(hd0,5)" line, AND specified the
> > partition the linux kernal will use as root via the "root=UUID=..."
> > kernel argument... So what does that search command line that specifies the
> > same UUID do for you???
> 
> The search can search for partitions as well as UUID, and as in 
> grub-legacy, we can boot not just by UUID, but by partition number or 
> label also.

So then I could probably use /dev/disk/by-id structures as well then... :-)


It would appear that on Sep 26, Goh Lip did also say about editing grub.cfg:

> > I would think so, just that I just copied the same stuff from Karmic. I 
> > also understand why you want to this. Before doing it, make a copy of 
> > old, just in case.
> 
> 
> Additional note, BEFORE you do the above, best you make a grub2.iso cd.
> 
> grub-mkrescue gggrub.iso
> 
> This will ensure if we mess up, we can still enter into OS.
> Note this iso will NOT contain any grub.cfg entries. There is now a new 
> method to create with grub.cfg, but I have to check that up. But with 
> the "configfile" and "chainload" entries (enter manually), you can enter 
> any OS from that CD, whether or not you have any grub partition or 
> messed up your mbr.
> 
> To check which partition is available. type just "ls"
> To check which partition has menu.lst, type
> search -f /boot/grub/menu.lst
> To check which partition has grub.cfg, type
> search -f /boot/grub/grub.cfg

It would appear that on Sep 26, Goh Lip did additionally say:

> 
> My bad, Joe, I should complete my thinking before I send out messages...
> You can of course modify temporarily the entry by entering "e" at the 
> entry, modify it, then boot and see if it works, if not the entry is not 
> modified, so you can still have the right grub entries.
 
Actually I'm glad you told me how to make the grub2 rescue cd It would
be especially useful in case of a disastrously edited grub.cfg (or
menu.lst for that matter) that's installed to the mbr... (would the
grub rescue (grub shell?) have any help functions that could help me to
remember how to manually enter the "configfile" and "chainload" entries?)

But it shouldn't even become close to an issue until I'm ready to
replace my /dev/sda3 grub-legacy with grub2... Until then my habit of
making backup copies of last known good config files would let me
just boot a different linux, and restore the old grub.cfg so I can
again chainload it... And of course, at least until ALL my linux
actually require grub2 to successfully boot, I'd be able to use my
existing "supergrub" disk to fire up one of the others via the
grub-legacy installed to 'their' superblocks...

-- 
|  ~^~	 ~^~
|  <?>	 <?>		 Joe (theWordy) Philbrook
|      ^		      J(tWdy)P
|    \___/		   <<jtwdyp at ttlc.net>>