[Bug 1652332] Re: Alternative to BIOS-Boot partition
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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?. ** Attachment added: "contents of MBR of GPT device" https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+attachment/4953410/+files/boot2.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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. ** Attachment added: "Boot1.doc" https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+attachment/4953088/+files/Boot1.doc -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
Helleo Thanks for yor anwser and remark. But i thinks that ubuntu 16.04 use already this technic. ** Attachment added: "Legacy boot on GPT deice without partition boot" https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+attachment/4952805/+files/boot.doc -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1652332] Re: Alternative to BIOS-Boot partition
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. ** Project changed: ubiquity => ubiquity (Ubuntu) ** Changed in: ubiquity (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652332 Title: Alternative to BIOS-Boot partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
