4:32 p.m.
On 2012-12-02 19:21 (GMT) bugzilla(a)redhat.com composed:
--- Comment #19 from Chris Murphy ---
Anaconda should not offer options that are expressly stated as not recommended
by upstream. The problem is ext4's boot sector is only 512 bytes, which is not
enough space. The use of --force fragments GRUB, and installs the pieces into
free space without informing the file system. At any future time the file
system can step on any one of those block lists and render the system
unbootable.
Upstream screwed up by replacing a bootloading system that can work
acceptably on partitions with one that the very same devs claim cannot.
Fedora should to compensate by providing an alternative to Grub2 that can do
what multiboot users want. Grub2, Grub Legacy and Lilo are not the only
bootloaders. http://en.wikipedia.org/wiki/Comparison_of_boot_loaders
Personally, I can't get Fedora installed the way I want in other regards as
well, so I install it its way, but it _never_ gets to boot that way even
once. Before ever booting it, I undo its boot track damage, and copy its / to
the partition I wanted it on in the first place but wouldn't let me. I
install Grub Legacy on this target, and either use it via chainload, or load
Fedora directly with my master bootloader installed to a different
_partition_, while my MBR as used remains compliant with legacy BIOS, OS/2,
DOS and Windows whether DOS or Windows or OS/2 are even installed.
Changing the boot track without permission is rude, particularly since it
doesn't bother to report it will obliterate what is already there present.
Fedora ought to be able to be put where the user wants it, on a partition
prepared as the user wants it prepared, without any bootloader if that's what
the user wants, and without writing anything to any partition table when it's
unnecessary and unwanted due to all partitioning having been done in advance
(see: Mandriva/Mageia: cmdline option "readonly=1" results in only
"partitioning" to allow selection of mount points for existing partitions).
Anyone who thinks Windows installation is rude or limiting needs to put on a
Fedora hat and look in the mirror.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
4:36 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
Am 02.12.2012 23:32, schrieb Felix Miata:
On 2012-12-02 19:21 (GMT) bugzilla(a)redhat.com composed:
> https://bugzilla.redhat.com/show_bug.cgi?id=872826
> --- Comment #19 from Chris Murphy ---
> Anaconda should not offer options that are expressly stated as not recommended
> by upstream. The problem is ext4's boot sector is only 512 bytes, which is not
> enough space. The use of --force fragments GRUB, and installs the pieces into
> free space without informing the file system. At any future time the file
> system can step on any one of those block lists and render the system
> unbootable.
Upstream screwed up by replacing a bootloading system that can work acceptably on
partitions with one that the very
same devs claim cannot. Fedora should to compensate by providing an alternative to Grub2
that can do what multiboot
users want. Grub2, Grub Legacy and Lilo are not the only bootloaders.
http://en.wikipedia.org/wiki/Comparison_of_boot_loaders
grub2 in fedora is crap
https://bugzilla.redhat.com/show_bug.cgi?id=882721
grub was a bootloader, grub2 is a operating system with tons
of scripts some guys are calling "configuration" and full
of bugs
grub2 is fragile or why does F16/F17 not get the final version?
because maintainers fear it is more worse as beta6
5:15 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Sun, 02 Dec 2012 23:36:58 +0100
Reindl Harald <h.reindl(a)thelounge.net> wrote:
grub2 in fedora is crap
https://bugzilla.redhat.com/show_bug.cgi?id=882721
I'm not the grub2 maintainer, but personally I would ask you for a
more understandable report. What did you want to happen? What happened?
Whats your config?
Perhaps expanding on your bug report would get it more attention?
grub was a bootloader, grub2 is a operating system with tons
of scripts some guys are calling "configuration" and full
of bugs
grub2 is fragile or why does F16/F17 not get the final version?
because maintainers fear it is more worse as beta6
I've not looked at the changes between beta6 and final, perhaps they
are minor and not worth the update? Or perhaps they require something
thats not available in f16/f17?
kevin
5:21 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
Am 03.12.2012 00:15, schrieb Kevin Fenzi:
On Sun, 02 Dec 2012 23:36:58 +0100
Reindl Harald <h.reindl(a)thelounge.net> wrote:
> grub2 in fedora is crap
> https://bugzilla.redhat.com/show_bug.cgi?id=882721
I'm not the grub2 maintainer, but personally I would ask you for a
more understandable report. What did you want to happen? What happened?
Whats your config?
Perhaps expanding on your bug report would get it more attention?
the same password protection for the bootloader which was possible
for dacades with "grub-legacy" - request the password if someone
is touching the boot-entry but leave the user in peace for a
untouched boot
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.*********************
export superusers
results in a password request every time
______________________________
menuentry 'Fedora (3.6.8-2.fc17.x86_64)' --unrestricted --class fedora --class
gnu-linux
brings back the behavior only request a password if you try to boot
as example in single-user-mode or modify any kernel-param
"--unrestricted" is the key to bring back this behavior
this was NOT the case for all grub2-releases
it is a MAJOR DEGRADE of a bootloader having problems to secure
it with a password because it is HARDLY needed if you want to be
sure that nobody bypass your boot-configuration after you made
sure your BIOS settings are protected with a password and boot
from any external media is disallowed
5:29 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Mon, 03 Dec 2012 00:21:44 +0100
Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 03.12.2012 00:15, schrieb Kevin Fenzi:
> On Sun, 02 Dec 2012 23:36:58 +0100
> Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
>> grub2 in fedora is crap
>> https://bugzilla.redhat.com/show_bug.cgi?id=882721
>
> I'm not the grub2 maintainer, but personally I would ask you for a
> more understandable report. What did you want to happen? What
> happened? Whats your config?
>
> Perhaps expanding on your bug report would get it more attention?
...snip...
I meant update the _BUG_ with the additional info? :)
Thanks for doing that, perhaps it will get some action...
kevin
5:12 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Sun, 02 Dec 2012 17:32:20 -0500
Felix Miata <mrmazda(a)earthlink.net> wrote:
On 2012-12-02 19:21 (GMT) bugzilla(a)redhat.com composed:
> https://bugzilla.redhat.com/show_bug.cgi?id=872826
> --- Comment #19 from Chris Murphy ---
> Anaconda should not offer options that are expressly stated as not
> recommended by upstream. The problem is ext4's boot sector is only
> 512 bytes, which is not enough space. The use of --force fragments
> GRUB, and installs the pieces into free space without informing the
> file system. At any future time the file system can step on any one
> of those block lists and render the system unbootable
This sounds like a different bug than the one thats in the report
above. I'd advise the commenter to open a new one on mkfs or anaconda
to change the boot sector padding.
...snip...
Changing the boot track without permission is rude, particularly
since it doesn't bother to report it will obliterate what is already
there present. Fedora ought to be able to be put where the user wants
it, on a partition prepared as the user wants it prepared, without
any bootloader if that's what the user wants, and without writing
anything to any partition table when it's unnecessary and unwanted
due to all partitioning having been done in advance (see:
Mandriva/Mageia: cmdline option "readonly=1" results in only
"partitioning" to allow selection of mount points for existing
partitions).
How can anaconda know all that? If you are dual booting a bunch of
OSes, don't you already have to manually decide how you want things to
chainload and update? I think a default of MBR with an option to not do
anything seems reasonable... how does the 'don't do anything with
bootloaders' not meet your needs?
Anyone who thinks Windows installation is rude or limiting needs to
put on a Fedora hat and look in the mirror.
This is the kind of comment that makes some people less likely to
listen to the rest of your argument... IMHO.
kevin
7:17 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On 2012-12-02 18:12 (GMT-0500) Kevin Fenzi composed:
On Sun, 02 Dec 2012 17:32:20 -0500 Felix Miata wrote:
> Changing the boot track without permission is rude, particularly
> since it doesn't bother to report it will obliterate what is already
> there present. Fedora ought to be able to be put where the user wants
> it, on a partition prepared as the user wants it prepared, without
> any bootloader if that's what the user wants, and without writing
> anything to any partition table when it's unnecessary and unwanted
> due to all partitioning having been done in advance (see:
> Mandriva/Mageia: cmdline option "readonly=1" results in only
> "partitioning" to allow selection of mount points for existing
> partitions).
How can anaconda know all that?
You mean besides offering a cmdline option to tell Anaconda don't touch any
partition tables?
If you are dual booting a bunch of
OSes, don't you already have to manually decide how you want things to
chainload and update? I think a default of MBR with an option to not do
I think MBR _default_ is inappropriate _every_ time Anaconda finds itself
faced with a multiboot system. In these cases presuming one wants the
existing bootloading configuation replaced is inane.
What to do about bootloader should be prominent and early. YaST gets the
idea: http://fm.no-ip.com/SS/yast2-is-exp.png (6 years ago).
anything seems reasonable... how does the 'don't do anything
with
bootloaders' not meet your needs?
It needs to be put where it can be found. "It never presented an opportunity
to discuss the bootloader."
http://lists.fedoraproject.org/pipermail/test/2012-December/111977.html
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:30 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Dec 2, 2012, at 4:12 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sun, 02 Dec 2012 17:32:20 -0500
Felix Miata <mrmazda(a)earthlink.net> wrote:
> On 2012-12-02 19:21 (GMT) bugzilla(a)redhat.com composed:
>
>> https://bugzilla.redhat.com/show_bug.cgi?id=872826
>
>> --- Comment #19 from Chris Murphy ---
>> Anaconda should not offer options that are expressly stated as not
>> recommended by upstream. The problem is ext4's boot sector is only
>> 512 bytes, which is not enough space. The use of --force fragments
>> GRUB, and installs the pieces into free space without informing the
>> file system. At any future time the file system can step on any one
>> of those block lists and render the system unbootable
This sounds like a different bug than the one thats in the report
above. I'd advise the commenter to open a new one on mkfs or anaconda
to change the boot sector padding.
I'm not seeing such an option in mke2fs. If it is possible to change the
padding/offset, then it would be possible for a continuous installation of GRUB2's
boot.img and core.img, without using block lists.
I did get slightly incorrect, ext4 has two boot sectors, for a total of 1024 bytes of code
which is still too small for GRUB to fit without block lists. I'm curious how other
bootloaders get away with less.
Chris Murphy
8:57 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
I'm not seeing such an option in mke2fs. If it is possible to
change the padding/offset, then it would be possible for a continuous installation of
GRUB2's boot.img and core.img, without using block lists.
I did get slightly incorrect, ext4 has two boot sectors, for a total of 1024 bytes of
code which is still too small for GRUB to fit without block lists. I'm curious how
other bootloaders get away with less.
Fourteen years ago in 1998 I published a boot loader for i386 that loaded linux
kernel and initrd using filesystem lookup by name from ext2, occupying 446 bytes
of MBR plus 2*510 bytes of bootblock from ext2. The space also allowed some
tens of bytes of kernel command line. So "must use block lists" was not true
then.
The code is still available at:
http://www.bitwagon.com/ftp/e2boot4c.tgz
http://www.bitwagon.com/ftp/mbr03.tgz
--
12:14 a.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Dec 2, 2012, at 7:57 PM, John Reiser <jreiser(a)bitwagon.com> wrote:
Fourteen years ago in 1998 I published a boot loader for i386 that
loaded linux
kernel and initrd using filesystem lookup by name from ext2, occupying 446 bytes
of MBR plus 2*510 bytes of bootblock from ext2. The space also allowed some
tens of bytes of kernel command line. So "must use block lists" was not true
then.
Yeah obviously I asked the wrong question, again. I will digress instead of asking a new
(bad) question:
1. Another possible work around.
In addition to the "do nothing" and "install to MBR + MBR gap"
options, is the "make a core.img and grub.cfg, but do not install anything to MBR,
the MBR gap, or use block lists" option. This core.img could be called by another
boot manager, presumably already installed and in use by the user, the one they don't
want stepped on in the first place. If they load the /boot/grub2/core.img, it will in turn
load the grub.cfg and they get a GRUB menu as expected. To do this anaconda would use
grub2-mkimage instead of grub2-install; it would use grub2-mkconfig as it currently does
to generate the grub.cfg.
I think that work around satisfies most concerns, albeit without automatically linking the
existing boot manager to the core.img file. The user wouldh have to do that themselves
(rather than relying merely on a change in the MBR active flag).
2.
Incidentally, Btrfs has a 64KB offset before the start of the file system, which I
confirmed on the btrfs list is intended for a boot mananager/loader. Because of how btrfs
works, block lists are not merely "not recommended" but proscribed, the --force
option fails, but as it turns out you don't need to use block lists with Btrfs because
core.img and then some will happily fit in the rather enormous boot loader region
completely contiguously intact. And I've confirmed that it does work, both
installation of GRUB2 into this region, as well as it being loaded and functioning (ergo
100% Btrfs boot, even with boot and root in subvols).
So the solution to the problem maybe for F19/F20 is actually Btrfs by default, and then
grub2-install to a partition can be employed once again and simply just work without extra
effort on the part of the user as is the case with work around 1.
Chris Murphy
7:44 a.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Sun, Dec 02, 2012 at 04:12:09PM -0700, Kevin Fenzi wrote:
This sounds like a different bug than the one thats in the report
above. I'd advise the commenter to open a new one on mkfs or anaconda
to change the boot sector padding.
It's part of the filesystem format, there's no way to change it.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:58 a.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
Am 03.12.2012 14:44, schrieb Matthew Garrett:
On Sun, Dec 02, 2012 at 04:12:09PM -0700, Kevin Fenzi wrote:
> This sounds like a different bug than the one thats in the report
> above. I'd advise the commenter to open a new one on mkfs or anaconda
> to change the boot sector padding.
It's part of the filesystem format, there's no way to change it
in other words - grub2 is way to bloated for a boot-loader and
looks more like a operating system with it's own scripting
language as a bootloader
that is also the reason why /boot has to start on 2048
while over decades it was not needed
12:37 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Monday 03 December 2012 14:58:05 Reindl Harald wrote:
that is also the reason why /boot has to start on 2048
while over decades it was not needed
You really want your partitions to be nicely aligned when using SSDs or
similar.
12:41 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
Am 03.12.2012 19:37, schrieb Lars Seipel:
On Monday 03 December 2012 14:58:05 Reindl Harald wrote:
> that is also the reason why /boot has to start on 2048
> while over decades it was not needed
You really want your partitions to be nicely aligned when using SSDs or
similar.
maybe, but as example i do not want to resize /boot of
more than 20 perfect working fedora-VM's which are
living on a vSphere environment with a SAN storage as
backend as forced with F16 because they are not interested
in which physical media is behind the SAN
happily i decided 2008 to make own virtual disks for
boot, sysroot, /var/cache, /var/log, /tmp and data
so i had only to resize/move /boot without downtime
and blow the dd-image from the goldenmaster to all
other VMs
9:25 a.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On 12/03/2012 05:44 AM, Matthew Garrett wrote:
On Sun, Dec 02, 2012 at 04:12:09PM -0700, Kevin Fenzi wrote:
> This sounds like a different bug than the one thats in the report
> above. I'd advise the commenter to open a new one on mkfs or anaconda
> to change the boot sector padding.
It's part of the filesystem format, there's no way to change it.
This may be true, but not a priori. extN has feature flags which can
be used to enable leaving more space, or other larger space at a "constant"
offset. For example, the first otherwise-allocatable filesystem block might
be permanently allocated for use by booting. There may be other ways, too.
If not, then there is ext5. Deprecate ext4 for its mistake in not allowing
a maximal-sized filesystem block [8KiB] for the boot block.
And oh by the way, several years ago ext3 was "fixed" in a non-backwards
compatible way involving symbolic links. The "fix" changed the interpretation
of on-disk file system data!
--
2:54 p.m.
New subject: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Mon, Dec 03, 2012 at 07:25:16AM -0800, John Reiser wrote:
On 12/03/2012 05:44 AM, Matthew Garrett wrote:
> It's part of the filesystem format, there's no way to change it.
This may be true, but not a priori. extN has feature flags which can
be used to enable leaving more space, or other larger space at a "constant"
offset. For example, the first otherwise-allocatable filesystem block might
be permanently allocated for use by booting. There may be other ways, too.
Sure, this is a problem that could be solved. But nobody's working on
solving it, and it's not going to be solved in time for F18.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4153
days inactive
4155
days old
15 comments
7 participants
participants (7)
-
Chris Murphy -
Felix Miata -
John Reiser -
Kevin Fenzi -
Lars Seipel -
Matthew Garrett -
Reindl Harald