Re: grub-dumpbios
On Tue, May 5, 2009 at 3:45 PM, Bean wrote: > Hi, > > I've documented the usage of grub-dumpbios in wiki page: > > http://grub.enbug.org/TestingOnMacbook > > The commands can be placed there as well. I personally doesn't mind, > but perhaps it would be easier for casual user to use a command > instead of typing the dd's directly. > Hi, It would be useful to have the commands engraved in the wiki, then it won't matter what happens to grub-dumpbios, although it was handy to have it. Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 4:39 AM, Robert Millan wrote: > On Tue, May 05, 2009 at 03:57:17AM +0800, Bean wrote: >> Hi, >> >> Perhaps we could incorporate them in grub-update/grub-install, I guess >> there should be no harm adding two files in /boot/grub. > > Please don't. This is really corner case; I at least wouldn't want GRUB > to install non-free blobs in /boot/grub automagically. > > (Those blobs were already in the hardware, so GRUB is not responsible for > them, but still...) > > Is this use case documented somewhere (e.g. in the wiki)? Then users who > need it can learn about the procedure from the same place. Also ... > Hi, I've documented the usage of grub-dumpbios in wiki page: http://grub.enbug.org/TestingOnMacbook The commands can be placed there as well. I personally doesn't mind, but perhaps it would be easier for casual user to use a command instead of typing the dd's directly. > On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote: >> As a side note: On many machines dumping the VGA option rom like that >> does not produce good option rom images. Many option roms are >> self-modifying and the above method only dumps the modified variants of >> the ROMs that are normally not good for "POSTing" a graphics card >> anymore. They're still good for other purposes though I guess. > > ... as Stefan points out (thanks Stefan) this may not be so > straightforwarded. I don't think this kind of tweaking is suitable > for a setup that "Joe user" will get by default. > > Btw, if the video rom can be obtained directly from memory, why doesn't > GRUB read it in runtime instead? Actually, the modified rom is what we need, as it contains information such as DDC table which is detected on POST, the original rom is not very useful in this respect. A better approach would be to fetch the rom from pci, then emulate the POST process in grub2. But this need to port code from x86emu. > > -- > 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 > -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Provide grub_dl_ref() and grub_dl_unref() for GRUB_UTIL
Quoting David Miller : Change looks great, but probably you want to explicitly mention all of the C files where you got rid of the CPP conditional tests. OK, will do. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
It is kinda documented on ubuntu-forums I think ... and maybe on the list. (here) When ppl were either asked to test it or reported their findings. I think the main use case is booting linux directly from efi, without bios emulation mode/legacy mode. This primarily applies to macs, though it might apply to non-mac efi machines too. Concerning "Joe User": If someone really wants to install linux on their mac/efi machine they're likely o.k. to run a shell script to get a binary blob (if they want graphics accel that is) As I see it the main reason to put this in a script is really that it saves you unncessary trips to the wiki or other documentation sources, where you'd end up copy n' pasting the command anyway. So from an "end user" perspective, I'd think it'd be nice to keep it. If/why it can't be read by grub directly I don't know. Most likely I think because it needs a properly "initialized" video bios to work, which is not present when grub is active. > > Is this use case documented somewhere (e.g. in the wiki)? Then users who > need it can learn about the procedure from the same place. Also ... > > On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote: >> As a side note: On many machines dumping the VGA option rom like that >> does not produce good option rom images. Many option roms are >> self-modifying and the above method only dumps the modified variants of >> the ROMs that are normally not good for "POSTing" a graphics card >> anymore. They're still good for other purposes though I guess. > > ... as Stefan points out (thanks Stefan) this may not be so > straightforwarded. I don't think this kind of tweaking is suitable > for a setup that "Joe user" will get by default. > > Btw, if the video rom can be obtained directly from memory, why doesn't > GRUB read it in runtime instead? > > -- > 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 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Provide grub_dl_ref() and grub_dl_unref() for GRUB_UTIL
From: Pavel Roskin Date: Mon, 04 May 2009 20:13:24 -0400 > Hello! > > The GRUB code is full of constructs like > > #ifndef GRUB_UTIL > grub_dl_ref (my_mod); > #endif > > It's better to avoid having source files littered with preprocessor > conditionals. This patch implements grub_dl_ref() and grub_dl_unref() > as inline functions when GRUB_UTIL is defined. > > I'm not using the unused attribute to match the existing signature of > those functions. > > ChangeLog: > * include/grub/dl.h [GRUB_UTIL]: Provide inline implementations > of grub_dl_ref() and grub_dl_unref(). Remove preprocessor > conditionals around all callers. Change looks great, but probably you want to explicitly mention all of the C files where you got rid of the CPP conditional tests. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Provide grub_dl_ref() and grub_dl_unref() for GRUB_UTIL
Hello!
The GRUB code is full of constructs like
#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
#endif
It's better to avoid having source files littered with preprocessor
conditionals. This patch implements grub_dl_ref() and grub_dl_unref()
as inline functions when GRUB_UTIL is defined.
I'm not using the unused attribute to match the existing signature of
those functions.
ChangeLog:
* include/grub/dl.h [GRUB_UTIL]: Provide inline implementations
of grub_dl_ref() and grub_dl_unref(). Remove preprocessor
conditionals around all callers.
diff --git a/commands/parttool.c b/commands/parttool.c
index b4cbf00..58751ca 100644
--- a/commands/parttool.c
+++ b/commands/parttool.c
@@ -46,10 +46,8 @@ grub_parttool_register(const char *part_name,
struct grub_parttool *cur;
int nargs = 0;
-#ifndef GRUB_UTIL
if (! parts)
grub_dl_ref (mymod);
-#endif
cur = (struct grub_parttool *) grub_malloc (sizeof (struct grub_parttool));
cur->next = parts;
@@ -89,10 +87,8 @@ grub_parttool_unregister (int handle)
prev = cur;
cur = cur->next;
}
-#ifndef GRUB_UTIL
if (! parts)
grub_dl_unref (mymod);
-#endif
}
static grub_err_t
diff --git a/fs/affs.c b/fs/affs.c
index 4ddc347..8b7bc02 100644
--- a/fs/affs.c
+++ b/fs/affs.c
@@ -104,9 +104,7 @@ struct grub_affs_data
int htsize;
};
-#ifndef GRUB_UTIL
static grub_dl_t my_mod;
-#endif
static grub_disk_addr_t
@@ -392,9 +390,7 @@ grub_affs_open (struct grub_file *file, const char *name)
struct grub_affs_data *data;
struct grub_fshelp_node *fdiro = 0;
-#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
-#endif
data = grub_affs_mount (file->device->disk);
if (!data)
@@ -419,9 +415,7 @@ grub_affs_open (struct grub_file *file, const char *name)
grub_free (fdiro);
grub_free (data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return grub_errno;
}
@@ -432,9 +426,7 @@ grub_affs_close (grub_file_t file)
{
grub_free (file->data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return GRUB_ERR_NONE;
}
@@ -477,9 +469,7 @@ grub_affs_dir (grub_device_t device, const char *path,
return hook (filename, &info);
}
-#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
-#endif
data = grub_affs_mount (device->disk);
if (!data)
@@ -497,9 +487,7 @@ grub_affs_dir (grub_device_t device, const char *path,
grub_free (fdiro);
grub_free (data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return grub_errno;
}
@@ -512,9 +500,7 @@ grub_affs_label (grub_device_t device, char **label)
struct grub_affs_file file;
grub_disk_t disk = device->disk;
-#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
-#endif
data = grub_affs_mount (disk);
if (data)
@@ -533,9 +519,7 @@ grub_affs_label (grub_device_t device, char **label)
else
*label = 0;
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
grub_free (data);
@@ -557,9 +541,7 @@ static struct grub_fs grub_affs_fs =
GRUB_MOD_INIT(affs)
{
grub_fs_register (&grub_affs_fs);
-#ifndef GRUB_UTIL
my_mod = mod;
-#endif
}
GRUB_MOD_FINI(affs)
diff --git a/fs/afs.c b/fs/afs.c
index 90d8864..d710095 100644
--- a/fs/afs.c
+++ b/fs/afs.c
@@ -175,9 +175,7 @@ struct grub_afs_data
struct grub_fshelp_node diropen;
};
-#ifndef GRUB_UTIL
static grub_dl_t my_mod;
-#endif
static grub_afs_off_t
grub_afs_run_to_num (struct grub_afs_sblock *sb,
@@ -505,9 +503,7 @@ grub_afs_open (struct grub_file *file, const char *name)
struct grub_afs_data *data;
struct grub_fshelp_node *fdiro = 0;
-#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
-#endif
data = grub_afs_mount (file->device->disk);
if (! data)
@@ -532,9 +528,7 @@ fail:
grub_free (fdiro);
grub_free (data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return grub_errno;
}
@@ -553,9 +547,7 @@ grub_afs_close (grub_file_t file)
{
grub_free (file->data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return GRUB_ERR_NONE;
}
@@ -583,9 +575,7 @@ grub_afs_dir (grub_device_t device, const char *path,
return hook (filename, &info);
}
-#ifndef GRUB_UTIL
grub_dl_ref (my_mod);
-#endif
data = grub_afs_mount (device->disk);
if (! data)
@@ -603,9 +593,7 @@ grub_afs_dir (grub_device_t device, const char *path,
grub_free (fdiro);
grub_free (data);
-#ifndef GRUB_UTIL
grub_dl_unref (my_mod);
-#endif
return grub_errno;
}
@@ -623,9 +611,7 @@ static struct grub_fs grub_afs_fs = {
GRUB_MOD_INIT (afs)
{
grub_fs_register (&grub_afs_fs);
-#ifndef GRUB_UTIL
my_mod = mod;
-#endif
}
GRUB_MOD_FINI (afs)
diff --git a/fs/cpio.c b/fs/cpio.c
index bedd65e..7a49fc1 100644
--- a/fs/cpio.c
+++ b/fs/cpio.c
@@ -74,9 +74,7 @@ struct grub_cpio_data
grub_uint32_t size;
};
-#ifndef GRUB_UTIL
static grub_dl_t my_mod;
-#endif
static grub_err_t
grub_cpio_find_file (struct grub_cpio_data *data, char **name,
@@ -192,9 +190,7 @@ grub_cpio_dir (grub_devi
[PATCH]: IEEE1275 path name escaping...
Ok, finally GRUB works also on my workstation.
These are the changes that allow GRUB to properly handle
"," characters in OF path names.
As we discussed about a month ago, when a "," appears in an
OF path name we escape it with "\".
So all of the real work is escaping OF paths as they are given
to GRUB, and then un-escaping them when ofdisk tries to open
them.
Committed.
PS: I plan to spend the next few days testing what we have now on
a variety of sparc64 systems to make sure all of the most obvious
problems get shaken out.
2009-05-04 David S. Miller
* disk/ieee1275/ofdisk.c (compute_dev_path): New.
(grub_ofdisk_open): Use it to un-escape "," characters.
* kern/disk.c (find_part_sep): New.
(grub_disk_open): Use it to find the first non-escaped ','
character in the disk name.
* util/ieee1275/devicemap.c (escape_of_path): New.
(grub_util_emit_devicemap_entry): Use it.
* util/sparc64/ieee1275/grub-install.in: Update script to
strip partition specifiers properly by not triggering on
'\' escaped ',' characters.
Index: disk/ieee1275/ofdisk.c
===
--- disk/ieee1275/ofdisk.c (revision 2188)
+++ disk/ieee1275/ofdisk.c (working copy)
@@ -115,6 +115,38 @@
return grub_devalias_iterate (dev_iterate);
}
+static char *
+compute_dev_path (const char *name)
+{
+ char *devpath = grub_malloc (grub_strlen (name) + 2);
+ char *p, c;
+
+ if (!devpath)
+return NULL;
+
+ /* Un-escape commas. */
+ p = devpath;
+ while ((c = *name++) != '\0')
+{
+ if (c == '\\' && *name == ',')
+ {
+ *p++ = ',';
+ name++;
+ }
+ else
+ *p++ = c;
+}
+
+ if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_PARTITION_0))
+{
+ *p++ = ':';
+ *p++ = '0';
+}
+ *p++ = '\0';
+
+ return devpath;
+}
+
static grub_err_t
grub_ofdisk_open (const char *name, grub_disk_t disk)
{
@@ -126,14 +158,10 @@
char prop[64];
grub_ssize_t actual;
- devpath = grub_strndup (name, grub_strlen (name) + 2);
+ devpath = compute_dev_path (name);
if (! devpath)
return grub_errno;
- /* To access the complete disk add `:0'. */
- if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_PARTITION_0))
-grub_strcat (devpath, ":0");
-
op = ofdisk_hash_find (devpath);
if (!op)
op = ofdisk_hash_add (devpath);
Index: kern/disk.c
===
--- kern/disk.c (revision 2185)
+++ kern/disk.c (working copy)
@@ -215,10 +215,28 @@
return 0;
}
+/* Return the location of the first ',', if any, which is not
+ escaped by a '\'. */
+static const char *
+find_part_sep (const char *name)
+{
+ const char *p = name;
+ char c;
+
+ while ((c = *p++) != '\0')
+{
+ if (c == '\\' && *p == ',')
+ p++;
+ else if (c == ',')
+ return p - 1;
+}
+ return NULL;
+}
+
grub_disk_t
grub_disk_open (const char *name)
{
- char *p;
+ const char *p;
grub_disk_t disk;
grub_disk_dev_t dev;
char *raw = (char *) name;
@@ -238,7 +256,7 @@
if (! disk->name)
goto fail;
- p = grub_strchr (name, ',');
+ p = find_part_sep (name);
if (p)
{
grub_size_t len = p - name;
Index: util/sparc64/ieee1275/grub-install.in
===
--- util/sparc64/ieee1275/grub-install.in (revision 2185)
+++ util/sparc64/ieee1275/grub-install.in (working copy)
@@ -237,8 +237,8 @@
grub_drive="`$grub_probe --target=drive --device ${grub_device}`"
# Strip partition number
-install_drive="`echo ${install_drive} | sed -e s/,[0-9]*//g`"
-grub_drive="`echo ${grub_drive} | sed -e s/,[0-9]*//g`"
+install_drive="`echo ${install_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
+grub_drive="`echo ${grub_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
if [ "x${grub_drive}" != "x${install_drive}" ] ; then
uuid="`$grub_probe --target=fs_uuid --device ${grub_device}`"
if [ "x${uuid}" = "x" ] ; then
Index: util/sparc64/ieee1275/grub-setup.c
===
--- util/sparc64/ieee1275/grub-setup.c (revision 2185)
+++ util/sparc64/ieee1275/grub-setup.c (working copy)
@@ -56,7 +56,7 @@
* device. It also needs to know the initial block number of
* 'core' (which is 'diskboot' concatenated with 'kernel' and
* all the modules, this is created by grub-mkimage). This resulting
- * 'boot' image is 512 bytes in size and is placed in the first block
+ * 'boot' image is 512 bytes in size and is placed in the second block
* of a partition.
*
* The initial 'diskboot' block acts as a loader for the actual GRUB
@@ -100,6 +100,28 @@
fflush (stdout);
}
+static char *compute_dest_ofpath (const char *dest)
+{
+ int len = strlen (dest);
+ char *res, *p, c;
+
+ res = xmalloc (len);
+ p = res;
+
[PATCH]: Fix hangs and stalls on sparc64
1) If there isn't a CDROM in the drive, trying to do an ieee1275 open() on a cdroom device hangs nearly indefinitely. 2) If you try to open the bare device "ide/disk" for example (with no "@X,Y" ID selector) this hangs for 5 seconds then spits out ugly errors about not being able to read disk labels etc. So bypass these cases for now, we're only really interested in the explicitly listed aliases anyways. As for cdrom grub2 booting, I have some plans for this and I will look into them after I get some feedback about some details of OpenBoot from one of my engineering contacts at Sun. Committed. 2009-05-04 David S. Miller * disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Bypass cdrom devices, and do not traverse down under controller nodes. Index: disk/ieee1275/ofdisk.c === --- disk/ieee1275/ofdisk.c (revision 2185) +++ disk/ieee1275/ofdisk.c (working copy) @@ -106,13 +106,9 @@ } } - if (! grub_strcmp (alias->type, "block")) + if (! grub_strcmp (alias->type, "block") && + grub_strcmp (alias->name, "cdrom")) ret = hook (alias->name); - else if ((! grub_strcmp (alias->type, "scsi")) - || (! grub_strcmp (alias->type, "ide")) - || (! grub_strcmp (alias->type, "ata"))) - /* Search for block-type children of these bus controllers. */ - ret = grub_children_iterate (alias->name, dev_iterate); return ret; } ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH]: Fix sparc64 build.
Please be more careful people. 2009-05-04 David S. Miller * conf/sparc64-ieee1275.rmk: Fix build due to missing '\'. --- conf/sparc64-ieee1275.rmk (revision 2184) +++ conf/sparc64-ieee1275.rmk (revision 2187) @@ -113,12 +113,12 @@ kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c \ kern/err.c kern/file.c kern/fs.c kern/loader.c kern/main.c \ kern/misc.c kern/parser.c kern/partition.c kern/reader.c\ - kern/rescue_reader.c kern/rescue_parser.c + kern/rescue_reader.c kern/rescue_parser.c \ kern/term.c fs/fshelp.c \ kern/list.c kern/handler.c \ lib/arg.c normal/cmdline.c \ normal/completion.c \ - normal/main.c normal/menu.c \ + normal/main.c normal/menu.c \ normal/menu_text.c \ normal/menu_entry.c normal/menu_viewer.c normal/misc.c \ normal/color.c \ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH]: Fix ieee1275 iterator regression.
When I converted this code over to user dynamically allocated strings, I inserted a bug by passing the address of the string pointer instead of the pointer itself. Committed. 2009-05-04 David S. Miller * kern/ieee1275/openfw.c (grub_children_iterate): Fix string pointer args to grub_ieee1275_get_property(). diff --git a/kern/ieee1275/openfw.c b/kern/ieee1275/openfw.c index 7d65023..31296b1 100644 --- a/kern/ieee1275/openfw.c +++ b/kern/ieee1275/openfw.c @@ -78,7 +78,7 @@ grub_children_iterate (char *devpath, struct grub_ieee1275_devalias alias; grub_ssize_t actual; - if (grub_ieee1275_get_property (child, "device_type", &childtype, + if (grub_ieee1275_get_property (child, "device_type", childtype, sizeof childtype, &actual)) continue; @@ -86,7 +86,7 @@ grub_children_iterate (char *devpath, &actual)) continue; - if (grub_ieee1275_get_property (child, "name", &childname, + if (grub_ieee1275_get_property (child, "name", childname, sizeof childname, &actual)) continue; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
Robert Millan wrote: Btw, I increased the mode list considerably (using documented modes from Wikipedia). Chances that your ultra-weird mode of choice is supported are much greater now. There's still no fuzzy matching, though. I'm not sure if we'd want to do that at all for vga= modes, since we already do it properly in our video subsystem. = I'll give them a look as soon as I can get something new built. I'll have to admit, I didn't expect you guys to go to so much trouble, since the vga= will be going away anyhow. We can all live with the "fuzzy matching" for now, until you get the new video subsystem operating properly. Don't put a lot of time into something that won't be used much longer, as we can live with things as they are for the moment. Thanks for everything. Pat -- ---Zenwalk v6.0--Linux 2.6.28--- Registered Linux User #225206 "Ever tried Zen computing?" http://www.zenwalk.org ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] prevent duplicated entries due to symlinks
On Mon, 2009-05-04 at 18:45 +0200, Andreas wrote: > Pavel Roskin schrieb: > > The result will be that we would have an entry without version instead > > of an entry with a version. That's hardly an improvement. Can you give > > an example where it would be useful? > > > You have a symlink named /boot/vmlinuz which points at the current > kernel version. Now you could of course find out which kernel version > it's pointing at but that version could change anytime. I see, you want to support loading the "default" kernel, i.e. the one pointed to by the symlink. This way, re-running grub-mkconfig won't be necessary if a new kernel is installed. > /boot/vmlinu[zx] > and /vmlinu[zx] (there should only exist one of them) are the only cases > I can think of which have no version in their name. So you always know > that the version-free entry always boots the kernel pointed at by > /boot/vmlinuz, which is always the current kernel if your distro > maintains the symlink. I see no regression there. Suppose I have Linux 2.6.29 and 2.6.28. Your script makes entries for "Linux default" and "Linux 2.6.28". Then I install Linux 2.6.30 and don't run grub-mkconfig. Then I can boot Linux 2.6.30 and 2.6.28 form the menu, but not 2.6.29. Even if I run grub-mkconfig, there is still something I lose. By selecting "Linux default" I still don't know it it's Linux 2.6.30 or something else. For me, the convenience of not having to rerun grub-mkconfig doesn't outweigh the convenience of knowing what I'm loading. I know, it's have to argue about preferences, but if you want you changes to be accepted, you need to present a good case. I would consider placing the kernel pointed to by the vmlinuz link to the first position of the Linux kernels. Another approach would be to have an entry for the link without suppressing any versioned entries. > > Please specify where those names are used. Can you give the > > distribution name and version where such names are used? > > > Zenwalk, Slackware for example. I think more Slackware derivates are > using it too. Let's add support for more versioned names first. That should be rather non-controversial. > > What is initrd.splash? Why does it need to be handled like initrd and > > why is it always version independent? Again, where is it used? > > > > > initrd.splash is used by Zenwalk (others too) it contains only the data > of one or multiple bootsplashes as returned by the "splash" command. > It's used by bootsplash and doesn't contain any files, modules, etc. > The version independence is quite self-explaining now, I think. Unless > bootsplash support was removed it works for any kernel version. And even > if bootsplash support is removed it does no harm to load it. > > Is it understandable now? It's quite strange that some distro would use the initrd functionality purely for eye candy. But if that's true, I'm fine with using initrd.splash as the last resort if no other initrd image is found. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 05, 2009 at 03:57:17AM +0800, Bean wrote: > Hi, > > Perhaps we could incorporate them in grub-update/grub-install, I guess > there should be no harm adding two files in /boot/grub. Please don't. This is really corner case; I at least wouldn't want GRUB to install non-free blobs in /boot/grub automagically. (Those blobs were already in the hardware, so GRUB is not responsible for them, but still...) Is this use case documented somewhere (e.g. in the wiki)? Then users who need it can learn about the procedure from the same place. Also ... On Mon, May 04, 2009 at 10:28:52PM +0200, Stefan Reinauer wrote: > As a side note: On many machines dumping the VGA option rom like that > does not produce good option rom images. Many option roms are > self-modifying and the above method only dumps the modified variants of > the ROMs that are normally not good for "POSTing" a graphics card > anymore. They're still good for other purposes though I guess. ... as Stefan points out (thanks Stefan) this may not be so straightforwarded. I don't think this kind of tweaking is suitable for a setup that "Joe user" will get by default. Btw, if the video rom can be obtained directly from memory, why doesn't GRUB read it in runtime instead? -- 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: Copyright lines not being updated!
On Tue, May 05, 2009 at 03:44:27AM +0800, Bean wrote:
> Hi,
>
> git users can add this at the beginning of .git/hooks/pre-commit to
> run the copyright update test before committing:
>
> L1=`git diff --cached --stat 2>/dev/null | gawk '{ if (($2 == "|") &&
> ($3 > 5)) print $1}'`
> L2=`grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" $L1 2>/dev/null`
>
> if test ! -z $L2 ; then
> echo You should update copyright information for the following files:
> git diff --cached --stat $L2 2>/dev/null
> exit 1
> fi
Note that copyright lines don't _always_ have to be updated. It's
detrimental to do it when there's no need (bogus copyright assertions
weaken the legitimate ones).
--
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] Video mode fixes in linux loader
Btw, I increased the mode list considerably (using documented modes from Wikipedia). Chances that your ultra-weird mode of choice is supported are much greater now. There's still no fuzzy matching, though. I'm not sure if we'd want to do that at all for vga= modes, since we already do it properly in our video subsystem. -- 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: grub-dumpbios
On 04.05.2009 21:27 Uhr, Robert Millan wrote:
> Hi,
>
> Do we really need to ship a specific utility just to run two commands?
>
> dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
> dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
>
> Sounds like user will need to read some documentation in order to figure
> out what grub-dumpbios is good for, and what to do with those files, so
> why not just document the commands there instead? (e.g. in the wiki or
> so)
>
>
As a side note: On many machines dumping the VGA option rom like that
does not produce good option rom images. Many option roms are
self-modifying and the above method only dumps the modified variants of
the ROMs that are normally not good for "POSTing" a graphics card
anymore. They're still good for other purposes though I guess.
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
Hi,
Perhaps we could incorporate them in grub-update/grub-install, I guess
there should be no harm adding two files in /boot/grub.
On Tue, May 5, 2009 at 3:27 AM, Robert Millan wrote:
>
> Hi,
>
> Do we really need to ship a specific utility just to run two commands?
>
> dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
> dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
>
> Sounds like user will need to read some documentation in order to figure
> out what grub-dumpbios is good for, and what to do with those files, so
> why not just document the commands there instead? (e.g. in the wiki or
> so)
>
> --
> 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
>
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Copyright lines not being updated!
Hi,
git users can add this at the beginning of .git/hooks/pre-commit to
run the copyright update test before committing:
L1=`git diff --cached --stat 2>/dev/null | gawk '{ if (($2 == "|") &&
($3 > 5)) print $1}'`
L2=`grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" $L1 2>/dev/null`
if test ! -z $L2 ; then
echo You should update copyright information for the following files:
git diff --cached --stat $L2 2>/dev/null
exit 1
fi
On Tue, May 5, 2009 at 3:15 AM, Bean wrote:
> Hi,
>
> This new script list more information, it helps to decide whether it
> need update.
>
> L1=`git diff --stat @{2009-01-01}..HEAD 2>/dev/null | gawk '{ if (($2
> == "|") && ($3 > 5)) print $1}'`
> L2=`grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" $L1 2>/dev/null`
>
> git diff --stat @{2009-01-01}..HEAD $L2 2>/dev/null
>
> result:
> Makefile.in | 48 +-
> bus/usb/ohci.c | 609 ++
> bus/usb/uhci.c | 676 +++
> bus/usb/usb.c | 263 +
> bus/usb/usbhub.c | 193 +
> bus/usb/usbtrans.c | 212 +
> commands/blocklist.c | 14 +-
> commands/cat.c | 12 +-
> commands/cmp.c | 12 +-
> commands/crc.c | 14 +-
> commands/date.c | 19 +-
> commands/echo.c | 16 +-
> commands/halt.c | 13 +-
> commands/help.c | 60 +-
> commands/hexdump.c | 19 +-
> commands/i386/cpuid.c | 19 +-
> commands/i386/pc/halt.c | 17 +-
> commands/i386/pc/play.c | 12 +-
> commands/i386/pc/pxecmd.c | 17 +-
> commands/i386/pc/vbeinfo.c | 24 +-
> commands/i386/pc/vbetest.c | 15 +-
> commands/ieee1275/suspend.c | 11 +-
> commands/ls.c | 64 +-
> commands/lsmmap.c | 17 +-
> commands/read.c | 13 +-
> commands/reboot.c | 11 +-
> commands/search.c | 32 +-
> commands/sleep.c | 14 +-
> commands/test.c | 420 ++-
> commands/usbtest.c | 162 +
> configure | 9612
> --
> disk/fs_uuid.c | 26 +-
> disk/ieee1275/nand.c | 17 +-
> disk/ieee1275/ofdisk.c | 102 +-
> disk/loopback.c | 18 +-
> disk/lvm.c | 9 +-
> disk/raid.c | 15 +-
> disk/scsi.c | 46 +-
> disk/usbms.c | 393 ++
> fs/affs.c | 14 +-
> fs/afs.c | 14 +-
> fs/cpio.c | 56 +-
> fs/ext2.c | 123 +-
> fs/hfs.c | 265 +-
> fs/hfsplus.c | 63 +-
> fs/i386/pc/pxe.c | 10 +-
> fs/iso9660.c | 16 +-
> fs/jfs.c | 14 +-
> fs/minix.c | 13 +-
> fs/ntfs.c | 16 +-
> fs/reiserfs.c | 12 +-
> fs/sfs.c | 26 +-
> fs/udf.c | 16 +-
> fs/ufs.c | 161 +-
> fs/xfs.c | 14 +-
> genmk.rb | 25 +-
> hello/hello.c | 12 +-
> include/grub/datetime.h | 48 +
> include/grub/disk.h | 13 +-
> include/grub/efi/api.h | 82 +-
> include/grub/efi/pe32.h | 11 +-
> include/grub/fs.h | 14 +-
> include/grub/i386/bsd.h | 9 +-
> include/grub/i386/pc/memory.h | 40 +-
> include/grub/i386/pci.h | 35 +
> include/grub/ieee1275/ieee1275.h | 11 +-
> include/grub/lib/arg.h | 72 +
> include/grub/memory.h | 52 +
> include/grub/misc.h | 6 +-
> include/grub/sparc64/ieee1275/ieee1275.h | 22 +
> include/grub/sparc64/kernel.h | 30 +
> include/grub/sparc64/libgcc.h | 12 +
> include/grub/term.h | 78 +-
> include/grub/types.h | 22 +-
> include/grub/usb.h | 207 +
> include/grub/usbdesc.h | 119 +
> include/grub/usb
grub-dumpbios
Hi,
Do we really need to ship a specific utility just to run two commands?
dd if=/dev/mem of=${output_dir}vbios.bin bs=65536 skip=12 count=1
dd if=/dev/mem of=${output_dir}int10.bin bs=4 skip=16 count=1
Sounds like user will need to read some documentation in order to figure
out what grub-dumpbios is good for, and what to do with those files, so
why not just document the commands there instead? (e.g. in the wiki or
so)
--
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: Copyright lines not being updated!
Hi,
This new script list more information, it helps to decide whether it
need update.
L1=`git diff --stat @{2009-01-01}..HEAD 2>/dev/null | gawk '{ if (($2
== "|") && ($3 > 5)) print $1}'`
L2=`grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" $L1 2>/dev/null`
git diff --stat @{2009-01-01}..HEAD $L2 2>/dev/null
result:
Makefile.in | 48 +-
bus/usb/ohci.c | 609 ++
bus/usb/uhci.c | 676 +++
bus/usb/usb.c| 263 +
bus/usb/usbhub.c | 193 +
bus/usb/usbtrans.c | 212 +
commands/blocklist.c | 14 +-
commands/cat.c | 12 +-
commands/cmp.c | 12 +-
commands/crc.c | 14 +-
commands/date.c | 19 +-
commands/echo.c | 16 +-
commands/halt.c | 13 +-
commands/help.c | 60 +-
commands/hexdump.c | 19 +-
commands/i386/cpuid.c| 19 +-
commands/i386/pc/halt.c | 17 +-
commands/i386/pc/play.c | 12 +-
commands/i386/pc/pxecmd.c| 17 +-
commands/i386/pc/vbeinfo.c | 24 +-
commands/i386/pc/vbetest.c | 15 +-
commands/ieee1275/suspend.c | 11 +-
commands/ls.c| 64 +-
commands/lsmmap.c| 17 +-
commands/read.c | 13 +-
commands/reboot.c| 11 +-
commands/search.c| 32 +-
commands/sleep.c | 14 +-
commands/test.c | 420 ++-
commands/usbtest.c | 162 +
configure| 9612 --
disk/fs_uuid.c | 26 +-
disk/ieee1275/nand.c | 17 +-
disk/ieee1275/ofdisk.c | 102 +-
disk/loopback.c | 18 +-
disk/lvm.c |9 +-
disk/raid.c | 15 +-
disk/scsi.c | 46 +-
disk/usbms.c | 393 ++
fs/affs.c| 14 +-
fs/afs.c | 14 +-
fs/cpio.c| 56 +-
fs/ext2.c| 123 +-
fs/hfs.c | 265 +-
fs/hfsplus.c | 63 +-
fs/i386/pc/pxe.c | 10 +-
fs/iso9660.c | 16 +-
fs/jfs.c | 14 +-
fs/minix.c | 13 +-
fs/ntfs.c| 16 +-
fs/reiserfs.c| 12 +-
fs/sfs.c | 26 +-
fs/udf.c | 16 +-
fs/ufs.c | 161 +-
fs/xfs.c | 14 +-
genmk.rb | 25 +-
hello/hello.c| 12 +-
include/grub/datetime.h | 48 +
include/grub/disk.h | 13 +-
include/grub/efi/api.h | 82 +-
include/grub/efi/pe32.h | 11 +-
include/grub/fs.h| 14 +-
include/grub/i386/bsd.h |9 +-
include/grub/i386/pc/memory.h| 40 +-
include/grub/i386/pci.h | 35 +
include/grub/ieee1275/ieee1275.h | 11 +-
include/grub/lib/arg.h | 72 +
include/grub/memory.h| 52 +
include/grub/misc.h |6 +-
include/grub/sparc64/ieee1275/ieee1275.h | 22 +
include/grub/sparc64/kernel.h| 30 +
include/grub/sparc64/libgcc.h| 12 +
include/grub/term.h | 78 +-
include/grub/types.h | 22 +-
include/grub/usb.h | 207 +
include/grub/usbdesc.h | 119 +
include/grub/usbtrans.h | 107 +
kern/device.c| 58 +-
kern/disk.c | 11 +-
kern/dl.c| 30 +-
kern/efi/efi.c | 23 +
kern/i386/coreboot/init.c| 17 +-
kern/i386/efi/startup.S |6 +-
kern/i386/loader.S | 103 +-
kern/i386/pc/init.c |9 +-
kern/i386/pc/startup.S | 18 +-
kern/ieee1275/ieee1275.c | 50 +-
kern/ieee1275/openfw.c | 113 +-
kern/main.c | 16 +-
kern/mm.c
Re: Copyright lines not being updated!
Hi,
I make some improvement to the script, now it only print files that
contains more than 5 lines of changes, which should be qualified as
significant.
grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" `git diff
--stat @{2009-01-01}..HEAD 2>/dev/null | gawk '{ if (($2 == "|") &&
($3 > 5)) print $1}'` 2>/dev/null
The list:
Makefile.in
bus/usb/ohci.c
bus/usb/uhci.c
bus/usb/usb.c
bus/usb/usbhub.c
bus/usb/usbtrans.c
commands/blocklist.c
commands/cat.c
commands/cmp.c
commands/crc.c
commands/date.c
commands/echo.c
commands/halt.c
commands/help.c
commands/hexdump.c
commands/i386/cpuid.c
commands/i386/pc/halt.c
commands/i386/pc/play.c
commands/i386/pc/pxecmd.c
commands/i386/pc/vbeinfo.c
commands/i386/pc/vbetest.c
commands/ieee1275/suspend.c
commands/ls.c
commands/lsmmap.c
commands/read.c
commands/reboot.c
commands/search.c
commands/sleep.c
commands/test.c
commands/usbtest.c
configure
disk/fs_uuid.c
disk/ieee1275/nand.c
disk/ieee1275/ofdisk.c
disk/loopback.c
disk/lvm.c
disk/raid.c
disk/scsi.c
disk/usbms.c
fs/affs.c
fs/afs.c
fs/cpio.c
fs/ext2.c
fs/hfs.c
fs/hfsplus.c
fs/i386/pc/pxe.c
fs/iso9660.c
fs/jfs.c
fs/minix.c
fs/ntfs.c
fs/reiserfs.c
fs/sfs.c
fs/udf.c
fs/ufs.c
fs/xfs.c
genmk.rb
hello/hello.c
include/grub/datetime.h
include/grub/disk.h
include/grub/efi/api.h
include/grub/efi/pe32.h
include/grub/fs.h
include/grub/i386/bsd.h
include/grub/i386/pc/memory.h
include/grub/i386/pci.h
include/grub/ieee1275/ieee1275.h
include/grub/lib/arg.h
include/grub/memory.h
include/grub/misc.h
include/grub/sparc64/ieee1275/ieee1275.h
include/grub/sparc64/kernel.h
include/grub/sparc64/libgcc.h
include/grub/term.h
include/grub/types.h
include/grub/usb.h
include/grub/usbdesc.h
include/grub/usbtrans.h
kern/device.c
kern/disk.c
kern/dl.c
kern/efi/efi.c
kern/i386/coreboot/init.c
kern/i386/efi/startup.S
kern/i386/loader.S
kern/i386/pc/init.c
kern/i386/pc/startup.S
kern/ieee1275/ieee1275.c
kern/ieee1275/openfw.c
kern/main.c
kern/mm.c
kern/sparc64/dl.c
kern/x86_64/dl.c
lib/arg.c
lib/hexdump.c
loader/efi/appleloader.c
loader/efi/chainloader.c
loader/i386/bsd.c
loader/i386/ieee1275/linux.c
loader/i386/pc/chainloader.c
loader/i386/pc/linux.c
loader/multiboot_loader.c
loader/powerpc/ieee1275/linux.c
normal/cmdline.c
normal/completion.c
normal/datetime.c
normal/menu_entry.c
normal/misc.c
term/efi/console.c
term/i386/pc/serial.c
term/terminfo.c
util/console.c
util/deviceiter.c
util/elf/grub-mkimage.c
util/grub-emu.c
util/grub-fstest.c
util/grub-mkdevicemap.c
util/grub-pe2elf.c
util/grub.d/30_os-prober.in
util/hostfs.c
util/i386/pc/grub-install.in
util/i386/pc/grub-setup.c
util/usb.c
On Tue, May 5, 2009 at 2:00 AM, Robert Millan wrote:
> On Mon, May 04, 2009 at 07:52:39PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> On Mon, May 4, 2009 at 7:40 PM, Bean wrote:
>>
>> > Hi,
>> >
>> > Well, I just write a small script to detect files that needs updating.
>> > BTW, I use git to access the svn repository:
>> >
>> With the following script :
>> sed "s/ Free/,2009 Free/g;" < $1 > ./tmp
>> cp ./tmp $1
>>
>> xargs and this list I generated a patch to update all these files
>
> Unfortunately they can't be automagically updated. Technically it has to
> be done only when we check-in copyright-significant changes, and there's no
> automated way to test that.
>
> It's not such a big deal, but it's good to send a reminder from time to time,
> so people (me included! ;-)) keep it in mind.
>
> --
> 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
>
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
Am Montag, den 04.05.2009, 14:16 -0400 schrieb BandiPat: > A little help here. Where do you run this "vbeinfo" command to get a > listing of suitable modes? I am going to load the vbeinfo.mod in the > grub.cfg, but what after that to get a listing? > Just press `c' to get to commandline and type vbeinfo. Normally you shouldn't ever need to insmod command modules. GRUB should load them automatically as long as you have /boot/grub/command.lst. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
Robert Millan wrote: === Thanks Robert for the suggestion. I had renewed hopes this might work, but it would not. After editing the menuentry to use either the vga=0x31b or vga=795, the machine booted to a blinking cursor. It would not go beyond that. What suitable modes does "vbeinfo" list? === A little help here. Where do you run this "vbeinfo" command to get a listing of suitable modes? I am going to load the vbeinfo.mod in the grub.cfg, but what after that to get a listing? Thanks ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
On Sat, May 02, 2009 at 05:32:01PM +0200, Robert Millan wrote: > > See also this new patch. It restructures the checks so that > "vid_mode == 0" indicates lack of "vga=" parameter. For user requesting > text mode (vga=normal or vga=0) we already have GRUB_LINUX_VID_MODE_NORMAL > so there's no need to handle both values in GRUB. > > It also introduces the GRUB_ASSUME_LINUX_HAS_FB_SUPPORT macro, which allows > easy override of the "fallback to text mode" setting. Committed. -- 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: Copyright lines not being updated!
On Mon, May 04, 2009 at 07:52:39PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Mon, May 4, 2009 at 7:40 PM, Bean wrote: > > > Hi, > > > > Well, I just write a small script to detect files that needs updating. > > BTW, I use git to access the svn repository: > > > With the following script : > sed "s/ Free/,2009 Free/g;" < $1 > ./tmp > cp ./tmp $1 > > xargs and this list I generated a patch to update all these files Unfortunately they can't be automagically updated. Technically it has to be done only when we check-in copyright-significant changes, and there's no automated way to test that. It's not such a big deal, but it's good to send a reminder from time to time, so people (me included! ;-)) keep it in mind. -- 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: Copyright lines not being updated!
Am Dienstag, den 05.05.2009, 01:40 +0800 schrieb Bean: > Here are the result: > Makefile.in Makefile.in had curiously 2008,2009,2008. I just fixed this. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Copyright lines not being updated!
On Tue, May 05, 2009 at 01:40:02AM +0800, Bean wrote:
> Hi,
>
> Well, I just write a small script to detect files that needs updating.
> BTW, I use git to access the svn repository:
>
> grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" `git diff
> --stat @{2009-01-01}..HEAD 2>/dev/null | grep '|' | cut -d\ -f2`
> 2>/dev/null
>
> Here are the result:
> [...]
Scary... well, unless someone wants to review all of them, I suggest we
just try to keep this in mind. Hopefully by the end of the year the list
will be shorter :-)
--
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: Copyright lines not being updated!
Hi,
Well, I just write a small script to detect files that needs updating.
BTW, I use git to access the svn repository:
grep -lie "Copyright (C).*\(199[0-9]\|200[^9]\) *Free" `git diff
--stat @{2009-01-01}..HEAD 2>/dev/null | grep '|' | cut -d\ -f2`
2>/dev/null
Here are the result:
Makefile.in
boot/i386/pc/boot.S
bus/usb/ohci.c
bus/usb/uhci.c
bus/usb/usb.c
bus/usb/usbhub.c
bus/usb/usbtrans.c
commands/blocklist.c
commands/cat.c
commands/cmp.c
commands/crc.c
commands/date.c
commands/echo.c
commands/halt.c
commands/help.c
commands/hexdump.c
commands/i386/cpuid.c
commands/i386/pc/halt.c
commands/i386/pc/play.c
commands/i386/pc/pxecmd.c
commands/i386/pc/vbeinfo.c
commands/i386/pc/vbetest.c
commands/ieee1275/suspend.c
commands/ls.c
commands/lsmmap.c
commands/read.c
commands/reboot.c
commands/search.c
commands/sleep.c
commands/test.c
commands/usbtest.c
configure
disk/efi/efidisk.c
disk/fs_uuid.c
disk/i386/pc/biosdisk.c
disk/ieee1275/nand.c
disk/ieee1275/ofdisk.c
disk/loopback.c
disk/lvm.c
disk/raid.c
disk/scsi.c
disk/usbms.c
fs/affs.c
fs/afs.c
fs/cpio.c
fs/ext2.c
fs/fshelp.c
fs/hfs.c
fs/hfsplus.c
fs/i386/pc/pxe.c
fs/iso9660.c
fs/jfs.c
fs/minix.c
fs/ntfs.c
fs/reiserfs.c
fs/sfs.c
fs/udf.c
fs/ufs.c
fs/xfs.c
gencmdlist.sh
genfslist.sh
genkernsyms.sh.in
genmk.rb
gensymlist.sh.in
hello/hello.c
hook/datehook.c
include/grub/datetime.h
include/grub/disk.h
include/grub/dl.h
include/grub/efi/api.h
include/grub/efi/efi.h
include/grub/efi/pe32.h
include/grub/elf.h
include/grub/err.h
include/grub/fs.h
include/grub/fshelp.h
include/grub/gpt_partition.h
include/grub/i386/bsd.h
include/grub/i386/efi/loader.h
include/grub/i386/ieee1275/loader.h
include/grub/i386/linux.h
include/grub/i386/pc/biosdisk.h
include/grub/i386/pc/chainloader.h
include/grub/i386/pc/init.h
include/grub/i386/pc/memory.h
include/grub/i386/pci.h
include/grub/i386/pit.h
include/grub/ieee1275/ieee1275.h
include/grub/lib/arg.h
include/grub/memory.h
include/grub/misc.h
include/grub/pci.h
include/grub/powerpc/ieee1275/memory.h
include/grub/sparc64/ieee1275/ieee1275.h
include/grub/sparc64/kernel.h
include/grub/sparc64/libgcc.h
include/grub/symbol.h
include/grub/term.h
include/grub/types.h
include/grub/usb.h
include/grub/usbdesc.h
include/grub/usbtrans.h
include/grub/util/misc.h
include/grub/x86_64/efi/loader.h
kern/device.c
kern/disk.c
kern/dl.c
kern/efi/efi.c
kern/efi/mm.c
kern/fs.c
kern/i386/coreboot/init.c
kern/i386/coreboot/startup.S
kern/i386/efi/startup.S
kern/i386/ieee1275/startup.S
kern/i386/loader.S
kern/i386/pc/init.c
kern/i386/pc/startup.S
kern/ieee1275/ieee1275.c
kern/ieee1275/init.c
kern/ieee1275/mmap.c
kern/ieee1275/openfw.c
kern/main.c
kern/mm.c
kern/powerpc/ieee1275/startup.S
kern/sparc64/dl.c
kern/x86_64/dl.c
lib/arg.c
lib/efi/datetime.c
lib/hexdump.c
lib/i386/datetime.c
loader/efi/appleloader.c
loader/efi/chainloader.c
loader/i386/bsd.c
loader/i386/ieee1275/linux.c
loader/i386/pc/chainloader.c
loader/i386/pc/linux.c
loader/i386/pc/multiboot2.c
loader/multiboot2.c
loader/multiboot_loader.c
loader/powerpc/ieee1275/linux.c
normal/cmdline.c
normal/completion.c
normal/datetime.c
normal/menu_entry.c
normal/misc.c
term/efi/console.c
term/i386/pc/at_keyboard.c
term/i386/pc/console.c
term/i386/pc/serial.c
term/i386/pc/vga_text.c
term/ieee1275/ofconsole.c
term/terminfo.c
util/console.c
util/deviceiter.c
util/elf/grub-mkimage.c
util/grub-emu.c
util/grub-fstest.c
util/grub-mkconfig.in
util/grub-mkdevicemap.c
util/grub-pe2elf.c
util/grub.d/30_os-prober.in
util/hostfs.c
util/i386/pc/grub-install.in
util/i386/pc/grub-mkrescue.in
util/i386/pc/grub-setup.c
util/lvm.c
util/raid.c
util/usb.c
video/readers/jpeg.c
video/readers/png.c
video/readers/tga.c
On Tue, May 5, 2009 at 12:10 AM, Robert Millan wrote:
>
> Hi all,
>
> Please remember to update copyright lines in files when you commit
> copyright significant changes. As a general rule of thumb, if your
> commit modifies/adds more than 10 lines of code it's likely going to
> be copyright-significant. And if in doubt, it's better to err on the
> safe side and update it anyway.
>
> It becomes a PITA at the end of each year when the full list of modified
> files needs to be checked manually.
>
> --
> 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
>
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] prevent duplicated entries due to symlinks
Pavel Roskin schrieb:
On Fri, 2009-05-01 at 22:51 +0200, Andreas Born wrote:
If there's both a symlink and a kernel at which the symlink is pointing
in the list of detected kernels of 10_linux, two entries are created for
actually the same kernel. This patch checks for this condition and only
uses the symlink (usually the wanted behaviour), in case the target of
the symlink doesn't exist, it uses neither.
Furthermore there may be kernel images named e.g. /boot/vmlinuz, so to
detect those the patch doesn't require a hyphen in the kernel name.
In this case the sed used to determine the kernel version, won't return
as expected an empty string. Therefore I replaced it by another one with
the wanted behaviour.
If the kernel version can be empty we don't want to have a "GNU/Linux,
linux " menuentry. Accordingly this patch adds a check for empty kernel
version, so that only "GNU/Linux" will be displayed.
The result will be that we would have an entry without version instead
of an entry with a version. That's hardly an improvement. Can you give
an example where it would be useful?
You have a symlink named /boot/vmlinuz which points at the current
kernel version. Now you could of course find out which kernel version
it's pointing at but that version could change anytime. /boot/vmlinu[zx]
and /vmlinu[zx] (there should only exist one of them) are the only cases
I can think of which have no version in their name. So you always know
that the version-free entry always boots the kernel pointed at by
/boot/vmlinuz, which is always the current kernel if your distro
maintains the symlink. I see no regression there.
This is for example my Zenwalk boot entry:
'menuentry "Zenwalk GNU/Linux" {
set root=(hd0,3)
search --fs-uuid --set 408e3e53-d766-4592-bb12-31233bd415c0
linux16/boot/vmlinuz root=/dev/sda3 ro splash=silent
resume=/dev/sda7 vga=794
initrd16/boot/initrd.splash
}'
That's the symlink: /boot/vmlinuz -> vmlinuz-2.6.29.2
Finally there's quite a bunch of other names for initrds. This patch
adds support for initrd.gz and initrd.splash. Both initrd.img and
initrd.gz become or were yet supported with two different version
positions and without version at all. For initrd.splash this isn't
needed because it's not kernel version dependent.
Please specify where those names are used. Can you give the
distribution name and version where such names are used?
Zenwalk, Slackware for example. I think more Slackware derivates are
using it too.
What is initrd.splash? Why does it need to be handled like initrd and
why is it always version independent? Again, where is it used?
initrd.splash is used by Zenwalk (others too) it contains only the data
of one or multiple bootsplashes as returned by the "splash" command.
It's used by bootsplash and doesn't contain any files, modules, etc.
The version independence is quite self-explaining now, I think. Unless
bootsplash support was removed it works for any kernel version. And even
if bootsplash support is removed it does no harm to load it.
Is it understandable now?
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] improve error messages in grub-setup
On Sun, May 03, 2009 at 05:02:33PM -0400, Pavel Roskin wrote: > > > grub_util_warn() doesn't set any flag that there have been > > > warnings. > > > > That's an option, too. But it would preclude the possibility of issuing > > warnings for which we don't want to require --force (i.e. lesser evils). > > I wonder if that would be a problem? > > We can decide it when we know what the lesser evils are. I'm fine with > your patch. Alright then, I checked it in. -- 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] add disk name to scanning debug output
On Sun, May 03, 2009 at 04:14:02PM +0200, martin f. krafft wrote:
> Signed-off-by: martin f. krafft
> ---
> disk/raid.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/disk/raid.c b/disk/raid.c
> index 2b3130b..8b026cd 100644
> --- a/disk/raid.c
> +++ b/disk/raid.c
> @@ -598,7 +598,7 @@ grub_raid_scan_device (int head_only)
>struct grub_raid_array array;
>struct grub_raid *p;
>
> - grub_dprintf ("raid", "Scanning for RAID devices\n");
> + grub_dprintf ("raid", "Scanning for RAID devices on disk %s\n", name);
>
>disk = grub_disk_open (name);
>if (!disk)
Committed, thanks.
Btw next time please include a ChangeLog entry (and make it an inline
attachment).
--
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
Copyright lines not being updated!
Hi all, Please remember to update copyright lines in files when you commit copyright significant changes. As a general rule of thumb, if your commit modifies/adds more than 10 lines of code it's likely going to be copyright-significant. And if in doubt, it's better to err on the safe side and update it anyway. It becomes a PITA at the end of each year when the full list of modified files needs to be checked manually. -- 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] Video mode fixes in linux loader
On Mon, May 04, 2009 at 11:15:13AM -0400, BandiPat wrote: > Robert Millan wrote: >> On Sat, May 02, 2009 at 08:03:23PM -0400, BandiPat wrote: >>> linux16 /boot/vmlinuz root=/dev/sda1 ro resume=/dev/sda4 >>> splash=silent vga=794 >> >> This means vga=0x31a, aka 16-bit 1280x1024. Does 24-bit (vga=0x31b) work? >> >> I suspect there's some fuzzy matching here. >> > === > Thanks Robert for the suggestion. I had renewed hopes this might work, > but it would not. After editing the menuentry to use either the > vga=0x31b or vga=795, the machine booted to a blinking cursor. It would > not go beyond that. What suitable modes does "vbeinfo" list? > Does that help in determining where maybe the problem lies? Also, I > thought both linux16 and vga were deprecated, no longer to be used? "vga" is deprecated, but we don't have a replacement for it yet. "linux16" will eventually become completely obsolete, but some users (e.g. you) still need to rely on it, which is why we didn't remove 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] hfs+ uuid
commited On Mon, May 4, 2009 at 3:22 PM, Pavel Roskin wrote: > On Mon, 2009-05-04 at 15:08 +0200, Vladimir 'phcoder' Serbinenko wrote: > > > Setting two environment variables is undocumented. I think > > rd_string > > should not be needed. If you need it due to the script engine > > problems, > > it's better to fix the script engine. > > I'm looking how to do it. The corresponding part to support foo=$bar > > is here but commented out. > > The changes to fs/hfsplus.c look rather uncontroversial. Maybe you > could apply that part first? And then we could deal with the xnu > related stuff separately. > > -- > Regards, > Pavel Roskin > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
Robert Millan wrote: On Sat, May 02, 2009 at 08:03:23PM -0400, BandiPat wrote: linux16 /boot/vmlinuz root=/dev/sda1 ro resume=/dev/sda4 splash=silent vga=794 This means vga=0x31a, aka 16-bit 1280x1024. Does 24-bit (vga=0x31b) work? I suspect there's some fuzzy matching here. === Thanks Robert for the suggestion. I had renewed hopes this might work, but it would not. After editing the menuentry to use either the vga=0x31b or vga=795, the machine booted to a blinking cursor. It would not go beyond that. Does that help in determining where maybe the problem lies? Also, I thought both linux16 and vga were deprecated, no longer to be used? Thanks, Pat -- ---Zenwalk v6.0--Linux 2.6.28--- Registered Linux User #225206 "Ever tried Zen computing?" http://www.zenwalk.org ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: truecrypt support in grub ?
On Mon, May 4, 2009 at 2:27 PM, Chip Panarchy wrote: > So I've got to use LUKS & FreeOTFE? > FreeOTFE has a function which allows reading sectors from a device without authentication. This way the whole application security is blown away (not like the were a big deal of it, it's windows). I informed Sarah Dean that because of this function FreeOTFE is an application which destroys the security instead of enhancing it. However it looks like she doesn't understand the gravity of the problem and assumes only a threat of laptop steal and not much more common threats like viruses or trojans (it is windows, he-he) > > Seems a little hard... seeing as the different file-systems I need to > encrypt, including; > > Ext3, HFS+, Ext4, NTFS, UFS2 & ZFS > You can encrypt any FS with any full-disk-encryption. The encryption doesn't care what you put on it. > > Any other drive encryption tools you'd like to suggest, or should I > stick to TrueCrypt (will start using it once all my OSs are working > together) > What you say is quite out of sync with reality. I don't know any program able to boot two different OSes encrypted with it. (I don't speak about reading volumes, I speak about booting). Additionally such a setup is less secure than encrypting every OS separately since if one OS is compomised it's somewhat contained (not entirely true actually). AFAIK till date noone was able to boot Darwin or OSX from encrypted volume. But encrypting every OS on a harddrive is really an overkill. Remember that encryption only addresses a small set of threats all of them involving physical access to your hardware. It's not like some marketing employes who make the people believe that pronouncing the word AES three times a day makes your computer secure. I doubt that you use more than one or at most two OSes for regular data work. I suppose the rest is just your experimental OSes. Encrypting experimental OS is just more headache and waste of resources. The setup I recommend is: GPT-partitioned disk: -BIOS or EFI boot partition holding embeded part of grub or grub.efi BIOS partition is typically 1 MiB in size. EFI partition is typically 100MiB in size (but 10 MiB should be enough) -GRUB /boot partition holding grub modules and linux kernels and initrds. Optionally also holding information related to booting of other OSes -Linux root, swap and home on lvm on luks -Optionally a FAT partition used to transfer data between OSes -Experimental OSes And please next time inform yourself before suggesting any feature requests. Best feature request is the one containing a patch with it. Second best is the one containing detailed info with it Anyway this discussion goes away from grub so please don't continue it here. -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hfs+ uuid
On Mon, 2009-05-04 at 15:08 +0200, Vladimir 'phcoder' Serbinenko wrote: > Setting two environment variables is undocumented. I think > rd_string > should not be needed. If you need it due to the script engine > problems, > it's better to fix the script engine. > I'm looking how to do it. The corresponding part to support foo=$bar > is here but commented out. The changes to fs/hfsplus.c look rather uncontroversial. Maybe you could apply that part first? And then we could deal with the xnu related stuff separately. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hfs+ uuid
On Sun, May 3, 2009 at 6:55 PM, Pavel Roskin wrote: > On Sun, 2009-05-03 at 12:42 +0200, Vladimir 'phcoder' Serbinenko wrote: > > This is a patch to support UUIDs on HFS+. MD5 code is copied from > > Michael Gorven's patch which is copied from libgcrypt nearly verbatim. > > Thanks for Cris for the info about how xnu expects UUID to be > > I suggest that you run all new code through GNU indent. Spacing in > "32-(n)" will probably need to be fixed manually, as it's a preprocessor > directive. > > Commented out call to to _gcry_burn_stack() should probably be removed. > I would prefer that we don't use #undef. Instead, the preprocessor > defines should use unique names that never need to be redefined. > This part is temporary copied here till Michael Gorven's patch is merged. > > Setting two environment variables is undocumented. I think rd_string > should not be needed. If you need it due to the script engine problems, > it's better to fix the script engine. I'm looking how to do it. The corresponding part to support foo=$bar is here but commented out. > At least please mark that hack as > a hack. > > Perhaps we should consider adding %X support to grub_printf(). I > realize that it will increase the core slightly, but if it's just a few > bytes, we could accept it. Other modules may use it. Let me think a bit about it. Unfortunately what seems to be few bytes in a first glance may be up to 100 bytes once implemented > Or maybe we could > have grub_toupper(), perhaps an inline function? > If it's an inline then it's ok. > > Another thing to consider is whether md5 support should be in a separate > file. It would make it possible to reuse md5 for other commands. > Actually md5 is a part of Michael Gorven patch where it's exported nicely but since his patch is pending I temporary copied it to this file. So I think it's unnecessary to > > -- > Regards, > Pavel Roskin > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: truecrypt support in grub ?
loop-aes... On 5/4/09, Chip Panarchy wrote: > So I've got to use LUKS & FreeOTFE? > > Seems a little hard... seeing as the different file-systems I need to > encrypt, including; > > Ext3, HFS+, Ext4, NTFS, UFS2 & ZFS > > Any other drive encryption tools you'd like to suggest, or should I > stick to TrueCrypt (will start using it once all my OSs are working > together) > > > On Mon, May 4, 2009 at 2:28 AM, Robert Millan wrote: > > On Sun, May 03, 2009 at 10:47:00AM +1000, Chip Panarchy wrote: > >> ^Ah. > >> > >> What would you suggest instead, for a free full-drive encryption? > > > > LUKS > > > > -- > > 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 > > > > > ___ > 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: truecrypt support in grub ?
So I've got to use LUKS & FreeOTFE? Seems a little hard... seeing as the different file-systems I need to encrypt, including; Ext3, HFS+, Ext4, NTFS, UFS2 & ZFS Any other drive encryption tools you'd like to suggest, or should I stick to TrueCrypt (will start using it once all my OSs are working together) On Mon, May 4, 2009 at 2:28 AM, Robert Millan wrote: > On Sun, May 03, 2009 at 10:47:00AM +1000, Chip Panarchy wrote: >> ^Ah. >> >> What would you suggest instead, for a free full-drive encryption? > > LUKS > > -- > 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 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
