Alternative to BIOS-Boot partition

[Bougron]

Hello
Since the beginning of LEGACY installations with a formatted disk MSDSOS,
It was necessary to create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag)

It seems to me that there is a much better solution.
Write in the MBR the address of the image file that is in the root partition

I saw this in a boot info that I send you for detailed analysis

It is possible that I was mistaken in the comprehension of the report

However the computer boots very well. I did not see any partition (FAT or bios-boot). It's a mystery.

[YannUbuntu (yannubuntu)]

thx Bougron for your report.
I think this is a suggestion you could submit to GRUB developers (or UBIQUITY developers).

[Colin Watson (cjwatson)]

Thanks for the suggestion. However, we very deliberately don't do it the way you suggest, because it would mean the boot loader would too easily be broken by perfectly legitimate internal rearrangements performed by the file system. For example, a file system might quite reasonably move the physical locations of files during fsck, and we don't want that kind of thing to require updating the parts of the boot loader in the MBR. A dedicated partition is much more robust.

[Bougron (francis-bougron)]

Helleo
Thanks for yor anwser and remark. But i thinks that ubuntu 16.04 use already this technic.

[Bougron (francis-bougron)]

I remember that with MS-DOS device you write the beginning of the boot from sector 1 to sector 2047.

Why, it is not possible to write the same thing from sector 256 to sector 2047 when the device is GPT except if this sequence is too big?.

But if this sequence is realy too big, one day, it will be the same thing for MS-DOS device.......

[Colin Watson (cjwatson)]

In your original report, you said "in the root partition". The technique we use on MBR disks is to write the GRUB core image *outside* any partition, in the area before the first partition sometimes called the "boot track" or the "embedding area". This is at least safe against being rearranged by file system implementations, as I noted above.

But having the boot loader's code outside any partition has its problems. It means that the space in question isn't clearly allocated for use by the boot loader, so it's possible for it to be capriciously overwritten by something else that decides to make use of an unallocated area of disk. (Such software in fact exists, and has resulted in quite a few very strange bug reports. GRUB has to take some quite exotic defensive measures against it.) The reason that we don't normally use a partition on MBR disks despite this problem is that the MBR format has rather restrictive rules for partitions, especially if you're trying to install the OS on a system that already has some other OS installed, and it works out better to avoid using a whole partition just for the boot loader.

GPT has much more sensible partitioning rules, and it's straightforward to just use a partition there. This gets us the best of both worlds: we don't have to worry about our bits being overwritten by other software (malicious or otherwise - I've seen both) that writes into the area before the first partition, and we don't have to worry about them being moved around by a file system implementation because that partition is just raw and doesn't contain a file system. In a way it is a bit like the behaviour you observe on MBR disks, except it's better: rather than hoping that nobody else will write into the same area of disk, we require that it be made it clear in the partition table which area of disk we're using.

So it is true that it would be technically possible to return GPT disks to the prior practice from MBR disks of not bothering to indicate in the partition table what area of disk we're using and just picking an area that's unlikely to be used by anything else; but it would be a step backwards, and so we won't do that.

[Bougron (francis-bougron)]

Thank you very much for your detailed explanations.
So I think there is a huge malfunction in the ubuntu installation software version 16.04. and perhaps the following ones because in version 1404 this was not possible.
Is it possible to confirm and to raise the problem.

[Colin Watson (cjwatson)]

I don't think I understand what you're objecting to. Is the problem that the installer failed to set up the correct partitioning structure? If so, we'd need installer logs (/var/log/installer/syslog and /var/log/installer/partman). If the problem is something else, please explain what's going on in plain language rather than continuing to throw large attachments at us.

(It would generally be appreciated if you could attach text files separately as plain text and where necessary explain what they relate to, rather than pasting them all into a large LibreOffice document.)

[Bougron (francis-bougron)]

Sorry for having provided you the entire boot-info report from a windows XP.

I just extracted the part that surprises me.
The question is simple:
Is it a good installation?
Is this a bug from the installer?
If Yes, will it be corrected?.

[Colin Watson (cjwatson)]

It seems wrong to me that the system has neither an EFI System Partition nor a BIOS Boot Partition, certainly, but it could well have been the result of manual partitioning, in which case it wouldn't be a bug: the installer does not guarantee to protect the user from all possible misconfigurations. That's why we need installer logs as I mentioned in my previous comment: they should make it possible to determine how the system ended up that way.