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

Submitted by:  Tal <tal>
Submitted on:  Fri 25 Jul 2014 11:00:42 PM UTC  
 
Category: NoneSeverity: Major
Priority: 5 - NormalItem Group: Software Error
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenRelease: 
Release: Git masterReproducibility: Every Time
Planned Release: 2.03+

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:
abc-1.2.3.4.7z
abc-1.2.3.7z

abc-1.2.3.4.x86_64.rpm
abc-1.2.3.x86_64.rpm

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:

...
2.4.21-138
3.10.0-123.4.4
3.10.0-123
2.4.19-120
2.6.5-7.325
...
2.6.5-7.97
2.6.27.19-5.1
2.6.16.60-0.123.1
...

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:
/boot/vmlinuz-0-rescue-ee3529f5964c4439921a155f7fd766e7
/boot/vmlinuz-3.10.0-123.4.2.el7.x86_64
/boot/vmlinuz-3.10.0-123.el7.x86_64

Sorted List:
/boot/vmlinuz-3.10.0-123.el7.x86_64
/boot/vmlinuz-3.10.0-123.4.2.el7.x86_64
/boot/vmlinuz-0-rescue-ee3529f5964c4439921a155f7fd766e7

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>

 

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
  • -unavailable- added by phcoder (Updated the item)
  • -unavailable- added by plamentotev (Posted a comment)
  • -unavailable- added by tal (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 02 Mar 2016 12:42:27 PM UTCphcoderPlanned ReleaseNone=>2.03+
    Sun 04 Jan 2015 03:35:21 PM UTCplamentotevAttached File-=>Added version_ordering.patch, #32756
    Sun 27 Jul 2014 03:55:23 PM UTCtalAttached File-=>Added test2.sh, #31781
    Fri 25 Jul 2014 11:00:42 PM UTCtalAttached File-=>Added test.sh, #31776

    Back to the top


    Powered by Savane 3.1-cleanup1