Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#20077 - [grub2] mkconfig doesn't handle initrd-less kernels correctly

Attached to Project: Arch Linux
Opened by Ayla Ounce (reacocard) - Monday, 05 July 2010, 05:05 GMT
Last edited by Ronald van Haren (pressh) - Tuesday, 03 May 2011, 14:00 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

When using GRUB2's grub-mkconfig to generate a grub.cfg, all kernels in boot are detected and entries added for them, however all entries also get a Fallback entry, even if no fallback initrd exists (as is the case for my initrd-less custom kernel). mkconfig should check for the existence of the Fallback initrds, and not create entries for them if they do not exist.

Additional info:
* GRUB2 version 1.98-4 from [extra]

Steps to reproduce:
1) Put a kernel image in /boot that does not have a corresponding fallback initrd image
2) Run grub-mkconfig
3) Observe that there is a Fallback entry for kernel image from step 1, though the image path referenced does not exist.
This task depends upon

Closed by  Ronald van Haren (pressh)
Tuesday, 03 May 2011, 14:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  added your new patch in the upcoming version
Comment by Matthias Dienstbier (fs4000) - Friday, 18 March 2011, 12:18 GMT
I also experienced this problem because I don't have a fallback image with Arch's default kernel.

New patch is attached.

2 additional minor faults:
- 05_archtheme isn't needed anymore because the patch adds config options for the colors
- the patch is marked executable in git
   archlinux_grub2_mkconfig_fixe... (3.3 KiB)
Comment by Anonymous Submitter - Tuesday, 19 April 2011, 15:00 GMT
Use updated patch in http://aur.archlinux.org/packages.php?ID=41055 for 1.99 final release pkgs since the patch has diverged in bzr trunk.
Comment by Matthias Dienstbier (fs4000) - Saturday, 23 April 2011, 07:48 GMT
patch from aur doesn't contain my changes
Comment by Matthias Dienstbier (fs4000) - Saturday, 23 April 2011, 12:13 GMT
New and simplified patch for grub 1.99 rc2. Fallback option is only added if there is an appropriate *-fallback.img.

The misuse of the version parameter of linux_entry() had some side effects. In the second patch I added the possibility to append text to the title and set the recovery parameter of Fallback to true because otherwise GRUB would save that entry as default if GRUB_SAVEDEFAULT is true.
   archlinux_grub2_mkconfig_fixe... (3.2 KiB)
   archlinux_grub2_mkconfig_fixe... (3.5 KiB)
Comment by Ronald van Haren (pressh) - Tuesday, 26 April 2011, 09:42 GMT
Sorry, I thought it was included in the patch Keshav provided. I'll include the new patch in a bugfix release today or tomorrow.
Comment by Matthias Dienstbier (fs4000) - Wednesday, 27 April 2011, 15:58 GMT
I also reworked the PKGBUILDs. Was there a reason to disable efiemu on 32bit bios?

Changes (oriented at Debian):
- removed enable/disable-efiemu (enabled for bios version by default)
- bin and sbin moved to /usr
- moved some binaries to platform dependant package and made packages conflicting each other

Is that ok?
(application/x-gzip)    grub2-PKGBUILD.tar.gz (2.6 KiB)
Comment by Anonymous Submitter - Wednesday, 27 April 2011, 18:23 GMT
@fs4000: Try building efiemu in i686 . It will fail. grub2-bios x86_64 package has efiemu enabled.

GRUB_CONTRIB should have absolute path to work, relative paths confuses the build system.

Don't know about platform specific binaries. The only minor change require for platform specific binary is grub-install which is taken care by sed. I would prefer to keep binaries under grub2-common and as simple as possible isntead of keeping track of every platform specific binary.

Also you forgot about grub2-efi-x86_64. Otherwise the PKGBUILD looks ok but the changes look cosmetic and unnecessary to me.
Comment by Anonymous Submitter - Wednesday, 27 April 2011, 18:28 GMT
[quote - Matthias Dienstbier (fs4000)]
- moved some binaries to platform dependant package and made packages conflicting each other
[/quote]

Big no. Many systems support both bios and uefi boot modes and some installer scripts rely on both not conflicting on each other. This was a deliberate choice i made when i wrote the PKGBUILDs, packages should co-exist. Some installers like archboot rely on that for the same reason. I personally use both grub2-bios and grub2-efi-x86_64 on my system. Installing the package does not automatically setup the bootloader (unlike in Debian/Ubuntu) so no problem in them co-existing in the same system.
Comment by Ronald van Haren (pressh) - Wednesday, 27 April 2011, 18:42 GMT
I agree with Keshav here, I don't see a good reason to move files around in the different splitted packages.

As for /bin and /sbin, they should NOT move to /usr/bin and /usr/sbin. Please see http://www.pathname.com/fhs/pub/fhs-2.3.html
Comment by Matthias Dienstbier (fs4000) - Wednesday, 27 April 2011, 22:27 GMT
It's not only grub-install but also grub-mkrescue, grub-mknetdir and grub-setup (doesn't exist in an efi build). We should at least provide grub-mkrescue and grub-mknetdir for the two efi packages. In which package is not so important, but I thought it would be cleaner if one doesn't have scripts and binaries for platforms that are not installed.

I don't really see the sense of putting binaries/scripts directly into /bin and /sbin while they rely on stuff that is under /usr/lib/grub.

I see, on 32 bit configure doesn't enable efiemu by default, so mine and your PKGBUILD do exacly the same.
Comment by Ronald van Haren (pressh) - Thursday, 28 April 2011, 06:45 GMT
[quote="fs4000"]I don't really see the sense of putting binaries/scripts directly into /bin and /sbin while they rely on stuff that is under /usr/lib/grub.[/quote]

Sure, but then the move should be the other way around as we try to follow the FHS. The libs should be moved to /lib.
Comment by Ronald van Haren (pressh) - Thursday, 28 April 2011, 06:47 GMT
Please remain with the original topic (handling initrd-less kernels). If there are other issues please or feature requests open separate bug reports for those.

Loading...