Re: Details behind a GRUB2 warning message?

(Thanks for starting this thread, Richard, I finally found out how to access the grub lists.)

On Sun, Apr 6, 2014 at 2:22 PM, Richard Owlett <rowlett@cloud85.net> wrote:

Tom H wrote:

On Fri, Apr 4, 2014 at 9:59 AM, Richard Owlett <rowlett@cloud85.net> wrote:

Thank you. My individual use case appears to be adequately safe, perhaps
more due to good luck than good management. However a couple of side
comments plus something I read somewhere hints at a more elegant solution.
Will have to some experiments.

Let's assume that you have two Linux installations on sda, on sda1 and
sda2, and that grub is embedded in the mbr of sda for sda1 and in the
pbr/vbr of sda2 for sda2.

Preamble:
I was recently reminded that " [my] ignorance is archived. :) "

And so is someone else's arrogance. Ignorance, arrogance, the only problem is when people refuse to change.

I have two distinct use cases
1. one machine has multiple Debian installs {primary and logical partitions}
2. one machine has WinXP on sda1 with multiple Debian installs on both
primary and logical partitions with several logical partitions formatted
as NTFS

I used to have two Fedoras, one openSUSE, Solaris, and a BSD, maybe two, on one machine. When you're learning, it's important to do things like that.

For the record ;/
1. I have no idea what "pbr/vbr" means

I believe he's talking about the partition boot record and the volume boot record.

2. I've not yet Googled 'chainloading of boot loaders'

If it's sda1's grub to which the bios hands over the boot process,
you'll be booting the installation on sda2 with one of these three,
"linux (hd0,msdos2)/boot/vmlinuz...", "configfile
(hd0,msdos2)/boot/grub/grub.cfg", "multiboot
(hd0,msdos2)/boot/grub/i386-pc/core.img", and none of them can be
affected by the block list issue.

IMNSHO, chain-loading is the only correct way to boot multiple OS instances.

In the current one-boot-loader-to-rule-them-all approach of grub2, you upgrade any kernel and you have to boot whichever OS contains the master configuration to update the list and locations of valid kernels. Either that, or every OS you boot has to avoid changing whatever grub expects to be looking for when it's looking for the kernel. (Effective name and/or physical location.) That's just asking for unbootable systems.

In the chain-loading approach, every partition has some extra space in it's structure header, just like the disk itself has some extra space in the master boot record, and the extra space doesn't move (doesn't get renamed, etc.), unless you do something to the partition itself. So the chain-loading approach (if I understand it correctly) uses that extra space to chain to the system in that partition.

The clear advantage to this approach is that the system that uses a partition can maintain its own boot records, so you don't have to remember who has the master configuration file. Another clear advantage is that the (boot process of the) system that has to read a particular file system is the one that has the drivers for it.

The only problem is that there is a new file system (XFS was it?) whose developers were so arrogant that they thought they had to use every last byte on the stupid partition, just because they could. And the current grub crew seems to think that catering to that crowd's file system is more important than best practices. (And it gives a "good" excuse to take the omnipotent approach, which is always a real stroke to the ego, even though it is almost always absolute worst practice.)

My machine with only Debian *appears* well behaved.

According to what people are saying in the referenced ML threads, that shouldn't be surprising. (If something goes hay-wire and messes with that extra, hard-to-maintain list of absolute sector addresses, there's a problem, but you always expect problems anyway when that sort of thing happens. Is what the grub developers are saying, which is why the warning sounds dangerous to us but not to them. :-/ )

My machine with both Windows and Debian gives me fits.

Likewise. MSWindows is the other odd toe in the pool, insisting on doing non-best practices, but that is no surprise.

You did notice that the advice is to let MSWindows make the original cut of the partitions, then never let the MSWindows partitioning utility look at he partitions again? Well, no, that's not going to work if you have to add or delete NTFS partitions.

Which is one good reason to use LVM instead of DOS-extended partitions for Linux, if you are sharing a disk between the two kinds of OSses.

I have more reading to do before asking intelligent (aka answerable) questions.

P.S. Having written one test procedure and one manual (decades ago) I *DO* believe in reading documentation ;)

Well, writing documentation is (unfortunately) no proof of a willingness to read. (Just like reading documentation is no guarantee of understanding it.) Which has absolutely nothing to do with anything here.

Documentation, and the reading or not reading of it, was not the problem in the first place.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.