Bug 827531

Well ... I do not think it is grub problem. We have 3.10.0-rc and 3.10.0-1. Now there is no reason to prefer one sort order to another in general and grub has no way to know it is release candidate.

I would say having something like 3.10.0-0.rcXX for a RC versions would solve this problem.

Also did it ever happen during updates between released versions (not between internal Factory releases)?

The sort algorithm is done via "sort --version-sort" and command "ls" possesses the same version sort problem.

$ ls -vr /boot/vmlinuz-* | grep ""

Yup there's no good way for sorting the versions in general.

In my bash script SGTB (http://forums.opensuse.org/blogs/jdmcdaniel3/sgtb-suse-git-kernel-tarball-creator-version-1-31-53/) to deal with kernel 3.10 properly, I must make it 3.10.0 and I wonder if you expanded the kernel version number, only when the third digit is missing, to a zero, if the sort would work properly.  Its just one more function before you do a sort, in memory perhaps.  I would say that I do not expect RC numbers ahead of a final release and I don't expect Kernel.org to rename the kernel versions for grub 2, but who knows I guess.

As always, I appreciate your consideration and thank you for your time looking at this issue.

James

Since we are using rpm to install the kernels, grub should use the same algorithm as rpm does:

$ zypper vcmp 3.10.0-rc7-1.11-desktop 3.10.0-1.11-desktop
3.10.0-rc7-1.11-desktop is older than 3.10.0-1.11-desktop
$ printf '%s\n' 3.10.0-rc7-1.11-desktop 3.10.0-1.11-desktop | /usr/lib/rpm/rpmsort 
3.10.0-rc7-1.11-desktop
3.10.0-1.11-desktop

This bug is kinda problem for our plans in making factory rolling release distro.

People would stick with older kernel with each final release and that is something we really don't want to happen :)

Created attachment 586060 [details]
use rpmsort for sorting

This patch should solve the issue. It works just fine for me here when testing.

Basically we just check for rpmsort output and compare to it as mmarek pointed out.

Hi Tomas,

Will you commit it to openSUSE factory ?

Thanks.

Done, submitted to Base:System and mhrusecky will fwd it soonish to Factory. sr#230152.

This is an autogenerated message for OBS integration:
This bug (827531) was mentioned in
https://build.opensuse.org/request/show/230153 Factory / grub2

In the current Factory, this fails with self-built kernels.

e.g. I went to test 3.16-final and since there aren't RPMs for it yet, I built it myself.

That leaves:

$ ls /lib/modules/| /usr/lib/rpm/rpmsort -r
3.16.0-rc7-2-xen
3.16.0-rc7-2-desktop
3.16.0-rc7-2-default
3.16.0-default

If I modify 3.16.0-default to 3.16.0-0-default, I get:
3.16.0-0-default
3.16.0-rc7-2-xen
3.16.0-rc7-2-desktop
3.16.0-rc7-2-default

But what number gets substituted there? Once we release an official kernel, the self-built kernel still gets sorted after all of them.

Since we don't actually support self-built kernels, maybe the answer is to add the ability (disabled by default) to sort by timestamp. Fortunately, that's easy:

version_find_latest_by_timestamp ()
{
  lc -c "$@"|head -n1
}

Generating the package version like this should solve it for all times (like for wine-snapshot):

### modify the -rc version to .9xx
### it is required for proper updates
RC="$(grep -e "^EXTRAVERSION" Makefile | sed -r -e "s:[^0-9]*::g")"
MAJOR="$(grep -e "^VERSION" Makefile | sed -e "s:[^0-9]*::g")"
MINOR="$(grep -e "^PATCHLEVEL" Makefile | sed -e "s:[^0-9]::g")"
SUBLEVEL="$(grep -e "^SUBLEVEL" Makefile | sed -e "s:[^0-9]::g")"
if [ "$(grep -e "EXTRAVERSION = -rc" Makefile)" ]; then
  MINOR="$(( $MINOR - 1 ))"
  SUBLEVEL="$(( $RC + 900 ))"
fi
echo "$MAJOR.$MINOR.$SUBLEVEL"

If you want to sort package versions, you should be compatible with the version ordering defined by the package manager. And it seems this is what grub2 in Factory actually does. So we are not changing the kernel package numbering.

But I like Jeff's approach more. "Boot the most recently installed kernel" is what everyone actually wants. For most people, this is equivalent to "boot the kernel with the highest version number", but it also serves the use cases with deliberately installing an old kernel or using a slightly different numbering scheme (like a final release without the .0).

Whatever will be selected for automatic configuration will not suite someone. We really need to implement manual editing and sorting (not for 13.2 ...)

May be based on idea in 90_persistent. Define XX_yast which simply echoes back whatever it contains. Let yast-bootloader edit this file. As long as the file is not ever supposed to be edited by hand, we can be sufficiently sure that yast-bootloader will also be able to parse these entry when needed. Also we can skip all feature tests because we know what is supported by grub version, which will further simplify entries.

This would make 10_linux redundant. And you could sort it to your heart's content. And it still will be editable by hand if user insists on it (just carefully).

(In reply to Andrei Borzenkov from comment #13)
> Whatever will be selected for automatic configuration will not suite
> someone

Actually I'm aware of an algorithm that I think should work but its written in Python. It works by giving weights to each type or revision just as the kernel uses each kernel level as a weight too. This extends the weighing of revisions to the rc and stable releases as well. Its the only way to do this right if one does not want to rely on existing tools. This can be implemented in bash but perhaps its best to just add sorting capabilities to upstream sort to treat versions as as Linux style and flag, then bash can just use that flag.

The implementation is here:

https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/lib/bpreqs.py

Look at compute_rel_weight() as an example.

For $subject, it had been fixed by Thomas's patch from comment #8. If there any other change requests like sorting by timestamp or even manual menuentry order support from YaST, please file a separate ticket(FATE) for it. Thanks.

*** Bug 990701 has been marked as a duplicate of this bug. ***