On Tue, 28 Oct 2008, Robert Millan wrote:
Sorry but I don't understand how you concile the two sentences that you
gave:
- on one side you say that -t drive only fails when device.map is wrong
and you accept that we invite the user to regenerate it
s/regenerate/check/g. When
On Wed, Oct 29, 2008 at 09:22:18AM +0100, Raphael Hertzog wrote:
Ok, if you really don't want to replace the device.map on the fly,
let me propose yet another solution: in case of grub-probe failure, we
regenerate a device.map in a temporary file and we try grub-probe again
but with
Am Mittwoch, den 29.10.2008, 14:30 +0100 schrieb Robert Millan:
I don't like that it is an ugly hack, in the sense that we're trying to stop
reliing on this sort of heuristic, and this only works around the problem.
Our long-term fix is to use only reliable identifiers like UUIDs.
But since
On Wed, 29 Oct 2008, Felix Zielcke wrote:
Am Mittwoch, den 29.10.2008, 14:30 +0100 schrieb Robert Millan:
I don't like that it is an ugly hack, in the sense that we're trying to stop
reliing on this sort of heuristic, and this only works around the problem.
Our long-term fix is to use
On Wed, Oct 29, 2008 at 04:56:54PM +0100, Raphael Hertzog wrote:
Robert, I saw that you comitted the fix in SVN with a version 0.97-52 but
unstable/lenny has 0.97-47, and the changes in between are probably
unwanted by release managers. Will you prepare a 0.97-47lenny1 version
for unstable ?
On Mon, 27 Oct 2008, Robert Millan wrote:
On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
Attached is now an ugly patch which would display the grub-probe error
Check your device.map if it fails.
Else I had the idea to make an environment variable like
Tirsdag den 28. Oktober 2008 skrev Raphael Hertzog:
- the installation will still fail and most users have no idea what
device.map really is. If you go that route, you should at least give
them the command-line to execute to regenerate the device.map
But in the mean time for Grub 1,
On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
a misleading error message in those cases
grub-probe's messages aren't always appropiate for grub legacy's update-grub
On Tue, 28 Oct 2008, Robert Millan wrote:
On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
a misleading error message in those cases
grub-probe's messages aren't
On Tue, Oct 28, 2008 at 09:13:30PM +0100, Raphael Hertzog wrote:
On Tue, 28 Oct 2008, Robert Millan wrote:
On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
a
On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
Attached is now an ugly patch which would display the grub-probe error
Check your device.map if it fails.
Else I had the idea to make an environment variable like
GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
Attached is now an ugly patch which would display the grub-probe error
Check your device.map if it fails.
Else I had the idea to make an environment variable like
GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
grub_print_error() but then we would need to change grub-common and grub
12 matches
Mail list logo
