Comitted, thanks.
On 22.01.2013 18:01, Andrey Borzenkov wrote:
grub-install is not supposed to create device.map; change comment
to avoid confusion. It was already considered a bug by users.
Signed-off-by: Andrey Borzenkov arvidj...@gmail.com
---
ChangeLog|5 +
util
grub-install is not supposed to create device.map; change comment
to avoid confusion. It was already considered a bug by users.
Signed-off-by: Andrey Borzenkov arvidj...@gmail.com
---
ChangeLog|5 +
util/grub-install.in |2 +-
2 files changed, 6 insertions(+), 1 deletion
wrote:
This fix, at least in its current form, has a potential to break grub for
users having more than one drive, unless they are careful enough to check
and
fix their device.map after upgrade.
Old mkdevicemaps assigned grub device numbers in the sort order of kernel
device names
if I'd written it from scratch.
No need of copyright assignment for this patch.
2010-07-12 Vadim Solomin vadic...@gmail.com
2010-07-12 Colin Watson cjwat...@ubuntu.com
Generate device.map in something closer to the old ordering.
* util/deviceiter.c (struct device): New
On Fri, Jul 09, 2010 at 08:01:12AM +0400, Vadim Solomin wrote:
This fix, at least in its current form, has a potential to break grub for
users having more than one drive, unless they are careful enough to check and
fix their device.map after upgrade.
Old mkdevicemaps assigned grub device
, has a potential to break grub for
users having more than one drive, unless they are careful enough to check
and
fix their device.map after upgrade.
Old mkdevicemaps assigned grub device numbers in the sort order of kernel
device names, which was right more often than
On Sat, Jun 26, 2010 at 11:38:38AM +0100, Colin Watson wrote:
2010-06-21 Colin Watson cjwat...@ubuntu.com
Change grub-mkdevicemap to emit /dev/disk/by-id/ names where
possible on Linux.
* util/deviceiter.c (check_device): Rename to ...
On Fri, Jun 25, 2010 at 08:46:48PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
Colin Watson wrote:
=== modified file 'util/deviceiter.c'
--- util/deviceiter.c 2010-06-11 20:31:16 +
+++ util/deviceiter.c 2010-06-21 08:54:07 +
@@ -345,18 +346,37 @@
=== modified file 'util/deviceiter.c'
--- util/deviceiter.c 2010-06-11 20:31:16 +
+++ util/deviceiter.c 2010-06-21 08:54:07 +
@@ -28,6 +28,7 @@
#include errno.h
#include fcntl.h
#include limits.h
+#include dirent.h
#include grub/util/misc.h
#include
. Of course, GRUB has already committed to the idea that it
should be as independent of this as reasonably possible; that's why we
use UUIDs everywhere.
There is still one significant place in GRUB where we use traditional
device names, though: device.map. UUIDs don't apply to disk devices,
only
util/deviceiter.c is missing from your patch.
@@ -136,6 +138,22 @@ probe (const char *path, char *device_na
goto end;
}
+ if (stat (dev_map, dev_map_stat) == -1
+ grub_util_get_dev_abstraction (device_name) !=
GRUB_DEV_ABSTRACTION_NONE)
Looks like it may call stat
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
util/deviceiter.c is missing from your patch.
Sorry, I had an impression you were adding this file. Ignore this
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
We're trying to get rid of our reliance on device.map, for all the
well-known reasons: it causes problems when OS device names change, etc.
For the most part, GRUB 1.98 works fine without it, because if you run
grub-probe or grub-setup in a way that requires them to look at e.g.
/dev/sda
=(/dev/foo) statements in grub.cfg,
but those are just meant as a backward compatibility hack for pre-UUID GRUB
installs.
Which I guess addresses your next question:
If you remove device.map generation from grub-install, you can remove
the backward compatibility hack while at it.
Which backward
Robert Millan wrote:
On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote:
Just leave it with (/dev/foo).
You mean literally with the parentheses? I don't understand, since /dev/
names will be unintelligible to GRUB when running outside an operating
system.
Yes. This just means we'd
On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote:
Robert Millan wrote:
On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote:
Just leave it with (/dev/foo).
You mean literally with the parentheses? I don't understand, since /dev/
names will be unintelligible to GRUB when
Colin Watson wrote:
On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote:
Robert Millan wrote:
On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote:
Just leave it with (/dev/foo).
You mean literally with the parentheses? I don't understand, since /dev/
names will be
On Sat, Dec 26, 2009 at 02:25:51PM +0100, Robert Millan wrote:
On Thu, Dec 24, 2009 at 10:18:27PM +0100, Robert Millan wrote:
Colin Watson wrote:
No, I don't think we will. grub-probe is perfectly capable of mapping
/dev/sda1 to (hd0,1) even without device.map;
I wasn't very fond
On Thu, Dec 24, 2009 at 10:18:27PM +0100, Robert Millan wrote:
No, I don't think we will. grub-probe is perfectly capable of mapping
/dev/sda1 to (hd0,1) even without device.map;
I wasn't very fond of this because it's BIOS-specific. But I guess we can
live with it.
On second thought
From: Robert Millan r...@aybabtu.com
Date: Sat, 26 Dec 2009 14:25:51 +0100
Then we rely only on UUIDs.
This is exactly what I suggested we should avoid.
On OpenFirmware we scan every device alias, %80 of them point to
non-existing devices. The aliases are just an enumeration of
the set of
On Sat, Dec 26, 2009 at 01:37:14PM -0800, David Miller wrote:
From: Robert Millan r...@aybabtu.com
Date: Sat, 26 Dec 2009 14:25:51 +0100
Then we rely only on UUIDs.
This is exactly what I suggested we should avoid.
On OpenFirmware we scan every device alias, %80 of them point to
Am Donnerstag, den 24.12.2009, 22:17 +0100 schrieb Robert Millan:
On Thu, Dec 10, 2009 at 11:12:58AM +0100, Felix Zielcke wrote:
Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
But first we'd need to figure out what we do with the set
root=xxx
backward compatibility
On Thu, Dec 10, 2009 at 11:12:58AM +0100, Felix Zielcke wrote:
Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
But first we'd need to figure out what we do with the set root=xxx
backward compatibility hack. Has it been a while long enough that
we can remove support for
On Thu, Dec 10, 2009 at 08:12:52AM +, Colin Watson wrote:
On Thu, Dec 10, 2009 at 01:55:27AM +0100, Robert Millan wrote:
On Wed, Dec 09, 2009 at 11:04:43PM +, Colin Watson wrote:
I'm trying to figure out how to make Debian's grub-installer operate
without a device.map; it has
On Thu, Dec 10, 2009 at 01:55:27AM +0100, Robert Millan wrote:
On Wed, Dec 09, 2009 at 11:04:43PM +, Colin Watson wrote:
I'm trying to figure out how to make Debian's grub-installer operate
without a device.map; it has various legacy bits and pieces that need
conversion, and I'm working
Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
But first we'd need to figure out what we do with the set root=xxx
backward compatibility hack. Has it been a while long enough that
we can remove support for GRUB installs that didn't come with UUID
support?
Well we still
On Mon, Dec 07, 2009 at 05:25:22PM +, Colin Watson wrote:
On Mon, Dec 07, 2009 at 02:28:06PM +, Colin Watson wrote:
As Robert said recently, we're trying to get rid of our reliance on
device.map. Right now, it is still necessary to at least have entries in
device.map for any disks
apologise for doing something before I got round to it! :-)
Anyhow, if you find more issues with systems that have no device.map, help
is welcome fixing those of course.
I'm trying to figure out how to make Debian's grub-installer operate
without a device.map; it has various legacy bits and pieces
On Wed, Dec 09, 2009 at 11:04:43PM +, Colin Watson wrote:
I'm trying to figure out how to make Debian's grub-installer operate
without a device.map; it has various legacy bits and pieces that need
conversion, and I'm working on these.
Along the way, though, I noticed that grub-install
As Robert said recently, we're trying to get rid of our reliance on
device.map. Right now, it is still necessary to at least have entries in
device.map for any disks you wish to use with GRUB, although they don't
have to be particularly sensible; any bidirectional mapping will do (at
least as long
On Mon, Dec 07, 2009 at 02:28:06PM +, Colin Watson wrote:
As Robert said recently, we're trying to get rid of our reliance on
device.map. Right now, it is still necessary to at least have entries in
device.map for any disks you wish to use with GRUB, although they don't
have
On Sat, 2009-01-31 at 10:12 +1030, Arthur Marsh wrote:
Hi, I had an update-grub fail only reporting exiting with value 1.
I cannot find exiting with value anywhere in the current grub2 sources
from Subversion. Moreover, update-grub has been renamed to
grub-mkconfig.
--
Regards,
Pavel Roskin
Hi, I had an update-grub fail only reporting exiting with value 1.
I eventually found the problem that /boot/grub/device.map was
inaccurate, due to having to use different device names as I sometimes
have usb drives plugged in when booting which can use the /dev/sda name
like the SCSI disk
Can someone show me where grub2 uses device.map? I'm having a hard time
finding it in source.
Thanks.
--
Best Regards,
Manoel Abranches [EMAIL PROTECTED]
IBM Linux Technology Center Brazil
___
Grub-devel mailing list
Grub-devel@gnu.org
http
- Original Message
From: Manoel Rebelo Abranches [EMAIL PROTECTED]
To: The development of GRUB 2 grub-devel@gnu.org
Sent: Tuesday, 2 December, 2008 9:39:20 PM
Subject: device.map
Can someone show me where grub2 uses device.map? I'm having a hard time
finding it in source
On Tue, 2008-12-02 at 14:09 -0200, Manoel Rebelo Abranches wrote:
Can someone show me where grub2 uses device.map? I'm having a hard time
finding it in source.
include/grub/util/misc.h:
#define DEFAULT_DEVICE_MAPDEFAULT_DIRECTORY /device.map
There are several occurrences
I had already seen that. Sorry I didn't explain myself clearly.
In utils device.map is used because are they which create device.map
(grub-mkdevicemap).
But is device.map referenced in grub boot process?
How grub uses it in boot and where is it utilized outside utils?
On Tue, 2008-12-02 at 11:35
On Tue, 2008-12-02 at 16:16 -0200, Manoel Rebelo Abranches wrote:
I had already seen that. Sorry I didn't explain myself clearly.
In utils device.map is used because are they which create device.map
(grub-mkdevicemap).
But is device.map referenced in grub boot process?
How grub uses
On Mon, Jul 21, 2008 at 05:26:17PM -0400, Pavel Roskin wrote:
This is mostly implemented already. I sent a proof of concept in a mail
titled [PATCH] disk/fs_uuid.c.
It will only search hard drives unless no match is found (in that case your
boot is broken, so you wouldn't care much
).
Otherwise it's a no-go, and device.map won't solve your problem since it's
merely guessing which drive it'll be. I think it's better to detect this at
install time and fail, than make the user rely on our guesswork.
We could do it in theory. Even with device.map. It's not much more
insane
number.
1) MBR and core.img (embedded or not) are on different drives.
If embedded, then they're not different drives (core.img is put right after
MBR).
Otherwise it's a no-go, and device.map won't solve your problem since it's
merely guessing which drive it'll be. I think it's better
On Thu, May 29, 2008 at 07:12:52PM -0400, Pavel Roskin wrote:
On Wed, 2008-05-28 at 23:36 +0200, Robert Millan wrote:
Hi,
This patch fixed the device.map handlers to accept any device name for grub
drives, rather than just BIOS-style hd[0-9] and fd[0-9]. It makes
update-grub usable
On Fri, 2008-05-30 at 12:50 +0200, Robert Millan wrote:
By the way, biosdisk.c becomes a misnomer. If I understand correctly,
biosdisk.c is not going to be emulating anything BIOS specific with your
patch.
How about renaming to util/disk.c ?
Fine with me. Or we can go halfway and call
On Wed, 2008-05-28 at 23:36 +0200, Robert Millan wrote:
Hi,
This patch fixed the device.map handlers to accept any device name for grub
drives, rather than just BIOS-style hd[0-9] and fd[0-9]. It makes
update-grub usable on OFW, Coreboot, etc.
Any comments?
That's a very welcome change
Hi,
This patch fixed the device.map handlers to accept any device name for grub
drives, rather than just BIOS-style hd[0-9] and fd[0-9]. It makes
update-grub usable on OFW, Coreboot, etc.
Any comments?
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What good is a phone
On Thu, May 08, 2008 at 01:39:47AM +0800, Bean wrote:
Yes, UUID can be useful, it's better to add it to grub2.
UUID itself is quite easy to get, but the question is how to integrate
it with the existing disk layer. I'm thinking of the following three
implementation:
1, Add a function
for UUIDs..
Anyway, the fix belongs to the installer. The first step would be not
to use device.map is it's not needed. In other words, if it's not a
cross-device install, don't read device.map and don't try to create it.
I think this isn't an easy as it looks. grub-setup works much like grub-emu
is they're
not garanteed to be unique, right? So maybe we need support for UUIDs..
Right.
Anyway, the fix belongs to the installer. The first step would be not
to use device.map is it's not needed. In other words, if it's not a
cross-device install, don't read device.map and don't try to create
On Thu, May 8, 2008 at 1:22 AM, Pavel Roskin [EMAIL PROTECTED] wrote:
On Wed, 2008-05-07 at 15:03 +0200, Robert Millan wrote:
On Tue, May 06, 2008 at 11:43:48AM -0400, Pavel Roskin wrote:
On Tue, 2008-05-06 at 17:18 +0200, Robert Millan wrote:
I completely agree. How do we go
On Mon, Apr 21, 2008 at 06:31:06AM -0400, Pavel Roskin wrote:
I would explore the possibility of retiring device.map completely or
limiting its use to some rare cases.
In the vast majority of cases, the installer should not rely on knowing
the BIOS numbers of the devices involved
. It
cannot set root to, say, partition 3 on a disk where partition 1 has the
given label.
Anyway, the fix belongs to the installer. The first step would be not
to use device.map is it's not needed. In other words, if it's not a
cross-device install, don't read device.map and don't try to create
51 matches
Mail list logo
