Re: [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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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! -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Dec 2, 2012, at 7:57 PM, John Reiser jrei...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On 2012-12-02 19:21 (GMT) bugzi...@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 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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) bugzi...@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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Sun, 02 Dec 2012 17:32:20 -0500 Felix Miata mrma...@earthlink.net wrote: On 2012-12-02 19:21 (GMT) bugzi...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Sun, 02 Dec 2012 23:36:58 +0100 Reindl Harald h.rei...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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.rei...@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.1.* 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Mon, 03 Dec 2012 00:21:44 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 03.12.2012 00:15, schrieb Kevin Fenzi: On Sun, 02 Dec 2012 23:36:58 +0100 Reindl Harald h.rei...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition
On Dec 2, 2012, at 4:12 PM, Kevin Fenzi ke...@scrye.com wrote: On Sun, 02 Dec 2012 17:32:20 -0500 Felix Miata mrma...@earthlink.net wrote: On 2012-12-02 19:21 (GMT) bugzi...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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 -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
