Hide Forgot
Description of problem: grub2 takes its sweet time to load initrds. A 16 MB initrd takes seconds. It seems this is a known problem for which the Ubuntu people just made a patch: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/944347 Version-Release number of selected component (if applicable): grub2-1.99-13.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. Boot with grub2. Additional info:
Are you sure that patch makes any difference? How much? It refers to an EFI issue and you do apparently not use EFI. grub2 upstream do also not agree with the ubuntu patch ... but the code has for other reasons been refactored in a way that should solve any the problem the ubuntu patch might try to solve.
Hello Do you have a link (Git, whatever) to the recent upstream changes? We'd like to test them in a QEMU/KVM setup, which is where we are having the most problems. We have a similar problem using QEMU/KVM without GRUB2: bug #730128. That being said, it's also painfully slow on real hardware: it's faster to PXE boot with our large initramfs than it is to use GRUB2 from local disk. Cheers Albert
2011-06-23 Vladimir Serbinenko <phcoder> Support non-512B sectors and agglomerate reads. * Makefile.util.def (libgrubmods.a): Add grub-core/commands/testload.c. * grub-core/disk/efi/efidisk.c (grub_efidisk_data): Remove disk_io. (disk_io_guid): Removed. (make_devices): Locate solely by BlockIO. (grub_efidisk_open): Fill log_sector_size and total_sectors. (grub_efidisk_read): Use read_blocks. (grub_efidisk_write): Use write_blocks. * grub-core/disk/i386/pc/biosdisk.c (grub_biosdisk_open): Fill log_sector_size. (get_safe_sectors): Handle non-512B sectors. (grub_biosdisk_read): Remove special CDROM handling. Handle non-512B sectors. (grub_biosdisk_write): Handle non-512B sectors. * grub-core/disk/scsi.c (grub_scsi_open): Fill log_sector_size. (grub_scsi_read): Remove special non-512B block handling (now handled one level up). * grub-core/kern/disk.c (grub_disk_open): Fill default log_sector_size and do sanity checks. (grub_disk_adjust_range): Handle non-512B sectors. (transform_sector): New function. (grub_disk_read_small): Likewise. (grub_disk_read): Rewritten. (grub_disk_write): Handle non-512B sectors. * grub-core/kern/emu/hostdisk.c (grub_util_biosdisk_open): Fill log_sector_size. (open_device): Use log_sector_size. (grub_util_biosdisk_read): Likewise. (grub_util_biosdisk_write): Likewise. * grub-core/partmap/msdos.c (grub_partition_msdos_iterate): Handle non-512B sectors. (pc_partition_map_embed): Likewise. * include/grub/disk.h (grub_disk): New field log_sector_size. (GRUB_DISK_CACHE_SIZE): Redefined from GRUB_DISK_CACHE_BITS. (GRUB_DISK_CACHE_BITS): Increased to 6. * util/grub-fstest.c (fstest): New command testload. (argp_parser): Likewise. You can give http://koji.fedoraproject.org/koji/buildinfo?buildID=310417 a try. Some benchmarks with different GRUB_DISK_CACHE_BITS sizes in include/grub/disk.h would probably be interesting and convincing upstream. ... but in the bootstrap process the bootloader has to use the old primitive IO functions. I wouldn't expect them to be as efficient as the modern interfaces exposed by the kernel. It might thus not be a good idea to use a 100+ MB initrd. I can imagine that a multi staged approach might be more efficient.
grub2-2.0-0.24.beta4.fc17 has been pushed to f17 stable. Please provide some numbers or uptodate references that demonstrate the problem with that version.
This bug appears to still be in Fedora 17. On a fast SSD drive, I'm seeing it take 15 seconds just to load in the initrd. This is longer than what a 5400 RPM platter-based disk takes in Fedora 15, for both the kernel and the initrd. The SSD drive benchmarks in about 5-6 times faster than what the 5400 RPM drive does.
Please try with http://koji.fedoraproject.org/koji/buildinfo?buildID=322368 which is very close to where upstream development / bugfixing is happening.
Thanks, Mads, Alas, I still see the long delay with that version.
Just an update. Tried the Ubuntu fix by increasing GRUB_DISK_CACHE_BITS, for 4K and 16K. Managed to decrease the initrd loading time from about 15 seconds down to 9 seconds. This is still not acceptable, because a 30 MB initrd ought to be loading much, much faster on an SSD drive. Like in about 1 second. Took out the second hard disk (the slow Winchester based one), and saw the initrd load real fast. This is, alas, not repeatable. Sometimes it works, but too often, it doesn't. I don't think there's a prayer of a chance of debugging this issue unless one has hardware on which to reproduce the behaviour. So, I'm going to build a debugging version of grub2 and see if I can gather any more info.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.