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
>
> ---
> ChangeLog|
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
---
ChangeLog|5 +
util/grub-install.in |2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a
t would come out
> >> very much different if I'd written it from scratch.
>
> No need of copyright assignment for this patch.
>
> > 2010-07-12 Vadim Solomin
> > 2010-07-12 Colin Watson
> >
> > Generate device.map in something closer to the
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 upgrad
s 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
>
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 mkdevicemap
On Sat, Jun 26, 2010 at 11:38:38AM +0100, Colin Watson wrote:
> 2010-06-21 Colin Watson
>
> Change grub-mkdevicemap to emit /dev/disk/by-id/ names where
> possible on Linux.
>
> * util/deviceiter.c (check_device): Rename to ...
> (check_device_readable_unique): ... this
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 @@ get_x
>
> === 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
> #include
> #include
> +#include
>
> #include
> #include
> @@ -345,18 +346,37 @@ get_xvd_disk_name (char *name,
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 dev
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
___
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
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,
Felix Zielcke wrote:
Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs:
OK, I didn't realize set root was capable of using UUIDs. I did know
that the two root entries were different. I got that mixed up with
the
search command combined with the root=UUID=... which I think needs
Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs:
> 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
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 unintelligi
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 G
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
st means we'd have "set root=(/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
>
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 witho
On Sat, Dec 26, 2009 at 01:37:14PM -0800, David Miller wrote:
> From: Robert Millan
> 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
From: Robert Millan
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 devices that could
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
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 compat
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
&g
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 suppor
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 sti
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 nee
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
it seems so. Sorry about that :-(
Don't 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 oper
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
&g
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&
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
lea
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 Ro
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
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?
&
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
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 s
- Original Message
> From: Manoel Rebelo Abranches <[EMAIL PROTECTED]>
> To: The development of GRUB 2
> 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
> f
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@g
On Wed, 2008-07-23 at 00:08 +0200, Robert Millan wrote:
> I don't think it's that unusual. Let's take an example. We have 1 PATA
> disk and 1 SATA disk, and are installing GNU/Linux in it. We only have
> one /boot partition (or directory in /). Turns out we have no idea which
> of the two disk
On Tue, Jul 22, 2008 at 05:57:56PM -0400, Pavel Roskin wrote:
> On Tue, 2008-07-22 at 23:36 +0200, Robert Millan wrote:
> > 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]
On Tue, 2008-07-22 at 23:36 +0200, Robert Millan wrote:
> 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
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
erent 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 to detect this at
> install time and fail, than make the user rely on
o me.
>
> As I understand it, there are two cases where we have to hardcode the
> drive 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,
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 a
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]"
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
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
I know my rights; I want my phone call!
What
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 func
On Thu, 8 May 2008 01:39:47 +0800
Bean <[EMAIL PROTECTED]> wrote:
> 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 a
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. Ho
on 1 has the
> > given label.
>
> Sorry, I was confusing labels with UUIDs. The problem with labels 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
&g
not garanteed to be unique, right? So maybe we need support 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
inux swap labels. 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 d
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 d
57 matches
Mail list logo
