FS#25453 - [grub2] linux with grub2, name of Arch in boot menu is odd.

Attached to Project: Arch Linux
Opened by Mitchell Richters (mjr4077au) - Monday, 08 August 2011, 10:37 GMT
Last edited by Andrea Scarpino (BaSh) - Wednesday, 28 March 2012, 19:34 GMT
Task Type General Gripe
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 3
Private No

Details

Description:

After installing linux 3.0.1-1, the naming I have is "Arch Linux, with Linux linux". The fallback image is "Arch Linux, with Linux linux fallback".

Not really a bug, but just looks weird.


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Wednesday, 28 March 2012, 19:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  grub2-common 1:2.00beta2-2
Comment by Ronald van Haren (pressh) - Monday, 08 August 2011, 11:27 GMT
Yes it looks a bit ugly.

The naming scheme seems to be
$DISTRO, with Linux $kernelname

do you have a better naming scheme for all in $DISTRO and $kernelname?
Comment by Mitchell Richters (mjr4077au) - Monday, 08 August 2011, 11:50 GMT
You know, I actually didn't think of an alternative. Perhaps "$DISTRO, using Linux uname -sr"?

Are there any standards regarding boot loader entries?
Comment by Mitchell Richters (mjr4077au) - Monday, 08 August 2011, 12:05 GMT
Just realised that using "uname -sr" will give you information from the running kernel, not the new one. It is 10pm in Australia though and I've been on the go since 5am :(

Perhaps just "$DISTRO, using Linux $pkgver"? That's actually better than using the "uname -sr" before, as that only gives you the major version of "3.0-ARCH", not the point version.
Comment by Ronald van Haren (pressh) - Monday, 08 August 2011, 12:09 GMT
Not sure if that works. I think grub2 also detects kernels from other distros so it should work for all. There is no need to rush here, so we can think a bit longer if we can come up with something that works for all kernels it detects.
Comment by Mitchell Richters (mjr4077au) - Monday, 08 August 2011, 12:12 GMT
I agree completely, definitely should get some input from other Archers :)
Comment by Matthias Dienstbier (fs4000) - Saturday, 27 August 2011, 14:36 GMT
The actual problem is still our kernel naming scheme. Most distros append the kernel version after vmlinuz. But if we would do that now you would have to change your bootloader configuration on every major kernel update.  FS#16702  might fix that one day.
It would have looked a bit better, if the kernel were named vmlinuz-ARCH, but I don't know why we use CONFIG_LOCALVERSION in our main kernel at all.
Comment by Mitchell Richters (mjr4077au) - Sunday, 28 August 2011, 10:03 GMT
Even if it just said "Arch Linux", without the rest. "Arch Linux" implies it's Linux, and since Arch is a Rolling Release, it should be versionless. The only issue I can think that'd crop up is what about LTS kernels?
Comment by MG (elmurato) - Friday, 20 January 2012, 22:49 GMT
I didn't like that, too. So I did a (maybe dirty) workaround:

In "/etc/grub.d/10-linux" in the function "linux_entry()": Change "version=$2" to "version=$(pacman -Q linux | awk '{print $2;}')". It should use the package version. I hope it helps ;)
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 06 February 2012, 15:17 GMT
@MG: Any change made should be independent of distro or package manager agnostic. The problem here is the Arch's kernel package-naming policy. However your change can be incorporated into a patch by first detecting whether the user is running Arch, and then using the pacman -Q option. But such a patch will never be accepted by upstream (since it really is Arch specific).
Comment by Rorschach (Rorschach) - Monday, 13 February 2012, 12:57 GMT
I think I don't get the point here. I see it's an arch-specific problem because of the kernel naming. Two possible solutions:

1.) Change kernel-naming scheme to match those of the other distribution: requires change in archlinux, no change in grub2 needed

2.) Change grub2 to match archlinux. A possible patch would be in the attachment.


Why not using solution 2. until solution 1. has been discussed and maybe rolled out? Is there any disadvantage?

Patch for 2. attached.
   archlinux_correct_kernel_vers... (0.5 KiB)
Comment by Keshav Amburay (the.ridikulus.rat) - Tuesday, 14 February 2012, 17:55 GMT
2. is not a solution since a bootloader is supposed to work for all distros (and even other OSes). Even 1 is not a viable option now. I suggest using conditional statements (maybe reading /etc/os-release to detect Arch) such that for Arch alone pacman output is used.
Comment by MG (elmurato) - Sunday, 26 February 2012, 10:29 GMT
I don't get it why it's so hard to integrate solution number 1. But with the workaround I'm happy now, except one thing: How do I trigger update-grub automatically after a kernel-update? Dou you guys can help me with this problem? I think that problem is also related to this. Thanks in advance.
Comment by MG (elmurato) - Sunday, 18 March 2012, 11:33 GMT
OK finally I found a hacky solution for my problem. Maybe someone will need it, too. First, copy the attached file to /lib/initcpio/install/grub. Then add "grub" to your hooks in /etc/mkinitcpio.conf.
If you look at the script you'll see a workaround so that it won't update GRUB twice ("normal" and "fallback" kernel).
   grub (0.3 KiB)
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 19 March 2012, 08:51 GMT
Can you guys try PKGBUILDs at https://www.dropbox.com/s/jth3mchm3hobmfy . I have updated the patch for 2.00beta2 as well as tried to fix this issue.
Comment by Matthias Dienstbier (fs4000) - Monday, 19 March 2012, 12:48 GMT
Cool, thanks.

But could we get rid of this in the patch?
- LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
+ LINUX_ROOT_DEVICE="/dev/disk/by-uuid/${GRUB_DEVICE_UUID}"

It's not needed anymore since mkinitcpio 0.6.14. Moreover as there is devtmpfs I don't even use udev in initramfs so there are no /dev/disk/by-* symlinks for me. Mkinitcpio since 0.8.4 will use udev's symlinks if udev is running or fall back to blkid if the UUID= syntax is used.
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 19 March 2012, 14:01 GMT
@fs4000: Can you try updated https://www.dropbox.com/sh/jth3mchm3hobmfy/hzorMBcxqw/grub2-1%3A2.00beta2-2.src.tar.gz ?
Comment by Matthias Dienstbier (fs4000) - Monday, 19 March 2012, 18:04 GMT
Looks good in general, but there are some minor problems:
- save_default_entry is applied to fallback entry (I consider this wrong)
- Loading Linux core ...Loading Linux repo ...Loading Linux kernel ... is displayed when loading the kernel
This should be fixable by quoting ${version} in line 138.
- we could also drop "quiet" from CMDLINE, this is the default now with Arch's kernel

Arch's package has added "add_efi_memmap" to CMDLINE. What's that about?
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 19 March 2012, 19:07 GMT
@fs4000: Try the updated src.tar.gz . I think this fixes your issue. I corrected the first two, but left out "quiet" and removed add_efi_memmap .
Comment by Matthias Dienstbier (fs4000) - Monday, 19 March 2012, 20:39 GMT
Yeah, now it works pretty perfect.
Comment by Keshav Amburay (the.ridikulus.rat) - Wednesday, 21 March 2012, 15:00 GMT
Guys can you try grub2-common-1:2.00beta2-2 package and see if that is ok for you?

Loading...