Bug#494158: Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Just CC now both bug reports, although the difference between grub2's and grub-legacy's update-grub should be handled differently. Am Donnerstag, den 07.08.2008, 13:10 -0300 schrieb Henrique de Moraes Holschuh: I was about unsure if I should use 'lt' 'le' 'le-nl' or 'lt-nl' You want to return 1 for A B and 0 otherwise. That's how the code uses CompareVersions(). There is no reason to use -nl versions, the calling code avoids that issue entirely. On grub2 it works a bit different then grub-legacy. CompareVersions() gets called with only 1 value instead of 2 if you have only one kernel, I haven't tried this yet with grub-legacy. And I concentrate more on grub2 because that's the one we replace grub-legacy hopefully soon. Am Donnerstag, den 07.08.2008, 20:51 +0200 schrieb Robert Millan: I think I got it right now, but since we failed an attempt already, and the code around this is so tricky, I'd appreciate if you could test this first: On grub2 it doestn't work with just one as I currently have. update-grub shows: Updating /boot/grub/grub.cfg ... Found Debian background: debian-blueish-wallpaper-640x480.png Found linux image: basename: missing operand Try `basename --help' for more information. done To be a bit more safe with this scripting stuff I currently have /bin/sh as bash and not like normally as dash. After the 2 sed calls I added an echo /tmp/x which gives me this: 1:/boot/2.6.26-1-amd64 2: a:/boot/2.6.26-1-amd64 b: It isn't that easy to get it working for grub2 If CompareVersions() just contains an echo 0 I get just the same as above. The code in 24-5 (lenny) and 30-1 (experimental) which is the one from grub-legacy just works fine for me with only 1 kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Dienstag, den 05.08.2008, 21:40 +0200 schrieb Felix Zielcke:
The grub2 packages have only one update-grub the one in /usr/sbin
Ok and a update-grub2 which exec's update-grub but it's in /usr/sbin
too.
Probable wasn't that clear so another try:
By switching to grub2 as default, there will be no more a update-grub
thingy in /sbin
I doubt we change something with that /sbin thingy on grub-legacy.
But luckly this is not the point of this bug report :)
If I have some time, I will prepare the patch. But please don't wait on me
for it, if someone else has the time to prepare the patch, please do so.
That's very kind of you, I looked shortly at the comparison code and
couldn't figure out how to change it so it uses the dpkg code for it :)
Luckly grub2's update-grub uses now the comparison code of grub-legacy
so it's not that hard to apply it then to both.
Seems like I think even for bash scripts too complicated
Just replace the CompareVersion function with this:
CompareVersions()
{
dpkg --compare-versions $1 le $2
echo $?
}
update-grub shows me this with my debian sid 2.6.26 kernel and files
with names you reported this bug with:
Found kernel: /boot/vmlinuz-2.6.26-1-amd64
Found kernel: /boot/vmlinuz-2.6.25.14.1-t43
Found kernel: /boot/vmlinuz-2.6.25.14-t43
Found kernel: /boot/vmlinuz-2.6.25.13-t43
Found kernel: /boot/vmlinuz-2.6.25.12-t43
I was about unsure if I should use 'lt' 'le' 'le-nl' or 'lt-nl'
I try to find this now out, but please reply what you think is the best
we should use.
As you can see above it's very easy to test this :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Thu, 07 Aug 2008, Felix Zielcke wrote:
Just replace the CompareVersion function with this:
CompareVersions()
{
dpkg --compare-versions $1 le $2
echo $?
}
That's the minimal fix, yes.
But if you do it that way, you will lose the special casing of pre, ac,
rc and etc.
I was about unsure if I should use 'lt' 'le' 'le-nl' or 'lt-nl'
You want to return 1 for A B and 0 otherwise. That's how the code uses
CompareVersions(). There is no reason to use -nl versions, the calling code
avoids that issue entirely.
I try to find this now out, but please reply what you think is the best
we should use.
As you can see above it's very easy to test this :)
I'd be happy enough with it, but it *IS* an incomplete fix, as you are
trashdumping the special-casing of some version suffixes. At least -rc
needs to be special cased to get a ~ prefixed (sed -e 's/-rc/-~rc/'), to
sort before the final release.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Thu, Aug 07, 2008 at 01:10:24PM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 07 Aug 2008, Felix Zielcke wrote:
Just replace the CompareVersion function with this:
CompareVersions()
{
dpkg --compare-versions $1 le $2
echo $?
}
That's the minimal fix, yes.
But if you do it that way, you will lose the special casing of pre, ac,
rc and etc.
Hi Henrique,
I think I got it right now, but since we failed an attempt already, and the
code around this is so tricky, I'd appreciate if you could test this first:
CompareVersions()
{
local a=`echo $1 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
local b=`echo $2 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
if [ $a = $b ] ; then
echo 0
elif dpkg --compare-versions $a lt $b ; then
echo 1
else
echo -1
fi
}
(former code didn't adjust well to the api of this function, so it needed a
bit of adjustment)
thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Thu, 07 Aug 2008, Robert Millan wrote:
On Thu, Aug 07, 2008 at 01:10:24PM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 07 Aug 2008, Felix Zielcke wrote:
Just replace the CompareVersion function with this:
CompareVersions()
{
dpkg --compare-versions $1 le $2
echo $?
}
That's the minimal fix, yes.
But if you do it that way, you will lose the special casing of pre, ac,
rc and etc.
Hi Henrique,
I think I got it right now, but since we failed an attempt already, and the
code around this is so tricky, I'd appreciate if you could test this first:
CompareVersions()
{
local a=`echo $1 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
local b=`echo $2 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
if [ $a = $b ] ; then
echo 0
elif dpkg --compare-versions $a lt $b ; then
echo 1
else
echo -1
fi
}
(former code didn't adjust well to the api of this function, so it needed a
bit of adjustment)
I may not be able to test it until after I arrive in Argentina for debconf8,
i.e. on Sunday.
You don't need to care for the API if the users all do just a -gt 0
comparison anyway :)
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Mon, 04 Aug 2008, Robert Millan wrote: Why would you want something in /sbin to call something in /usr/s?bin ? You need to port the algorithm. update-grub is in /usr. Crap. I just noticed it is just a wrapper. Why the heck is it not a symlink, which we would notice at first glance? That excessive hand-holding script you guys have is actually WORSE a solution, chances are someone isn't going to notice it until it is too late, NEWS.Debian or not. It is too easy to forget about it after a while, when there is still an executable with the right name in /sbin. If I have some time, I will prepare the patch. But please don't wait on me for it, if someone else has the time to prepare the patch, please do so. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Dienstag, den 05.08.2008, 00:48 -0300 schrieb Henrique de Moraes Holschuh: On Mon, 04 Aug 2008, Robert Millan wrote: Why would you want something in /sbin to call something in /usr/s?bin ? You need to port the algorithm. update-grub is in /usr. Crap. I just noticed it is just a wrapper. Why the heck is it not a symlink, which we would notice at first glance? That excessive hand-holding script you guys have is actually WORSE a solution, chances are someone isn't going to notice it until it is too late, NEWS.Debian or not. It is too easy to forget about it after a while, when there is still an executable with the right name in /sbin. The grub2 packages have only one update-grub the one in /usr/sbin Ok and a update-grub2 which exec's update-grub but it's in /usr/sbin too. If I have some time, I will prepare the patch. But please don't wait on me for it, if someone else has the time to prepare the patch, please do so. That's very kind of you, I looked shortly at the comparison code and couldn't figure out how to change it so it uses the dpkg code for it :) Luckly grub2's update-grub uses now the comparison code of grub-legacy so it's not that hard to apply it then to both. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sun, Aug 03, 2008 at 11:33:33PM -0300, Henrique de Moraes Holschuh wrote: On Sun, 03 Aug 2008, Robert Millan wrote: On Sun, Aug 03, 2008 at 10:12:48AM -0300, Henrique de Moraes Holschuh wrote: There is absolutely NO reason for a human to accept that 1.2.3.1-foo is a LOWER version number than 1.2.3-foo, simply because it is not. Okay, I must have gotten the situation wrong then. Why don't you guys get the algorithm from apt/dpkg instead of reinventing the wheel? Granted, you may want to simplify it since you won't need epochs or ~, but you don't have to find clever ways to implement version sorting from the ground up. Sounds fine. Could you send us a patch to call dpkg --compare-versions from the script? Why would you want something in /sbin to call something in /usr/s?bin ? You need to port the algorithm. update-grub is in /usr. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sun, Aug 3, 2008 at 12:43 AM, Robert Millan [EMAIL PROTECTED] wrote:
Please could you try previous versions of update-grub (using either our SVN
or packages from http://snapshot.debian.net/) and determine when was this
problem introduced?
The change seems to be introduced in v0.97-29 since up to v0.97-28 has
the same ordering.
I've written change not bug since I'm not sure it is a problem.
That is because `update-grub' is supposed to create a list with a
descending ordering. This means that there is a char comparison and
the one with a higher value should go first, for example -openvz-amd64
would go before -amd64 ('a' char vs 'o' char). The same way
-2.6.26-1-amd64 has precedence over -2.6.25-2-amd64 (25 vs 26).
Thanks
piti:~# apt install grub/stable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version 0.97-27etch1 (Debian:4.0r4a/stable) for grub
The following packages were automatically installed and are no longer required:
grub-common
Use 'apt-get autoremove' to remove them.
Suggested packages:
grub-doc mdadm
The following packages will be DOWNGRADED:
grub
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 884kB of archives.
After this operation, 102kB disk space will be freed.
Do you want to continue [Y/n]?
Get:1 http://ftp.ro.debian.org etch/main grub 0.97-27etch1 [884kB]
Fetched 884kB in 0s (2906kB/s)
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
dpkg - warning: downgrading grub from 0.97-44 to 0.97-27etch1.
(Reading database ... 145250 files and directories currently installed.)
Preparing to replace grub 0.97-44 (using .../grub_0.97-27etch1_amd64.deb) ...
Unpacking replacement grub ...
Processing triggers for man-db ...
Setting up grub (0.97-27etch1) ...
piti:~#
piti:~#
piti:~# dpkg -l grub
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=-=-==
ii grub 0.97-27etch1 GRand Unified
Bootloader
piti:~# which update-grub
/usr/sbin/update-grub
piti:~# dpkg -S $(which update-grub)
grub: /usr/sbin/update-grub
piti:~#
piti:~#
piti:~# update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found Xen hypervisor 3.2-1-amd64, kernel: /boot/vmlinuz-2.6.18-6-xen-amd64
Found kernel: /boot/vmlinuz-2.6.26-1-amd64
Found kernel: /boot/vmlinuz-2.6.26-1-openvz-amd64
Found kernel: /boot/vmlinuz-2.6.25-2-amd64
Found kernel: /boot/vmlinuz-2.6.24-etchnhalf.1-amd64
Found kernel: /boot/memtest86.bin
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done
piti:~# for t in $(seq 28 38); do apt install grub=0.97-$t; update-grub; printf
\n\n; done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
grub-doc mdadm
The following packages will be upgraded:
grub
1 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Need to get 0B/825kB of archives.
After this operation, 111kB disk space will be freed.
WARNING: The following packages cannot be authenticated!
grub
Install these packages without verification [y/N]? y
(Reading database ... 144904 files and directories currently installed.)
Preparing to replace grub 0.97-27etch1 (using .../grub_0.97-28_amd64.deb) ...
Unpacking replacement grub ...
Processing triggers for man-db ...
Setting up grub (0.97-28) ...
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found Xen hypervisor 3.2-1-amd64, kernel: /boot/vmlinuz-2.6.18-6-xen-amd64
Found kernel: /boot/vmlinuz-2.6.26-1-amd64
Found kernel: /boot/vmlinuz-2.6.26-1-openvz-amd64
Found kernel: /boot/vmlinuz-2.6.25-2-amd64
Found kernel: /boot/vmlinuz-2.6.24-etchnhalf.1-amd64
Found kernel: /boot/memtest86.bin
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
grub-doc mdadm
The following packages will be upgraded:
grub
1 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Need to get 0B/819kB of archives.
After this operation, 16.4kB disk space will be
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
severity 493389 wishlist
tag 493389 wontfix
thanks
On Sun, Aug 03, 2008 at 01:37:07PM +0300, Teodor wrote:
On Sun, Aug 3, 2008 at 12:43 AM, Robert Millan [EMAIL PROTECTED] wrote:
Please could you try previous versions of update-grub (using either our SVN
or packages from http://snapshot.debian.net/) and determine when was this
problem introduced?
The change seems to be introduced in v0.97-29 since up to v0.97-28 has
the same ordering.
I've written change not bug since I'm not sure it is a problem.
That is because `update-grub' is supposed to create a list with a
descending ordering. This means that there is a char comparison and
the one with a higher value should go first, for example -openvz-amd64
would go before -amd64 ('a' char vs 'o' char). The same way
-2.6.26-1-amd64 has precedence over -2.6.25-2-amd64 (25 vs 26).
Thanks Teodor. This seems to come from #422759, which didn't make it to etch.
That explains why people are surprised about the change.
I'm tagging this bug wontfix unless someone can convince me otherwise.
For now I'd like to keep it open untill after the lenny release, since (I
expect) a number of users might run into this during the lenny upgrade.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
severity 493389 normal
thanks
I've written change not bug since I'm not sure it is a problem.
It is a problem, because it fails to implement the path of least surprise
for the users of the package. Even for the highly technical ones like me
(kernel developer and Debian developer).
Kernels are numbered the same way Debian packages are (if you ignore ~ and
epochs).
There is absolutely NO reason for a human to accept that 1.2.3.1-foo is a
LOWER version number than 1.2.3-foo, simply because it is not. When you add
one extra hierarchical component, it is a HIGHER version number, always.
So, update-grub is failing to do what is expected of it.
That is because `update-grub' is supposed to create a list with a
descending ordering. This means that there is a char comparison and
the one with a higher value should go first, for example -openvz-amd64
This just means the sorting algorithm is not good enough yet.
Why don't you guys get the algorithm from apt/dpkg instead of reinventing
the wheel? Granted, you may want to simplify it since you won't need epochs
or ~, but you don't have to find clever ways to implement version sorting
from the ground up.
It is not like version sorting is easy to get right, anyway. Better stick
to something that is already feature-complete and tested to do what is right
in every corner case that matters (dpkg's sorting algorithm).
would go before -amd64 ('a' char vs 'o' char). The same way
-2.6.26-1-amd64 has precedence over -2.6.25-2-amd64 (25 vs 26).
Sorry, I can't agree that something that sorts 1.2.3.4-foo as lower than
1.2.3-foo is working correctly for kernel numbering. It fails the usage for
upstream stable kernels, this is not a theoretical issue for anyone that
is not using Debian-packaged kernels (that just omit the stable version
level).
Thanks Teodor. This seems to come from #422759, which didn't make it to etch.
Looking at #422759, the test cases exemplified are very incomplete.
For now I'd like to keep it open untill after the lenny release, since (I
expect) a number of users might run into this during the lenny upgrade.
FIW, I ran into it on unstable, and I called it a bug because update-grub
failed to act in the way it is expected to.
If it will cause surprises for Etch users, than it is even *WORSE* of a
problem IMO.
In light of that, I don't even agree this bug could have a priority other
than important or grave, but since I don't like bug severity fights, I will
settle for normal.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
severity 493389 important thanks On Sun, Aug 03, 2008 at 10:12:48AM -0300, Henrique de Moraes Holschuh wrote: There is absolutely NO reason for a human to accept that 1.2.3.1-foo is a LOWER version number than 1.2.3-foo, simply because it is not. Okay, I must have gotten the situation wrong then. Why don't you guys get the algorithm from apt/dpkg instead of reinventing the wheel? Granted, you may want to simplify it since you won't need epochs or ~, but you don't have to find clever ways to implement version sorting from the ground up. Sounds fine. Could you send us a patch to call dpkg --compare-versions from the script? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sun, 03 Aug 2008, Robert Millan wrote: On Sun, Aug 03, 2008 at 10:12:48AM -0300, Henrique de Moraes Holschuh wrote: There is absolutely NO reason for a human to accept that 1.2.3.1-foo is a LOWER version number than 1.2.3-foo, simply because it is not. Okay, I must have gotten the situation wrong then. Why don't you guys get the algorithm from apt/dpkg instead of reinventing the wheel? Granted, you may want to simplify it since you won't need epochs or ~, but you don't have to find clever ways to implement version sorting from the ground up. Sounds fine. Could you send us a patch to call dpkg --compare-versions from the script? Why would you want something in /sbin to call something in /usr/s?bin ? You need to port the algorithm. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Package: grub Version: 0.97-44 Severity: important update-grub is giving me this ordering, here: Found kernel: /vmlinuz-2.6.25.14-t43 Found kernel: /vmlinuz-2.6.25.14.1-t43 Found kernel: /vmlinuz-2.6.25.13-t43 Found kernel: /vmlinuz-2.6.25.12-t43 which is broken. The second entry should have been sorted at a higher priority than the first entry. This causes the wrong kernel (i.e. not the newest one) to be the default image. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.16.55-debian13+bluesmoke+lm85 (SMP w/2 CPU cores) Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sat, Aug 02, 2008 at 01:27:49PM -0300, Henrique de Moraes Holschuh wrote: Package: grub Version: 0.97-44 Severity: important update-grub is giving me this ordering, here: Found kernel: /vmlinuz-2.6.25.14-t43 Found kernel: /vmlinuz-2.6.25.14.1-t43 Found kernel: /vmlinuz-2.6.25.13-t43 Found kernel: /vmlinuz-2.6.25.12-t43 which is broken. The second entry should have been sorted at a higher priority than the first entry. This causes the wrong kernel (i.e. not the newest one) to be the default image. I don't think the ordering code has changed in a very long time. Did you observe this behaviour in earlier versions, or is it something new? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sat, Aug 2, 2008 at 11:34 PM, Robert Millan [EMAIL PROTECTED] wrote: I don't think the ordering code has changed in a very long time. Did you observe this behaviour in earlier versions, or is it something new? I think this behaviour has appeared some time after the etch release. I'm experiencing the same issue with different kernel flavours (at the same kernel version). Thanks piti:~# update-grub Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found Xen hypervisor 3.2-1-amd64, kernel: /boot/vmlinuz-2.6.18-6-xen-amd64 Found kernel: /boot/vmlinuz-2.6.26-1-openvz-amd64 Found kernel: /boot/vmlinuz-2.6.26-1-amd64 Found kernel: /boot/vmlinuz-2.6.25-2-amd64 Found kernel: /boot/vmlinuz-2.6.24-etchnhalf.1-amd64 Found kernel: /boot/vmlinuz-2.6.18-6-xen-amd64 Found kernel: /boot/memtest86.bin Found kernel: /boot/memtest86+.bin Updating /boot/grub/menu.lst ... done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
On Sun, Aug 03, 2008 at 12:26:46AM +0300, Teodor wrote: On Sat, Aug 2, 2008 at 11:34 PM, Robert Millan [EMAIL PROTECTED] wrote: I don't think the ordering code has changed in a very long time. Did you observe this behaviour in earlier versions, or is it something new? I think this behaviour has appeared some time after the etch release. I'm experiencing the same issue with different kernel flavours (at the same kernel version). Please could you try previous versions of update-grub (using either our SVN or packages from http://snapshot.debian.net/) and determine when was this problem introduced? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
