bugGNU GRUB - Bugs: bug #42844, version_find_latest function in...


You are not allowed to post comments on this tracker with your current authentication level.

bug #42844: version_find_latest function in grub-mkconfig_lib produces wrong results

Submitter:  Tal <tal>
Submitted:  Fri 25 Jul 2014 11:00:42 PM UTC
Category:  None Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  Git master
Release:  Reproducibility:  Every Time
Planned Release:  2.03+

Wed 31 Jan 2018 01:31:38 AM UTC, comment #4: 

it´s the way how sort as part of the coreutils is working.


maybe they should implement a different version string sorting

Sir Grublon <grublon>
Sun 04 Jan 2015 03:30:44 PM UTC, comment #3: 

version_find_latest function uses version_test_gt to sort the list. version_test_gt uses version_test_numeric to compare two versions. version_test_numeric depends on sort -V (if present but it is indeed present on CentOS) to determine the order of two versions.

The problem is how sort -V works. This is excerpt From the info page(sorry but I didn't found an online version to give a link):

Version-sorted strings are compared such that if VER1 and VER2 are version numbers and PREFIX and SUFFIX (SUFFIX matching the regular expression '(\.[A-Za-z~][A-Za-z0-9~]*)*') are strings then VER1 < VER2 implies that the name composed of "PREFIX VER1 SUFFIX" sorts before "PREFIX VER2 SUFFIX".

Some suffixes will not be matched by the regular expression     mentioned above. Consequently these examples may not sort as you expect:


The CentOS kernel images fall under the later exception - they end with .x86_64 - the '_' character is not recognized as suffix so vmlinuz-3.10.0-123.4.2.el7.x86_64 is before vmlinuz-3.10.0-123.el7.x86_64 ('4' is before 'e') and thus is sorted as older version.

I've attached a patch that fixes this issue. It just strips the subversion groups after the first subversion group that does not begin with digit before passing the version string to version_test_numeric.
ex: 3.10.0-123.4.2.el7.x86_64 becomes 3.10.0-123.4.2 and 3.10.0-123.el7.x86_64 becomes 3.10.0-123 so now they can be properly sorted with sort -V

Some notes on the patch:

  • It does not solve http://savannah.gnu.org/bugs/?42921 but this bug is not exactly the same anyway.
  • Maybe it's safer to compare the suffixes of the two version and to strip them only if they are the same. As you can see from the point above some suffixes have special meaning for the version ordering. But even they are not stripped the current code does not work so it's better this suffixes to be handler separately (like the .old).
-Deleted Account- <plamentotev>
Sun 27 Jul 2014 04:00:55 PM UTC, comment #2: 

test2.sh has version_find_latest go through a list of kernel versions (just a random list I found online) to sort them. Not only does it appear to do this backwards (it finds the oldest ones first), it also doesn't do it in the right order. I'm seeing output like:


Tal <tal>
Sat 26 Jul 2014 01:32:43 AM UTC, comment #1: 

Small update:

I reinstalled my OS (unrelated reason), and it appears that as long as you don't manually run grub2-mkconfig, the grub menu is in proper order, which might explain how the bug went under the radar. If you run grub2-mkconfig, the order is changed and the default menu item is no longer the latest kernel version. Unless there's some reason for version_find_latest to not return the actual latest kernel (seems unlikely, especially considering its name), this definitely looks like a bug - or more accurately, version_find_latest's failure to handle CentOS 7's naming convention for its kernel versions.

Tal <tal>
Fri 25 Jul 2014 11:00:42 PM UTC, original submission:  

Hey Guys.

This is my first time filing a bug, and I'm not 100% sure it is one, so forgive the ignorance if I'm missing something.

I just installed CentOS 7, ran all the updates, and ran "grub2-mkconfig" to generate a new grub menu, but the list of kernels does not appear to be in proper order.

This appears to be caused by grub-mkconfig_lib's version_find_latest function not returning the proper newest kernel.

Attached is my short test script, using the grub-mkconfig_lib library from the latest commit (0901e7855f922e770cbfeb58262cb8fded518190).

This is the output I get from my script:

Original List:

Sorted List:

Unless I am mistaken, kernel vmlinuz-3.10.0-123.el7.x86_64 is older than vmlinuz-3.10.0-123.4.2.el7.x86_64, and should appear lower in the list.
Am I missing something or is this a bug?

Tal <tal>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #32756:  version_ordering.patch added by plamentotev (583B - application/octet-stream)
file #31781:  test2.sh added by tal (3KiB - application/x-shellscript)
file #31776:  test.sh added by tal (583B - application/x-shellscript)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by grublon (Posted a comment)
  • -email is unavailable- added by phcoder (Updated the item)
  • -email is unavailable- added by plamentotev (Posted a comment)
  • -email is unavailable- added by tal (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-02 phcoder Planned ReleaseNone 2.03+
    2015-01-04 plamentotev Attached File- Added version_ordering.patch, #32756
    2014-07-27 tal Attached File- Added test2.sh, #31781
    2014-07-25 tal Attached File- Added test.sh, #31776

    Back to the top

    Powered by Savane 3.13-9c15.
    Corresponding source code