Re: powerpc/sparc problems
On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote: > From: Pavel Roskin > Date: Thu, 15 Oct 2009 18:41:41 -0400 > > > This makes me think that checks for __bswapsi2 and __bswapdi2 will fail > > on Sparc64, even if those functions are present and even if > > --disable-werror is used. > > They worked perfectly fine for me on a real system with > a real compiler and glibc. > > If you're going to use cross compilation to test, use > a full cross toolset and glibc build not some hacked > up uclibc thing. I have tested the current GRUB on PowerPC. It's Fedora 11 with a real glibc. I added __ashldi3 to the arguments of AC_CHECK_FUNCS. The check fails. Yet __ashldi3 is present in libgcc and is exported unconditionally. The reason is that -nostdlib is added to CFLAGS immediately above AC_CHECK_FUNCS. -nostdlib disables linking against libgcc. I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for the same reason. Also, I believe the effect of -Werror on the test will be seen on sparc64. Adding -Werror should be after all tests and there should be a big warning in configure.ac telling not to add tests after that point. > I also believe that even if it still fails for you, > native building is more important to work than cross > building situations. It is a native build and the current code. The whole reason I removed the checks is because they stopped working correctly when the target libc requirement was eliminated. Restoring the checks without removing -nostdlib not going to help. I'm surprised that my code is being reverted immediately before the release and the result is not tested. It's one thing to revert the code that has just been committed, and it's entirely different when the code has been in the repository for months. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
Robert Millan wrote:
> On Fri, Oct 16, 2009 at 11:08:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> Robert Millan wrote:
>>
>>> On Fri, Oct 16, 2009 at 10:09:41PM +0200, Vladimir 'phcoder' Serbinenko
>>> wrote:
>>>
>>>
Robert Millan wrote:
> On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
>
>
>
>> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>>
>>
>>> + if (memcmp (tmp_img, "XFSB", 4) == 0)
>>> +grub_util_error ("Can't install on XFS.");
>>>
>>>
>>>
>> Can this error message give some more detail on what the problem is?
>>
>>
>>
> I suggest something like:
>
> grub_util_warn ("Refusing to overwrite XFS meta-data.");
>
> This is more informative, and with grub_util_warn() user has an
> opportunity to
> override it if she knows what she's doing.
>
>
>
>
Installing with blocklists/to partition is considered
backward-compatibility feature. We never supported a config with XFS why
we would want bw-compat for it?
>>> Because we can't reliably tell if it's a config with XFS, only the user can.
>>> This is an issue for both MBR or PBR installs.
>>>
>>> Maybe "XFSB" is only a remnant from one of this disk / partition former
>>> lifes. Maybe it's a valid XFS but user no longer cares about it. Or
>>> maybe a DOS-style label was created on top of it, without overwriting the
>>> first
>>> 440 bytes. Or maybe another filesystem had overwritten most XFS metadata
>>> but preserved the first block (this is conceivable since other filesystems
>>> tend to avoid using the first block).
>>>
>>> If user has to workaround GRUB heuristics by dd'ing zeros into a partition
>>> before running grub-install, this is a sign GRUB isn't doing the right
>>> thing.
>>>
>>>
>>>
>> Well, ok. But then I would ask to use a separate --force e.g.
>> --force-destroy-xfs since users and distributions tend to use --force
>> too much
>>
>
> Ok.
>
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index 960fc06..cc225a7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2009-10-16 Vladimir Serbinenko
+ * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS superblock.
+ (options): New option --destroy-xfs.
+ (main): Handle --destroy-xfs.
+
+2009-10-16 Vladimir Serbinenko
+
Let user specify OpenBSD root device.
* loader/i386/bsd.c (openbsd_root): New variable.
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index ccfbd1d..4ef746b 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -86,7 +86,8 @@ grub_refresh (void)
static void
setup (const char *dir,
const char *boot_file, const char *core_file,
- const char *root, const char *dest, int must_embed, int force)
+ const char *root, const char *dest, int must_embed, int force,
+ int destroy_xfs)
{
char *boot_path, *core_path, *core_path_dev;
char *boot_img, *core_img;
@@ -251,6 +252,13 @@ setup (const char *dir,
if (grub_disk_read (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, tmp_img))
grub_util_error ("%s", grub_errmsg);
+ if (memcmp (tmp_img, "XFSB", 4) == 0)
+{
+ grub_util_warn ("This install would require destroying XFS.");
+ if (! destroy_xfs)
+ grub_util_error ("If you really want to destroy it use --destroy-xfs.");
+}
+
/* Copy the possible DOS BPB. */
memcpy (boot_img + GRUB_BOOT_MACHINE_BPB_START,
tmp_img + GRUB_BOOT_MACHINE_BPB_START,
@@ -556,6 +564,7 @@ static struct option options[] =
{"device-map", required_argument, 0, 'm'},
{"root-device", required_argument, 0, 'r'},
{"force", no_argument, 0, 'f'},
+{"destroy-xfs", no_argument, 0, 'X'},
{"help", no_argument, 0, 'h'},
{"version", no_argument, 0, 'V'},
{"verbose", no_argument, 0, 'v'},
@@ -580,6 +589,7 @@ DEVICE must be a GRUB device (e.g. ``(hd0,1)'').\n\
-m, --device-map=FILE use FILE as the device map [default=%s]\n\
-r, --root-device=DEV use DEV as the root device [default=guessed]\n\
-f, --force install even if problems are detected\n\
+ --destroy-xfs install even destroying XFS superblock\n\
-h, --help display this message and exit\n\
-V, --version print version information and exit\n\
-v, --verbose print verbose messages\n\
@@ -614,6 +624,7 @@ main (int argc, char *argv[])
char *root_dev = 0;
char *dest_dev;
int must_embed = 0, force = 0;
+ int destroy_xfs = 0;
progname = "grub-setup";
@@ -666,6 +677,10 @@ main (int argc, char *argv[])
force = 1;
Re: [PATCH] Refuse to install on XFS destroying its superblock
On Fri, Oct 16, 2009 at 11:08:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> > On Fri, Oct 16, 2009 at 10:09:41PM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >
> >> Robert Millan wrote:
> >>
> >>> On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
> >>>
> >>>
> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko
> wrote:
>
>
> > + if (memcmp (tmp_img, "XFSB", 4) == 0)
> > +grub_util_error ("Can't install on XFS.");
> >
> >
> Can this error message give some more detail on what the problem is?
>
>
> >>> I suggest something like:
> >>>
> >>> grub_util_warn ("Refusing to overwrite XFS meta-data.");
> >>>
> >>> This is more informative, and with grub_util_warn() user has an
> >>> opportunity to
> >>> override it if she knows what she's doing.
> >>>
> >>>
> >>>
> >> Installing with blocklists/to partition is considered
> >> backward-compatibility feature. We never supported a config with XFS why
> >> we would want bw-compat for it?
> >>
> >
> > Because we can't reliably tell if it's a config with XFS, only the user can.
> > This is an issue for both MBR or PBR installs.
> >
> > Maybe "XFSB" is only a remnant from one of this disk / partition former
> > lifes. Maybe it's a valid XFS but user no longer cares about it. Or
> > maybe a DOS-style label was created on top of it, without overwriting the
> > first
> > 440 bytes. Or maybe another filesystem had overwritten most XFS metadata
> > but preserved the first block (this is conceivable since other filesystems
> > tend to avoid using the first block).
> >
> > If user has to workaround GRUB heuristics by dd'ing zeros into a partition
> > before running grub-install, this is a sign GRUB isn't doing the right
> > thing.
> >
> >
> Well, ok. But then I would ask to use a separate --force e.g.
> --force-destroy-xfs since users and distributions tend to use --force
> too much
Ok.
--
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."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using network informations from PXE as grub2 enviroment variables
Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Fri, 16...:
Seth Goldberg wrote:
Hi,
Quoting Pavel Pisa, who wrote the following on Fri, 16 Oct 2009:
Nobody can't use options 150 from DHCP, because GRUB2 don't have any
driver for network adapters. Network task are done only through
adapters PXE firmware. PXE passes informations only about IP
addresses, but no DHCP options.
Not true -- all DHCP options are available by inspecting the cached
DHCPACK that is available from a call to PXE firmware. This is a
stable interface and works quite well. In fact, we enhanced the
Legacy GRUB we use in Solaris to pass the entire DHCPACK via the
multiboot structure (albeit in a non-standard way -- and I'd like to
rectify that by including the DHCPACK in the multiboot structure
explicitly) so it can be used by the kernel.
Since you are familiar with networking and PXE could you make a
multiboot amendment proposal? It has to be
(a) expandable to new network interfaces (not only PXE), it includes the
necessity of passing info pertatining to multiple adapters and a way to
match this info to adapters (I think MAC is good for this)
(b) possibility to add custom information, not only what is specified by
DHCP standard. Vendor info encapsulation is perhaps a way. I'm not sure
we'll ever need this but I would like to have this possibility if we
ever need it
We'll need a flag bit indicating the presence of network boot information.
After that, define a field that's a pointer to a structure of the form:
struct netbootinfo {
int type; /* 0 = PXE; 1 = RARP/BOOTP */
void*data; /* Pointer to the boot-protocol-specific data */
/* In the PXE case, that's a DHCPACK frame; */
/* In the RARP/BOOTP case, it's a BOOTP reply */
struct netbootinfo *next; /* Link to next netbootinfo structure */
};
I know you don't like linked lists/pointers in the multiboot structure, so
we can specify an array of these structures, but that's a bit inefficient (and
embedding a union of types could waste even more space).
--S
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Fri, Oct 16, 2009 at 07:30:03PM +0200, Vladimir 'phcoder' Serbinenko wrote: > We don't need to reinvent the wheel. We can import regexp parser from > GNU sed I think there's one in GNU libc too (see regcomp()). -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFT,PATCH] Move embedding to appropriate partmap files
Robert Millan wrote: > On Fri, Oct 16, 2009 at 12:58:42PM +0200, Vladimir 'phcoder' Serbinenko wrote: > >> Robert Millan wrote: >> >>> On Thu, Aug 13, 2009 at 10:53:23PM +0200, Vladimir 'phcoder' Serbinenko >>> wrote: >>> >>> >> We may want to embed more in the future. Actually I think it's not >> ad-hoc. Basically partition map defines a function which gives back >> the sectors available for embedding. >> >> > Is embedding useful elsewhere? > > Yes. Consider a world of checksummed filesystems. In such world you can't change the contents of the file by just writing to its blocklist since it will break the checksum. Similar problems exist with RAIDs and LVMs. On some systems we can't put grub-env in a file. For these cases we can embed grub-env somewhere where we can write it with ease >>> Ok. Feel free to use partmap/ then. But please make sure #ifdefs only >>> enable those functions where they are going to be used. That'd be >>> GRUB_MACHINE_PCBIOS for now, if later code in other ports relies on them, >>> this can be changed. >>> >>> >>> >> This patch fixes an important bug - namely overwriting extended >> partition tables >> > > Is there a simpler way to resolve this? I don't object to the > restructuring you propose, but it seems too intrusive to do this > just a few hours before we release 1.97. > > Yes. It's my concern too. Solving this requires metadata info form partition map which is normally hidden and new code may have undiscovered bugs. On the other hand already present code has a bug but which is unlikely to be triggered. As a simple alternative one could keep current check + enumerte entries in MBR - this should be enough. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
Robert Millan wrote:
> On Fri, Oct 16, 2009 at 10:09:41PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> Robert Millan wrote:
>>
>>> On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
>>>
>>>
On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
> + if (memcmp (tmp_img, "XFSB", 4) == 0)
> +grub_util_error ("Can't install on XFS.");
>
>
Can this error message give some more detail on what the problem is?
>>> I suggest something like:
>>>
>>> grub_util_warn ("Refusing to overwrite XFS meta-data.");
>>>
>>> This is more informative, and with grub_util_warn() user has an opportunity
>>> to
>>> override it if she knows what she's doing.
>>>
>>>
>>>
>> Installing with blocklists/to partition is considered
>> backward-compatibility feature. We never supported a config with XFS why
>> we would want bw-compat for it?
>>
>
> Because we can't reliably tell if it's a config with XFS, only the user can.
> This is an issue for both MBR or PBR installs.
>
> Maybe "XFSB" is only a remnant from one of this disk / partition former
> lifes. Maybe it's a valid XFS but user no longer cares about it. Or
> maybe a DOS-style label was created on top of it, without overwriting the
> first
> 440 bytes. Or maybe another filesystem had overwritten most XFS metadata
> but preserved the first block (this is conceivable since other filesystems
> tend to avoid using the first block).
>
> If user has to workaround GRUB heuristics by dd'ing zeros into a partition
> before running grub-install, this is a sign GRUB isn't doing the right thing.
>
>
Well, ok. But then I would ask to use a separate --force e.g.
--force-destroy-xfs since users and distributions tend to use --force
too much
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFT,PATCH] Move embedding to appropriate partmap files
On Fri, Oct 16, 2009 at 12:58:42PM +0200, Vladimir 'phcoder' Serbinenko wrote: > Robert Millan wrote: > > On Thu, Aug 13, 2009 at 10:53:23PM +0200, Vladimir 'phcoder' Serbinenko > > wrote: > > > We may want to embed more in the future. Actually I think it's not > ad-hoc. Basically partition map defines a function which gives back > the sectors available for embedding. > > >>> Is embedding useful elsewhere? > >>> > >> Yes. Consider a world of checksummed filesystems. In such world you > >> can't change the contents of the file by just writing to its blocklist > >> since it will break the checksum. Similar problems exist with RAIDs > >> and LVMs. On some systems we can't put grub-env in a file. For these > >> cases we can embed grub-env somewhere where we can write it with ease > >> > > > > Ok. Feel free to use partmap/ then. But please make sure #ifdefs only > > enable those functions where they are going to be used. That'd be > > GRUB_MACHINE_PCBIOS for now, if later code in other ports relies on them, > > this can be changed. > > > > > This patch fixes an important bug - namely overwriting extended > partition tables Is there a simpler way to resolve this? I don't object to the restructuring you propose, but it seems too intrusive to do this just a few hours before we release 1.97. -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
Am Freitag, den 16.10.2009, 19:30 +0200 schrieb Vladimir 'phcoder' Serbinenko: > >> We need an improvement to test command then. What about having > >> test -regexp > >> > > > > I think that's a little overkill, regular expression parser can be > > quite complex. > > > > > We don't need to reinvent the wheel. We can import regexp parser from > GNU sed Would it be really that useful to have full regexp support inside GRUB? I can't currently imagine a case where I'd use that. Shouldn't be just normal shell wildcards (? and *) be enough? -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using network informations from PXE as grub2 enviroment variables
Seth Goldberg wrote:
> Hi,
>
> Quoting Pavel Pisa, who wrote the following on Fri, 16 Oct 2009:
>
Nobody can't use options 150 from DHCP, because GRUB2 don't have any
driver for network adapters. Network task are done only through
adapters PXE firmware. PXE passes informations only about IP
addresses, but no DHCP options.
>
> Not true -- all DHCP options are available by inspecting the cached
> DHCPACK that is available from a call to PXE firmware. This is a
> stable interface and works quite well. In fact, we enhanced the
> Legacy GRUB we use in Solaris to pass the entire DHCPACK via the
> multiboot structure (albeit in a non-standard way -- and I'd like to
> rectify that by including the DHCPACK in the multiboot structure
> explicitly) so it can be used by the kernel.
Since you are familiar with networking and PXE could you make a
multiboot amendment proposal? It has to be
(a) expandable to new network interfaces (not only PXE), it includes the
necessity of passing info pertatining to multiple adapters and a way to
match this info to adapters (I think MAC is good for this)
(b) possibility to add custom information, not only what is specified by
DHCP standard. Vendor info encapsulation is perhaps a way. I'm not sure
we'll ever need this but I would like to have this possibility if we
ever need it
> Note also that the EFI PXE wrapper also provides access to the
> cached DHCPACK.
>
>>>
>>> I let someone more familiar with PXE than me to answer this.
>>
>> The 150 option would be usesfull a lot, but I do not know PXE
>> good enough to support that. The PXE firmware seems to be
>> problematic (high probability of bugs and diversity) to me anyway
>> so we want to use as small subset as possible.
>
> In our experience (booting Solaris using PXE firmware), for our
> uses, the firmware has been quite stable. The trick it to ensure that
> you're using APIs that Microsoft uses -- that's the only way these
> APIs will be stable enough for general use. This is the same story as
> with the multitude of BIOS calls -- as time has progressed, the only
> stable set of calls you can 100% rely on are that set that are used by
> Windows.
>
> We've been using DHCP Option 150 extensively without a problem. In
> fact, we made modification to Legacy GRUB to go a bit beyond Option
> 150, which includes a search order for finding the appropriate GRUB
> menu. The search order is as follows (see the `solaris_config_file'
> in OpenSolaris's grub source base): (1) We look for DHCP option 150;
> (2) We look for menu.lst.01 using the MAC address of the
> PXE-booted NIC; (3) We look for menu.lst. (but if BootFile
> is "pxelinux.{X}" we just use {X} for ; (4) Finally, if
> those fail, we fall back on plain-old "menu.lst".
>
> This allows a significant amount of customization, either at the DHCP
> server level, or based on the MAC of the requesting client. Our
> install-server preparation scripts create the appropriate files
> automatically.
>
> Since our customers have come to rely on this behavior, we will
> continue to offer these options (obviously, with different menu
> filenames, though). It would be nice to include this functionality
> for all other GRUB2 users as well.
>
> Thanks,
> --S
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
On Fri, Oct 16, 2009 at 10:09:41PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> > On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
> >
> >> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko
> >> wrote:
> >>
> >>> + if (memcmp (tmp_img, "XFSB", 4) == 0)
> >>> +grub_util_error ("Can't install on XFS.");
> >>>
> >> Can this error message give some more detail on what the problem is?
> >>
> >
> > I suggest something like:
> >
> > grub_util_warn ("Refusing to overwrite XFS meta-data.");
> >
> > This is more informative, and with grub_util_warn() user has an opportunity
> > to
> > override it if she knows what she's doing.
> >
> >
> Installing with blocklists/to partition is considered
> backward-compatibility feature. We never supported a config with XFS why
> we would want bw-compat for it?
Because we can't reliably tell if it's a config with XFS, only the user can.
This is an issue for both MBR or PBR installs.
Maybe "XFSB" is only a remnant from one of this disk / partition former
lifes. Maybe it's a valid XFS but user no longer cares about it. Or
maybe a DOS-style label was created on top of it, without overwriting the first
440 bytes. Or maybe another filesystem had overwritten most XFS metadata
but preserved the first block (this is conceivable since other filesystems
tend to avoid using the first block).
If user has to workaround GRUB heuristics by dd'ing zeros into a partition
before running grub-install, this is a sign GRUB isn't doing the right thing.
--
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."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using network informations from PXE as grub2 enviroment variables
Hi,
Quoting Pavel Pisa, who wrote the following on Fri, 16 Oct 2009:
Nobody can't use options 150 from DHCP, because GRUB2 don't have any
driver for network adapters. Network task are done only through
adapters PXE firmware. PXE passes informations only about IP
addresses, but no DHCP options.
Not true -- all DHCP options are available by inspecting the cached DHCPACK
that is available from a call to PXE firmware. This is a stable interface and
works quite well. In fact, we enhanced the Legacy GRUB we use in Solaris to
pass the entire DHCPACK via the multiboot structure (albeit in a non-standard
way -- and I'd like to rectify that by including the DHCPACK in the multiboot
structure explicitly) so it can be used by the kernel. Note also that the
EFI PXE wrapper also provides access to the cached DHCPACK.
I let someone more familiar with PXE than me to answer this.
The 150 option would be usesfull a lot, but I do not know PXE
good enough to support that. The PXE firmware seems to be
problematic (high probability of bugs and diversity) to me anyway
so we want to use as small subset as possible.
In our experience (booting Solaris using PXE firmware), for our uses, the
firmware has been quite stable. The trick it to ensure that you're using APIs
that Microsoft uses -- that's the only way these APIs will be stable enough
for general use. This is the same story as with the multitude of BIOS calls
-- as time has progressed, the only stable set of calls you can 100% rely
on are that set that are used by Windows.
We've been using DHCP Option 150 extensively without a problem. In fact, we
made modification to Legacy GRUB to go a bit beyond Option 150, which includes
a search order for finding the appropriate GRUB menu. The search order is as
follows (see the `solaris_config_file' in OpenSolaris's grub source base):
(1) We look for DHCP option 150; (2) We look for menu.lst.01 using the
MAC address of the PXE-booted NIC; (3) We look for menu.lst. (but if
BootFile is "pxelinux.{X}" we just use {X} for ; (4) Finally, if
those fail, we fall back on plain-old "menu.lst".
This allows a significant amount of customization, either at the DHCP server
level, or based on the MAC of the requesting client. Our install-server
preparation scripts create the appropriate files automatically.
Since our customers have come to rely on this behavior, we will continue to
offer these options (obviously, with different menu filenames, though). It
would be nice to include this functionality for all other GRUB2 users as well.
Thanks,
--S
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Hi, Update: Optimize update algorithm for term widget, now it should only update the necessary regions. Fix prompt handling in term, you can't use backspace to erase prompt or use left to move before it, home would jump to position after the prompt. BTW, menu branch has been merged with master, new code would push to the master branch directly. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let user specify OpenBSD root device.
Robert Millan wrote:
> On Fri, Oct 16, 2009 at 01:00:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> Vladimir 'phcoder' Serbinenko wrote:
>>
>>> On Wed, Aug 26, 2009 at 2:34 AM, Robert Millan wrote:
>>>
>>>
On Tue, Aug 25, 2009 at 10:37:33PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
> + if (cmd->state[OPENBSD_ROOT_ARG].set)
> +{
> + const char *arg = cmd->state[OPENBSD_ROOT_ARG].arg;
> + int unit, part;
> + if (*(arg++) != 'w' || *(arg++) != 'd')
> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
> +"Only device specifications of form "
> +"wd are supported.");
> +
> + unit = grub_strtoul (arg, (char **) &arg, 10);
> + if (! (arg && *arg >= 'a' && *arg <= 'z'))
> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
> +"Only device specifications of form "
> +"wd are supported.");
>
>
Looks like the first error string could be used for both cases, saving
a few bytes.
>> This was fixed. Can this patch be comitted before release to avoid
>> changing command syntax after release?
>>
>
> Ok.
>
>
Comitted
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
Robert Millan wrote:
> On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
>
>> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>>> + if (memcmp (tmp_img, "XFSB", 4) == 0)
>>> +grub_util_error ("Can't install on XFS.");
>>>
>> Can this error message give some more detail on what the problem is?
>>
>
> I suggest something like:
>
> grub_util_warn ("Refusing to overwrite XFS meta-data.");
>
> This is more informative, and with grub_util_warn() user has an opportunity to
> override it if she knows what she's doing.
>
>
Installing with blocklists/to partition is considered
backward-compatibility feature. We never supported a config with XFS why
we would want bw-compat for it?
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Fri, Oct 16, 2009 at 10:45:08PM +0800, Bean wrote: > > Source is at http://github.com/bean123/grub/, master branch. Please could you attach it? -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > + if (memcmp (tmp_img, "XFSB", 4) == 0)
> > +grub_util_error ("Can't install on XFS.");
>
> Can this error message give some more detail on what the problem is?
I suggest something like:
grub_util_warn ("Refusing to overwrite XFS meta-data.");
This is more informative, and with grub_util_warn() user has an opportunity to
override it if she knows what she's doing.
--
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."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug #27695] parser.sh ignores the closing quote when preceeded by a variable
On Thu, Oct 15, 2009 at 03:28:02PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> diff --git a/script/sh/lexer.c b/script/sh/lexer.c
> index a30e3c0..0c71dae 100644
> --- a/script/sh/lexer.c
> +++ b/script/sh/lexer.c
> @@ -350,9 +350,11 @@ grub_script_yylex (union YYSTYPE *yylval, struct
> grub_parser_param *parsestate)
> if (! (check_varstate (newstate)))
> {
> if (state->state == GRUB_PARSER_STATE_VARNAME2
> - || state->state == GRUB_PARSER_STATE_QVARNAME2)
> - nextchar (state);
> - state->state = newstate;
> + || state->state == GRUB_PARSER_STATE_QVARNAME2)
> + {
> + nextchar (state);
> + state->state = newstate;
> + }
> break;
> }
>
> @@ -378,7 +380,6 @@ grub_script_yylex (union YYSTYPE *yylval, struct
> grub_parser_param *parsestate)
>
> buffer[bufpos++] = 0;
>
> - state->state = newstate;
> yylval->arg = grub_script_arg_add (parsestate, yylval->arg,
>GRUB_SCRIPT_ARG_TYPE_VAR, buffer);
> grub_dprintf ("scripting", "vartoken=`%s'\n", buffer);
Same here, I'm afraid.
--
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."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [BUGFIX] Fix rescue parser
On Thu, Oct 15, 2009 at 03:06:42PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > -- > Regards > Vladimir 'phcoder' Serbinenko > Personal git repository: http://repo.or.cz/w/grub2/phcoder.git > > diff --git a/ChangeLog b/ChangeLog > index b0864a9..55bdc92 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,5 +1,11 @@ > 2009-10-15 Vladimir Serbinenko > > + * kern/parser.c (grub_parser_split_cmdline): Fix incorrect counting > + of arguments. Return number of tokens and not arguments. All users > + updated. > + Sorry, this change is too scary for 1.97. I'd rather release with a known minor bug than with potential for major one. After 1.97 is released, feel free to commit this. -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Handling multiple cores by GRUB
On Thu, Oct 15, 2009 at 05:44:03PM +0100, James Courtier-Dutton wrote: > 2009/10/14 Robert Millan : > > But I don't think this would be desireable except in very specific > > situations, > > and I'm not sure which ones. Perhaps loading a compressed file would be an > > example (so that uncompression and disk poll can be done in parallel). > > > > Not specifically related, but why is grub reading a file from a USB > stick so slow when compared with say reading the HD. > I mean slow, it is about 20 times slower here. Are you using our own driver, or the BIOS' one? -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let user specify OpenBSD root device.
On Fri, Oct 16, 2009 at 01:00:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Vladimir 'phcoder' Serbinenko wrote:
> > On Wed, Aug 26, 2009 at 2:34 AM, Robert Millan wrote:
> >
> >> On Tue, Aug 25, 2009 at 10:37:33PM +0200, Vladimir 'phcoder' Serbinenko
> >> wrote:
> >>
> >>> + if (cmd->state[OPENBSD_ROOT_ARG].set)
> >>> +{
> >>> + const char *arg = cmd->state[OPENBSD_ROOT_ARG].arg;
> >>> + int unit, part;
> >>> + if (*(arg++) != 'w' || *(arg++) != 'd')
> >>> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
> >>> +"Only device specifications of form "
> >>> +"wd are supported.");
> >>> +
> >>> + unit = grub_strtoul (arg, (char **) &arg, 10);
> >>> + if (! (arg && *arg >= 'a' && *arg <= 'z'))
> >>> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
> >>> +"Only device specifications of form "
> >>> +"wd are supported.");
> >>>
> >> Looks like the first error string could be used for both cases, saving
> >> a few bytes.
> >>
> >>
> This was fixed. Can this patch be comitted before release to avoid
> changing command syntax after release?
Ok.
--
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."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
NEWS file
Hi, Release is imminent. If you can, please review NEWS file for any missing noteworthy items before 1.97 is released. 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
Bean wrote:
> On Sat, Oct 17, 2009 at 12:47 AM, Vladimir 'phcoder' Serbinenko
> wrote:
>
>> Bean wrote:
>>
>>> On Fri, Oct 16, 2009 at 11:26 PM, Vladimir 'phcoder' Serbinenko
>>> wrote:
>>>
>>>
Hello. Could you send this as a patch?
>>> Hi,
>>>
>>> This function depends on my menu branch, it can't be applied to svn
>>> head, so patch file is not very useful.
>>>
>>>
>>>
>> Could you explain me why PXE depends on menu?
>>
>
> Hi,
>
> The pxecfg command use the the same config file parser as menu.
>
Could you perhaps send only the part without pxecfg then?
>
Bean wrote:
> Hi,
>
> Extends pxe command:
>
> -i (--info) now shows mac and dhcp options
> -e (--export) export a dhcp option as grub variable, for example:
>
> pxe -e 150
>
>
>
>
Why can't this be exported unconditionally on pxe system startup?
>>> Right, perhaps we can export PXE_IP, PXE_MAC and PXE_150 by default,
>>> but this function is also useful in case we need to use other string
>>> option.
>>>
>>>
>>>
>> Is it possible just enumerate all available options and export them to
>> PXE. similarly to how we treat FreeBSD environment
>>
>
> Most DHCP option are binary format, only string option can be exported
> as variable.
>
>
We can export these ones as hex
> Set variable PXE_150 to the value of dhcp option 150, you can then use
> command like source to load it:
>
> source ${PXE_150}
>
> New command pxecfg, which allows you to run a command based on current
> ip/mac:
>
> pxecfg /pxe.txt
>
>
>
>
What's wrong with standard if? I would prefer to extend "if" if
necessary rather than having ad-hoc command for every condition (later
is inexpandable)
>>> IIRC the test command can't compare partial string.
>>>
>>>
>>>
>> We need an improvement to test command then. What about having
>> test -regexp
>>
>
> I think that's a little overkill, regular expression parser can be
> quite complex.
>
>
We don't need to reinvent the wheel. We can import regexp parser from
GNU sed
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Sat, Oct 17, 2009 at 12:47 AM, Vladimir 'phcoder' Serbinenko
wrote:
> Bean wrote:
>> On Fri, Oct 16, 2009 at 11:26 PM, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>>> Hello. Could you send this as a patch?
>>>
>>
>> Hi,
>>
>> This function depends on my menu branch, it can't be applied to svn
>> head, so patch file is not very useful.
>>
>>
> Could you explain me why PXE depends on menu?
Hi,
The pxecfg command use the the same config file parser as menu.
>>> Bean wrote:
>>>
Hi,
Extends pxe command:
-i (--info) now shows mac and dhcp options
-e (--export) export a dhcp option as grub variable, for example:
pxe -e 150
>>> Why can't this be exported unconditionally on pxe system startup?
>>>
>>
>> Right, perhaps we can export PXE_IP, PXE_MAC and PXE_150 by default,
>> but this function is also useful in case we need to use other string
>> option.
>>
>>
> Is it possible just enumerate all available options and export them to
> PXE. similarly to how we treat FreeBSD environment
Most DHCP option are binary format, only string option can be exported
as variable.
Set variable PXE_150 to the value of dhcp option 150, you can then use
command like source to load it:
source ${PXE_150}
New command pxecfg, which allows you to run a command based on current
ip/mac:
pxecfg /pxe.txt
>>> What's wrong with standard if? I would prefer to extend "if" if
>>> necessary rather than having ad-hoc command for every condition (later
>>> is inexpandable)
>>>
>>
>> IIRC the test command can't compare partial string.
>>
>>
> We need an improvement to test command then. What about having
> test -regexp
I think that's a little overkill, regular expression parser can be
quite complex.
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
Bean wrote:
> On Fri, Oct 16, 2009 at 11:26 PM, Vladimir 'phcoder' Serbinenko
> wrote:
>
>> Hello. Could you send this as a patch?
>>
>
> Hi,
>
> This function depends on my menu branch, it can't be applied to svn
> head, so patch file is not very useful.
>
>
Could you explain me why PXE depends on menu?
>> Bean wrote:
>>
>>> Hi,
>>>
>>> Extends pxe command:
>>>
>>> -i (--info) now shows mac and dhcp options
>>> -e (--export) export a dhcp option as grub variable, for example:
>>>
>>> pxe -e 150
>>>
>>>
>>>
>> Why can't this be exported unconditionally on pxe system startup?
>>
>
> Right, perhaps we can export PXE_IP, PXE_MAC and PXE_150 by default,
> but this function is also useful in case we need to use other string
> option.
>
>
Is it possible just enumerate all available options and export them to
PXE. similarly to how we treat FreeBSD environment
>>> Set variable PXE_150 to the value of dhcp option 150, you can then use
>>> command like source to load it:
>>>
>>> source ${PXE_150}
>>>
>>> New command pxecfg, which allows you to run a command based on current
>>> ip/mac:
>>>
>>> pxecfg /pxe.txt
>>>
>>>
>>>
>> What's wrong with standard if? I would prefer to extend "if" if
>> necessary rather than having ad-hoc command for every condition (later
>> is inexpandable)
>>
>
> IIRC the test command can't compare partial string.
>
>
We need an improvement to test command then. What about having
test -regexp
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Handling multiple cores by GRUB
On Thu, Oct 15, 2009 at 11:44 AM, James Courtier-Dutton wrote: > 2009/10/14 Robert Millan : >> But I don't think this would be desireable except in very specific >> situations, >> and I'm not sure which ones. Perhaps loading a compressed file would be an >> example (so that uncompression and disk poll can be done in parallel). >> > > Not specifically related, but why is grub reading a file from a USB > stick so slow when compared with say reading the HD. > I mean slow, it is about 20 times slower here. What model USB stick? Consumer-grade NAND flash controllers really are 10-15x slower than a recent SATA hard disk. (7MB/s vs 110MB/s on read). Only the expensive SSD, which access many NAND flash chips in parallel, can meet or exceed hard disk speeds. And USB 2.0 High Speed maxes out at about 1/3 of hard disk speed, Firewire 800 or USB 3.0 Ultra or eSATA would overcome that. But most likely you are just using slow flash memory with a cheap controller. > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Fri, Oct 16, 2009 at 11:26 PM, Vladimir 'phcoder' Serbinenko
wrote:
> Hello. Could you send this as a patch?
Hi,
This function depends on my menu branch, it can't be applied to svn
head, so patch file is not very useful.
> Bean wrote:
>> Hi,
>>
>> Extends pxe command:
>>
>> -i (--info) now shows mac and dhcp options
>> -e (--export) export a dhcp option as grub variable, for example:
>>
>> pxe -e 150
>>
>>
> Why can't this be exported unconditionally on pxe system startup?
Right, perhaps we can export PXE_IP, PXE_MAC and PXE_150 by default,
but this function is also useful in case we need to use other string
option.
>> Set variable PXE_150 to the value of dhcp option 150, you can then use
>> command like source to load it:
>>
>> source ${PXE_150}
>>
>> New command pxecfg, which allows you to run a command based on current
>> ip/mac:
>>
>> pxecfg /pxe.txt
>>
>>
> What's wrong with standard if? I would prefer to extend "if" if
> necessary rather than having ad-hoc command for every condition (later
> is inexpandable)
IIRC the test command can't compare partial string.
>> Here is an example config file:
>>
>> pxe {
>> ip {
>> 192 {
>> 168.2 {
>> command = "echo ip 192.168.2.*"
>> }
>>
>> 169 {
>> command = "echo ip 192.169.*.*"
>> }
>>
>> command = "echo ip 192.*.*.*"
>> }
>> }
>>
>> mac {
>> 00-0c-29-1a {
>> command = "echo mac 00-0c-29-1a-*-*"
>> }
>>
>> command = "echo mac *-*-*-*-*-*"
>> }
>> }
>>
>> The config file should be self-explaining, you can use \n to specify
>> multiple line of commands:
>>
>> command = "linux /vmlinuz\ninitrd /initrd\nboot"
>>
>> Source is at http://github.com/bean123/grub/, master branch.
>>
>>
>
>
> --
> Regards
> Vladimir 'phcoder' Serbinenko
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> + if (memcmp (tmp_img, "XFSB", 4) == 0)
> +grub_util_error ("Can't install on XFS.");
Can this error message give some more detail on what the problem is?
Jordi
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
Hello. Could you send this as a patch?
Bean wrote:
> Hi,
>
> Extends pxe command:
>
> -i (--info) now shows mac and dhcp options
> -e (--export) export a dhcp option as grub variable, for example:
>
> pxe -e 150
>
>
Why can't this be exported unconditionally on pxe system startup?
> Set variable PXE_150 to the value of dhcp option 150, you can then use
> command like source to load it:
>
> source ${PXE_150}
>
> New command pxecfg, which allows you to run a command based on current ip/mac:
>
> pxecfg /pxe.txt
>
>
What's wrong with standard if? I would prefer to extend "if" if
necessary rather than having ad-hoc command for every condition (later
is inexpandable)
> Here is an example config file:
>
> pxe {
> ip {
> 192 {
> 168.2 {
> command = "echo ip 192.168.2.*"
> }
>
> 169 {
> command = "echo ip 192.169.*.*"
> }
>
> command = "echo ip 192.*.*.*"
> }
> }
>
> mac {
> 00-0c-29-1a {
> command = "echo mac 00-0c-29-1a-*-*"
> }
>
> command = "echo mac *-*-*-*-*-*"
> }
> }
>
> The config file should be self-explaining, you can use \n to specify
> multiple line of commands:
>
> command = "linux /vmlinuz\ninitrd /initrd\nboot"
>
> Source is at http://github.com/bean123/grub/, master branch.
>
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[GITGRUB] Support PXE option and new command pxecfg
Hi,
Extends pxe command:
-i (--info) now shows mac and dhcp options
-e (--export) export a dhcp option as grub variable, for example:
pxe -e 150
Set variable PXE_150 to the value of dhcp option 150, you can then use
command like source to load it:
source ${PXE_150}
New command pxecfg, which allows you to run a command based on current ip/mac:
pxecfg /pxe.txt
Here is an example config file:
pxe {
ip {
192 {
168.2 {
command = "echo ip 192.168.2.*"
}
169 {
command = "echo ip 192.169.*.*"
}
command = "echo ip 192.*.*.*"
}
}
mac {
00-0c-29-1a {
command = "echo mac 00-0c-29-1a-*-*"
}
command = "echo mac *-*-*-*-*-*"
}
}
The config file should be self-explaining, you can use \n to specify
multiple line of commands:
command = "linux /vmlinuz\ninitrd /initrd\nboot"
Source is at http://github.com/bean123/grub/, master branch.
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Quoting David Miller : From: Pavel Roskin Date: Thu, 15 Oct 2009 18:41:41 -0400 This makes me think that checks for __bswapsi2 and __bswapdi2 will fail on Sparc64, even if those functions are present and even if --disable-werror is used. They worked perfectly fine for me on a real system with a real compiler and glibc. I don't think we can rely on testing done months ago. Now that we use -Werror by default, the checks would fail even natively. It they don't, I'd like to see the relevant excerpt from your config.log. I'm going to test the native PowerPC build later today. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
Sorry, patch had a problem
Vladimir 'phcoder' Serbinenko wrote:
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index b0864a9..a67fdfd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2009-10-16 Vladimir Serbinenko
+
+ * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS superblock.
+
2009-10-15 Vladimir Serbinenko
* loader/i386/pc/xnu.c (grub_xnu_set_video): Fix loading splash image.
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index ccfbd1d..b3f2736 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -251,6 +251,9 @@ setup (const char *dir,
if (grub_disk_read (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, tmp_img))
grub_util_error ("%s", grub_errmsg);
+ if (memcmp (tmp_img, "XFSB", 4) == 0)
+grub_util_error ("Can't install on XFS.");
+
/* Copy the possible DOS BPB. */
memcpy (boot_img + GRUB_BOOT_MACHINE_BPB_START,
tmp_img + GRUB_BOOT_MACHINE_BPB_START,
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Pavel Roskin Date: Thu, 15 Oct 2009 18:41:41 -0400 > This makes me think that checks for __bswapsi2 and __bswapdi2 will fail > on Sparc64, even if those functions are present and even if > --disable-werror is used. They worked perfectly fine for me on a real system with a real compiler and glibc. If you're going to use cross compilation to test, use a full cross toolset and glibc build not some hacked up uclibc thing. I also believe that even if it still fails for you, native building is more important to work than cross building situations. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using network informations from PXE as grub2 enviroment variables
Aleš Kapica wrote:
> Dear friends,
>
> You have missunderstood my previous post from Thu, 15 Oct 2009
> 08:52:01 +0200 when I post patch, which fixies problem with
> identification of the booting machine in network by IP address.
> The following discussion have nothing to do with my post. I want to
> clarify porpose of my patch.
>
> Nobody can't use options 150 from DHCP, because GRUB2 don't have any
> driver for network adapters. Network task are done only through
> adapters PXE firmware. PXE passes informations only about IP
> addresses, but no DHCP options.
>
I let someone more familiar with PXE than me to answer this.
> In current state these informations is possible only to list, that
> means that they aren't a part of the grubs environment.
> My patch solve this. Now is this possible to set PXE informations as
> grubs environment variables, and use in them in grub.cfg for
> identification of the booting machine.
>
> Is there any problem with adding of my patch?
>
I've looked into your first patch. The idea is good however patch has
some problems:
1) Don't hardcode array sizes. Use sizeof ("XXX.XXX.XXX.XXX") instead
2) Exporting variables shouldn't require user to run a command. Just
export them as soon as possible (e.g. on module load)
3) "your_ip" is problematic name. I would prefer "local_ip" and "remote_ip"
> Aleš Kapica
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Using network informations from PXE as grub2 enviroment variables
Dear friends, You have missunderstood my previous post from Thu, 15 Oct 2009 08:52:01 +0200 when I post patch, which fixies problem with identification of the booting machine in network by IP address. The following discussion have nothing to do with my post. I want to clarify porpose of my patch. Nobody can't use options 150 from DHCP, because GRUB2 don't have any driver for network adapters. Network task are done only through adapters PXE firmware. PXE passes informations only about IP addresses, but no DHCP options. In current state these informations is possible only to list, that means that they aren't a part of the grubs environment. My patch solve this. Now is this possible to set PXE informations as grubs environment variables, and use in them in grub.cfg for identification of the booting machine. Is there any problem with adding of my patch? Aleš Kapica -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ set_pxeinfo_into_enviroment_variables.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let user specify OpenBSD root device.
Vladimir 'phcoder' Serbinenko wrote:
> On Wed, Aug 26, 2009 at 2:34 AM, Robert Millan wrote:
>
>> On Tue, Aug 25, 2009 at 10:37:33PM +0200, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>>> + if (cmd->state[OPENBSD_ROOT_ARG].set)
>>> +{
>>> + const char *arg = cmd->state[OPENBSD_ROOT_ARG].arg;
>>> + int unit, part;
>>> + if (*(arg++) != 'w' || *(arg++) != 'd')
>>> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
>>> +"Only device specifications of form "
>>> +"wd are supported.");
>>> +
>>> + unit = grub_strtoul (arg, (char **) &arg, 10);
>>> + if (! (arg && *arg >= 'a' && *arg <= 'z'))
>>> + return grub_error (GRUB_ERR_BAD_ARGUMENT,
>>> +"Only device specifications of form "
>>> +"wd are supported.");
>>>
>> Looks like the first error string could be used for both cases, saving
>> a few bytes.
>>
>>
This was fixed. Can this patch be comitted before release to avoid
changing command syntax after release?
>> --
>> 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."
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>
>
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFT,PATCH] Move embedding to appropriate partmap files
Robert Millan wrote: > On Thu, Aug 13, 2009 at 10:53:23PM +0200, Vladimir 'phcoder' Serbinenko wrote: > We may want to embed more in the future. Actually I think it's not ad-hoc. Basically partition map defines a function which gives back the sectors available for embedding. >>> Is embedding useful elsewhere? >>> >> Yes. Consider a world of checksummed filesystems. In such world you >> can't change the contents of the file by just writing to its blocklist >> since it will break the checksum. Similar problems exist with RAIDs >> and LVMs. On some systems we can't put grub-env in a file. For these >> cases we can embed grub-env somewhere where we can write it with ease >> > > Ok. Feel free to use partmap/ then. But please make sure #ifdefs only > enable those functions where they are going to be used. That'd be > GRUB_MACHINE_PCBIOS for now, if later code in other ports relies on them, > this can be changed. > > This patch fixes an important bug - namely overwriting extended partition tables -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Refuse to install on XFS destroying its superblock
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index b0864a9..a67fdfd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2009-10-16 Vladimir Serbinenko
+
+ * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS superblock.
+
2009-10-15 Vladimir Serbinenko
* loader/i386/pc/xnu.c (grub_xnu_set_video): Fix loading splash image.
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index ccfbd1d..5181e58 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -205,6 +205,9 @@ setup (const char *dir,
boot_img = grub_util_read_image (boot_path);
free (boot_path);
+ if (memcmp (boot_img, "XFSB", 4) == 0)
+grub_util_error ("Can't install on XFS.");
+
/* Set the addresses of variables in the boot image. */
boot_drive = (grub_uint8_t *) (boot_img + GRUB_BOOT_MACHINE_BOOT_DRIVE);
kernel_sector = (grub_disk_addr_t *) (boot_img
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
