Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Thu 2017-09-21 10:26:08 -0400, Daniel Kahn Gillmor wrote: > I like this idea but i don't have a lot of spare machines handy to try > d-i on these days. I can try to dig up a power supply for an idle older > ppc laptop i've got floating around, but i don't know whether i'll be > able to find it. I should mention: i currently run (and have run in the past) many powerpc systems (old Mac hardware, mainly, running an OpenFirmware forth shell from the mainboard), all of which i either directly installed with grub (via debootstrap from debirf) or converted from yaboot to grub. I've yet to find one (even a really old blue clamshell iBook with 64MiB of RAM) that grub didn't work for me on in the end. So for the machines i've dealt with, the question is more about d-i integration than about whether grub will work or not. I do note that there have been some interesting endianness issues (e.g. channel-swap, or palette inversion) with the colorspace when trying to use grub's graphical mode (but i've seen similar issues with non-grub stuff as well). I don't know how much we care in this discussion about grub's graphical capabilities, as compared to its booting capabilities. yaboot had no graphical capabilities at all, iirc. --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Thu 2017-09-21 14:21:52 +0200, John Paul Adrian Glaubitz wrote: > I would help with this transition to use GRUB on powerpc as well > as on ppc64 which we are now providing unofficial installation > for in Debian Ports [1]. > > I do have commit access to debian-installer and its components > as well as access to an IBM POWER7 instance which can be used > to test both powerpc as well as ppc64 installation images. > > I would like to get rid of yaboot because it is no longer maintained > upstream and switching to GRUB also helps reduce the maintenance > burden in debian-installer. > > What we need are people who are willing to extensively test d-i > images with GRUB on powerpc and ppc64 and report back. Also, I'm > not yet sure whether I have understood how exactly GRUB is properly > configured and used on powerpc and ppc64. I like this idea but i don't have a lot of spare machines handy to try d-i on these days. I can try to dig up a power supply for an idle older ppc laptop i've got floating around, but i don't know whether i'll be able to find it. sorry to not be more help. it'd be great to be able to drop yaboot. --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] Clarify documentation for special environment variable "default"
The current documentation for the special environment variable
"default" is confusing and unclear. This patch attempts to clean it
up.
In particular, the current documentation refers to the "number or
title", but then in the example it gives, the menu entries and
submenus all have numbers *in* their title; furthermore, there is no
example given about how to choose the number, or any indication about
whether counting is zero-indexed or 1-indexed.
Having a cleaner example and presenting all variants (numeric, title,
and id) should make it clearer to the user.
Signed-off-by: Daniel Kahn Gillmor <d...@fifthhorseman.net>
---
docs/grub.texi | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index b9ddb9b8a..e935af33e 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3218,9 +3218,10 @@ source for more details.
@node default
@subsection default
-If this variable is set, it identifies a menu entry that should be selected
-by default, possibly after a timeout (@pxref{timeout}). The entry may be
-identified by number or by id.
+If this variable is set, it identifies a menu entry that should be
+selected by default, possibly after a timeout (@pxref{timeout}). The
+entry may be identified by number (starting from 0 at each level of
+the hierarchy), by title, or by id.
For example, if you have:
@@ -3236,24 +3237,26 @@ then you can make this the default using:
default=example-gnu-linux
@end example
-If the entry is in a submenu, then it must be identified using the titles of
-each of the submenus starting from the top level followed by the number or
-title of the menu entry itself, separated by @samp{>}. For example, take
-the following menu structure:
+If the entry is in a submenu, then it must be identified using the
+number, title, or id of each of the submenus starting from the top
+level, followed by the number, title, or id of the menu entry itself,
+with each element separated by @samp{>}. For example, take the
+following menu structure:
@example
-Submenu 1
- Menu Entry 1
- Menu Entry 2
-Submenu 2
- Submenu 3
-Menu Entry 3
-Menu Entry 4
- Menu Entry 5
+GNU/Hurd --id gnu-hurd
+ Standard Boot --id=gnu-hurd-std
+ Rescue shell --id=gnu-hurd-rescue
+Other platforms --id=other
+ Minix --id=minix
+Version 3.4.0 --id=minix-3.4.0
+Version 3.3.0 --id=minix-3.3.0
+ GRUB Invaders --id=grub-invaders
@end example
-``Menu Entry 3'' would then be identified as
-@samp{Submenu 2>Submenu 3>Menu Entry 3}.
+The more recent release of Minix would then be identified as
+@samp{Other platforms>Minix>Version 3.4.0}, or as @samp{1>0>0}, or as
+@samp{other>minix>minix-3.4.0}.
This variable is often set by @samp{GRUB_DEFAULT} (@pxref{Simple
configuration}), @command{grub-set-default}, or @command{grub-reboot}.
--
2.11.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Clarify documentation for special environment variable "default"
The current documentation for the special environment variable
"default" is confusing and unclear. This patch attempts to clean it
up.
In particular, the current documentation refers to the "number or
title", but then in the example it gives, the menu entries and
submenus all have numbers *in* their title; furthermore, there is no
example given about how to choose the number (e.g. does it start at 1
or at 0?).
Having a cleaner example and presenting both the numeric version and
the title version will make it clearer.
In my patch here i've tried to make it clear and understandable. I've
also assumed that the number counting starts at 1, but haven't
verified that. If that's wrong, please commit the corrected version
:)
Signed-off-by: Daniel Kahn Gillmor <d...@fifthhorseman.net>
---
docs/grub.texi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index b9ddb9b8a..e868f045d 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3242,18 +3242,18 @@ title of the menu entry itself, separated by @samp{>}.
For example, take
the following menu structure:
@example
-Submenu 1
- Menu Entry 1
- Menu Entry 2
-Submenu 2
- Submenu 3
-Menu Entry 3
-Menu Entry 4
- Menu Entry 5
+GNU/Hurd
+ Standard Boot
+ Rescue shell
+Other platforms
+ Minix
+Version 3.4.0
+Version 3.3.0
+ GRUB Invaders
@end example
-``Menu Entry 3'' would then be identified as
-@samp{Submenu 2>Submenu 3>Menu Entry 3}.
+The more recent release of Minix would then be identified as
+@samp{Other platforms>Minix>Version 3.4.0}, or as @samp{2>1>1}.
This variable is often set by @samp{GRUB_DEFAULT} (@pxref{Simple
configuration}), @command{grub-set-default}, or @command{grub-reboot}.
--
2.11.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Clarify documentation for special environment variable "default"
The current documentation for the special environment variable
"default" is confusing and unclear. This patch attempts to clean it
up.
In particular, the current documentation refers to the "number or
title", but then in the example it gives, the menu entries and
submenus all have numbers *in* their title; furthermore, there is no
example given about how to choose the number (e.g. does it start at 1
or at 0?).
Having a cleaner example and presenting both the numeric version and
the title version will make it clearer.
In my patch here i've tried to make it clear and understandable. I've
also assumed that the number counting starts at 1, but haven't
verified that. If that's wrong, please commit the corrected version
:)
Signed-off-by: Daniel Kahn Gillmor <d...@fifthhorseman.net>
---
docs/grub.texi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index b9ddb9b8a..e868f045d 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3242,18 +3242,18 @@ title of the menu entry itself, separated by @samp{>}.
For example, take
the following menu structure:
@example
-Submenu 1
- Menu Entry 1
- Menu Entry 2
-Submenu 2
- Submenu 3
-Menu Entry 3
-Menu Entry 4
- Menu Entry 5
+GNU/Hurd
+ Standard Boot
+ Rescue shell
+Other platforms
+ Minix
+Version 3.4.0
+Version 3.3.0
+ GRUB Invaders
@end example
-``Menu Entry 3'' would then be identified as
-@samp{Submenu 2>Submenu 3>Menu Entry 3}.
+The more recent release of Minix would then be identified as
+@samp{Other platforms>Minix>Version 3.4.0}, or as @samp{2>1>1}.
This variable is often set by @samp{GRUB_DEFAULT} (@pxref{Simple
configuration}), @command{grub-set-default}, or @command{grub-reboot}.
--
2.11.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
reporting amount of available memory (and acting on it) from grub?
Hi grub folks-- Is there a way that a grub script (or the grub commandline) can report the amount of available memory? It seems like it would be useful in situations like a liveCD or bootable image that might want to warn the user up front if the available RAM is smaller than the advertised minimum. (e.g. Tails or debirf) Currently, when systems boot with less memory than their minimums, they often end up with a kernel dump or something similarly unintelligible to most users. A well-crafted grub configfile for such an image could provide the user with something more understandable, or at least warn the user before continuing that the available memory is believed to be inadequate. I could also imagine a use case like an automated boot process that selects some x86_64 kernel or boot options on machines with > 4GiB of RAM and plain x86 for machines with less. any pointers to how to do this? --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Plain dm-crypt
On Thu 2015-10-29 13:46:42 -0400, christopher.to...@riseup.net wrote: > No, since I type the line in manually every time, it is not located > anywhere for it to be discovered and need denying. I know my system very > well. I know if I put one USB drive into a slot, it will be named > (USB0). If I plug more than one USB drive into the system, I know what > they will be named based on their physical locations. "Deniable" crypto seems like it would have very limited utility [0], but there could still be some marginal use cases for it (for people who aren't Christopher Toews, anyway: Chris has already admitted publicly on this list to using encryption on his high-entropy devices, so he can't deny it any longer). If the patchset is small/simple (i haven't seen a pointer to the patches -- can someone supply a link?), and it doesn't introduce any troubling UI/UX issues, providing the feature in grub doesn't seem like a terrible idea. The other use case that Chris hasn't mentioned is that there may be people who don't trust LUKS to adequately protect the master dm-crypt key for their volume. I'm unaware of any legitimate reason to distrust the cryptography in the LUKS header itself, but i also haven't thought deeply about attacking it either. > Look, you can't presume to know my setup better than I do and then try > to convince me that I don't require this feature. I understand if it > won't be included, but don't hold it out because you think people are > too stupid to know how to use it, or worse, because you think people are > too stupid to know that they don't need it. There are people who want > this feature for good reasons and have the know-how to be able to > utilize it. Why can't you just accept that? I suspect that Vladimir isn't resistant because he thinks people are stupid. he's probably resistant like any other responsible long-term developer/maintainer of crucial infrastructure. more features == more support == more bugs, so conservatism on adding features is healthy, and it's not surprising that he is looking for a more concrete example of how it might get used. That said, it's tough to to provide a more concrete use case than the one descirbed by Chris here. In particular, this is a feature whose users will generally not admit to being users (since admitting to being a user is to lose its benefit). So i appreciate Chris being willing to out himself here in service of others who might like to have something that looks deniable. (fwiw, i'd really like it if all hard drives shipped from the manufacturer full of high-entropy noise by default. That would provide people like the users Chris is advocating for with much more convincing cover) --dkg [0] https://www.debian-administration.org/users/dkg/weblog/104 discusses deniability for chat, but similar analysis probably applies to encrypted volumes. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] use stock embedded timestamp 2015-01-01T0000+0000
On Fri 2015-03-27 08:27:42 -0400, Vladimir 'φ-coder/phcoder' Serbinenko wrote: @@ -1856,7 +1859,7 @@ grub_install_generate_image (const char *dir, const char *prefix, head-magic = image_target-bigendian ? grub_host_to_target16 (0x160) : grub_host_to_target16 (0x166); head-nsec = grub_host_to_target16 (1); -head-time = grub_host_to_target32 (0); +head-time = grub_host_to_target32 (STABLE_EMBEDDING_TIMESTAMP); I dropped this hunk as it's just changing one const to another. head-opt = grub_host_to_target16 (0x38); head-flags = image_target-bigendian ? grub_host_to_target16 (0x207) Sure, that's fine with me. I supplied it there so that we could say any grub image on any platform with an embedded timestamp will use the same timestamp, but if you don't think that's a necessary or useful statement to make, i have no interest in pushing it separately. My main goal is image reproducibility, and the MIPS_ARC builds were already reproducible. Thanks for adopting the fixed timestamp for the other two platforms! --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] use stock embedded timestamp 2015-01-01T0000+0000
Variant timestamps make some grub platforms produce non-deterministic
core images. This makes it difficult to use simple tools to audit the
stability of a system with grub installed.
This patch selects a single timestamp to use for these embedded
timestamps so that the core images will be replicable.
---
util/mkimage.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/util/mkimage.c b/util/mkimage.c
index 7821dc5..adc1706 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -55,6 +55,9 @@
#define TARGET_NO_FIELD 0x
+/* use 2015-01-01T00:00:00+ as a stock timestamp */
+#define STABLE_EMBEDDING_TIMESTAMP 1420070400
+
struct grub_install_image_target_desc
{
const char *dirname;
@@ -1439,7 +1442,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
c-machine = grub_host_to_target16 (image_target-pe_target);
c-num_sections = grub_host_to_target16 (4);
- c-time = grub_host_to_target32 (time (0));
+ c-time = grub_host_to_target32 (STABLE_EMBEDDING_TIMESTAMP);
c-characteristics = grub_host_to_target16 (GRUB_PE32_EXECUTABLE_IMAGE
|
GRUB_PE32_LINE_NUMS_STRIPPED
|
((image_target-voidp_sizeof == 4)
@@ -1782,7 +1785,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
memset (hdr, 0, sizeof (*hdr));
hdr-ih_magic = grub_cpu_to_be32_compile_time (GRUB_UBOOT_IH_MAGIC);
- hdr-ih_time = grub_cpu_to_be32 (time (0));
+ hdr-ih_time = grub_cpu_to_be32 (STABLE_EMBEDDING_TIMESTAMP);
hdr-ih_size = grub_cpu_to_be32 (core_size);
hdr-ih_load = grub_cpu_to_be32 (image_target-link_addr);
hdr-ih_ep = grub_cpu_to_be32 (image_target-link_addr);
@@ -1856,7 +1859,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
head-magic = image_target-bigendian ? grub_host_to_target16 (0x160)
: grub_host_to_target16 (0x166);
head-nsec = grub_host_to_target16 (1);
- head-time = grub_host_to_target32 (0);
+ head-time = grub_host_to_target32 (STABLE_EMBEDDING_TIMESTAMP);
head-opt = grub_host_to_target16 (0x38);
head-flags = image_target-bigendian
? grub_host_to_target16 (0x207)
--
2.1.4
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] make grub-install on efi idempotent by omitting PE timestamp
I'm using grub-efi on a debian amd64 system, with the ESP mounted at
/boot/efi.
when i run:
grub-install
the digest of /boot/efi/EFI/debian/grubx64.efi changes:
root@pops:~# sha1sum /boot/efi/EFI/debian/grubx64.efi
eafbe63218ecb7f7e69522e55ff7bc9551002c08 /boot/efi/EFI/debian/grubx64.efi
root@pops:~# grub-install
Installing for x86_64-efi platform.
Installation finished. No error reported.
root@pops:~# sha1sum /boot/efi/EFI/debian/grubx64.efi
b3ec06be87d356479e652e6515814ed4fd8f35cc /boot/efi/EFI/debian/grubx64.efi
root@pops:~#
I compared the two versions, and it looks like they only differ in the
PE timestamp:
root@pops:~# cp /boot/efi/EFI/debian/grubx64.efi{,.bak}
root@pops:~# grub-install
Installing for x86_64-efi platform.
Installation finished. No error reported.
root@pops:~# sha1sum /boot/efi/EFI/debian/grubx64.efi{,.bak}
a2fe7412a8fff69b033c5b11eb3a78927ea084e1 /boot/efi/EFI/debian/grubx64.efi
b3ec06be87d356479e652e6515814ed4fd8f35cc /boot/efi/EFI/debian/grubx64.efi.bak
root@pops:~# diff -u (hd /boot/efi/EFI/debian/grubx64.efi.bak ) (hd
/boot/efi/EFI/debian/grubx64.efi )
--- /dev/fd/63 2015-03-20 09:32:36.784878070 -0400
+++ /dev/fd/62 2015-03-20 09:32:36.784878070 -0400
@@ -6,7 +6,7 @@
0050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f |is program canno|
0060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 |t be run in DOS |
0070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 |mode$...|
-0080 50 45 00 00 64 86 04 00 30 21 0c 55 00 00 00 00 |PE..d...0!.U|
+0080 50 45 00 00 64 86 04 00 42 21 0c 55 00 00 00 00 |PE..d...B!.U|
0090 00 00 00 00 f0 00 0e 02 0b 02 00 00 00 96 00 00 ||
00a0 00 2c 01 00 00 00 00 00 00 04 00 00 00 04 00 00 |.,..|
00b0 00 00 00 00 00 00 00 00 00 02 00 00 00 02 00 00 ||
root@pops:~#
These are definitely timestamps, as the two files were generated about
20 seconds apart, and 0x42 - 0x30 = 0x12 = 18. Here's the
timestamp-to-date conversion:
$ date -d \@$(printf '%d' 0x550c2130)
Fri Mar 20 09:31:28 EDT 2015
$
This seems like a spurious change to me, and one that makes it harder to
do things like compare checksums to make sure no one has tampered with
the bootloader, or keeping a signature valid for the bootloader as blob.
Is there a reason to embed the timestamps here? in practice, PE
executables seem to be able to work with an all-zero timestamp
(e.g. see ld's --no-insert-timestamp option).
It looks like we're also embedding the timestamp for UBOOT images.
This should be fixable with the following change, which covers both efi
(first hunk) and uboot (second hunk):
--
diff --git a/util/mkimage.c b/util/mkimage.c
index 7821dc5..4b0f4de 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -1439,7 +1439,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
c-machine = grub_host_to_target16 (image_target-pe_target);
c-num_sections = grub_host_to_target16 (4);
- c-time = grub_host_to_target32 (time (0));
+ c-time = grub_host_to_target32 (0);
c-characteristics = grub_host_to_target16 (GRUB_PE32_EXECUTABLE_IMAGE
|
GRUB_PE32_LINE_NUMS_STRIPPED
|
((image_target-voidp_sizeof == 4)
@@ -1782,7 +1782,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
memset (hdr, 0, sizeof (*hdr));
hdr-ih_magic = grub_cpu_to_be32_compile_time (GRUB_UBOOT_IH_MAGIC);
- hdr-ih_time = grub_cpu_to_be32 (time (0));
+ hdr-ih_time = grub_cpu_to_be32 (0);
hdr-ih_size = grub_cpu_to_be32 (core_size);
hdr-ih_load = grub_cpu_to_be32 (image_target-link_addr);
hdr-ih_ep = grub_cpu_to_be32 (image_target-link_addr);
--
I notice that we're already embedding 0 for the timestamp for MIPS_ARC
on util/mkimage:1859, so this isn't without precedent.
If we want to get fancier, we could make an --embed-timestamp=SECONDS
option to grub-install, which would allow the user to explicitly set the
timestamp to a known value, or an --embed-current-timestamp option to
actually use the output of time(0), but i wouldn't get that fancy
without first hearing a strong argument for why we need an embedded
timestamp in the first place.
what do you think?
--dkg
signature.asc
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] make grub-install on efi idempotent by omitting PE timestamp
On Fri 2015-03-20 11:25:25 -0400, Vladimir 'φ-coder/phcoder' Serbinenko wrote: I've already detailed in another post in another post why embedding 0 is probably bad and that it's better to embed either 2015-01-01 00:00:00 or the date of last commit which can be put into modinfo.sh during compile time. whoops, sorry! I missed that the first time through. I just followed up on that thread with a patch using 2015-01-01 00:00:00. I can work up another patch with modinfo.sh approach if you like, but i think a stable/permanent timestamp is better. If i recompile grub with a patch affecting some other piece of code (code that doesn't affect the core image), and then i use the new grub to produce an image, i'd like to be able to see that the resultant image is identical. --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Restrictive file permissions
On 12/05/2013 04:20 PM, Jonathan McCune wrote: On Thu, Dec 5, 2013 at 10:10 AM, Colin Watson cjwat...@ubuntu.com wrote: I think we should identify the call sites that really need restricted permissions, explicitly lock them down, and open things back up for everything else. I agree that this policy makes more sense. fwiw, i agree with Jonathan and Colin that the default should be readable, and that we should only lock down specific files when we know that there is a need. i've argued for locking down the initramfs when it contains secret key material in http://bugs.debian.org/536195 so i'm aware that there are legitimate read-sensitivity concerns for some bootloader-available data. I'm really glad that the issue is taken seriously by the GRUB team. i just don't think files should be unreadable by default, because i prefer the ease of collaborative maintenance (as highlighted by Colin) and the general principle of system transparency for users where it does not present a security risk. --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Experiments with git. Hold your commits for today
On 10/22/2013 02:24 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: GIT repo is up and running now it's main repo. You can commit your patches to it. Keep a copy of any patch you commit in case I have to reimport repository. Thank you for doing this maintenance work, phcoder! As a user of the project's revision control and (infrequent) contributor I am happy to see the change. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
trouble (very slow reads -- disk or controller resets?) with Marvell 88SE92xx PCIe card
hi there-- i'm trying to boot a machine with grub-pc 2.00-19 (from debian sid), off of two SATA disks connected to a PCIe controller. The PCIe controller is a SYBA SI-PEX40064, and upon boot it announces itself as: Marvell 88SE92xx Adapter - BIOS Version 1.0.0.1010 PCIe x1 2.5Gbps Mode: PassThru AHCI Disks Information: Port Disk NameSizeSpeed S0 SATA: WDC WD2003FYYS-02W0B0 2TB 3Gb/s S1 SATA: ST32000644NS 2TB 3Gb/s Both of these disks have grub installed on them, and they hang with just the output GRUB on the video console. If i boot grub 2.00-19 from a USB stick, i can get into a grub rescue shell just fine. But when i do ls to get a listing of the disks, it pauses for over a minute after printing: (hd0) (hd0,msdos1) (hd1) (hd2) and before giving me back a grub prompt. after insmod part_gpt and another ls, i get: (hd0) (hd0,msdos1) (hd1) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1) (hd2) and then another long hang. this makes me think that grub is causing the SATA controller to reset itself with every disk read or something, and then grub is waiting for it to come back to life before carrying on. Is this something i can debug better somehow? is there a way to tell grub to be gentler with the controller or something to avoid these hangs? --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Moving from Bazaar (bzr) to git
On 06/24/2013 06:27 AM, Mikko Rantalainen wrote: I'd suggest trying to apply the workflow used by git development for grub, too. While i don't expect my opinion to have any particular weight (i'm mostly a bug reporter and tester in this community) i would also be happy to see a switch from bzr to git if the upstream devs are OK with it. Make sure to have a mirror at github.com and if you don't want to use github's issue tracker, put a big disclaimer about that in github. As far as I know, you cannot disable public issue tracker in github repository's settings. I have to disagree with the above. Maintaining a mirror at github.com is not at all a requirement, and the maintenance of such a mirror is extra work (however small). The extra mirror can potentially create confusion if it isn't properly maintained, as can the github issue tracker if it isn't the canonical issue tracker. If you consider switching to git, please don't spend any extra cycles worrying about github.com integration unless you have a compelling reason to do so. --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh from bzr failed : configure.ac:382: error: expected source file, required through AC_LIBSOURCES, not found
On 04/07/2013 02:22 AM, Andrey Borzenkov wrote: В Sun, 07 Apr 2013 00:04:08 -0400 Daniel Kahn Gillmor d...@fifthhorseman.net пишет: [...] missing file grub-core/gnulib/getopt1.c Do you actually have this file? Just to be sure? hm, good call, the file wasn't there. after checking at the bzr webview [0] to see that it's actually supposed to be on trunk in the first place (and not generated by some previous autotools step or something), i did a bit of further digging. it was a problem with my use of git-bzr, reported now at http://bugs.debian.org/704913 i'm now using standard bzr instead of git-bzr to do the repository work, and the build seems to be working fine. Sorry about the false alarm, --dkg [0] http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/head:/grub-core/gnulib/getopt1.c signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
autogen.sh from bzr failed : configure.ac:382: error: expected source file, required through AC_LIBSOURCES, not found
hi grub folk-- I'm trying to build grub from the current bzr head on a powerpc64 debian unstable system. I'm afraid i'm getting stuck right at the beginning, as i try to autogen: 0 dkg@reason:~/src/grub/grub$ ./autogen.sh Importing unicode... Importing libgcrypt... Creating Makefile.tpl... Running autogen... Saving timestamps... Running autoreconf... autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 missing file grub-core/gnulib/getopt1.c configure.ac:382: error: expected source file, required through AC_LIBSOURCES, not found m4/gnulib-comp.m4:100: gl_INIT is expanded from... configure.ac:382: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: /usr/bin/autom4te failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 1 dkg@reason:~/src/grub/grub$ I don't know what this error means; i've got gnulib and the various auto* packages installed: 0 dkg@reason:~/src/grub/grub$ dpkg -l 'auto*' gnulib Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii autoconf 2.69-1 all automatic configure script builde un autoconf-archi none(no description available) un autoconf-doc none(no description available) un autoconf2.13 none(no description available) un autofs none(no description available) ii autogen1:5.17.2-1 powerpc automated text file generator ii automake 1:1.12.6-2 all Tool for generating GNU Standards un automake1.10-d none(no description available) un automake1.12 none(no description available) un automake1.5none(no description available) un automake1.6none(no description available) un automake1.9none(no description available) un automaken none(no description available) ii autopoint 0.18.1.1-10 all The autopoint program from GNU ge ii autotools-dev 20120608.1 all Update infrastructure for config. ii gnulib 20120404+sta all GNU Portability Library 0 dkg@reason:~/src/grub/grub$ i've also tried it with automake 1:1.11.6-1 and autogen 1:5.12-0.1, and i get the same error messages when doing ./autogen.sh from a clean copy. what am i missing? --dkg pgpoPsdJbiqP1.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
online manual is out of date
hi folks-- https://www.gnu.org/software/grub/manual/grub.html appears to be generated from 2.00~rc1. Given that 2.00 has been out for a while now, it seems like the online docs should probably be updated to match. Thanks for all the work on grub! Regards, --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: pxe failing on grub 2.00 for files larger than 50KiB
On 09/25/2012 03:09 PM, Seth Goldberg wrote: Is it possible that debian mismerged some changes from 2.00? no, i don't think so. the tarball that debian's 2.00-5 package i used has this sha1 sum: 274d91e96b56a5b9dd0a07accff69dbb6dfb596b ../grub2_2.00.orig.tar.xz which is the same as the upstream tarball i find at ftp://ftp.gnu.org/gnu/grub/grub-2.00.tar.xz and that has a date of June 28, while r4505 has a date of June 22nd. There is code in tftp.c that stalls TFTP responses if = 50 packets are queued by the network driver. That packet count is increased by one each time grub_net_put_packet is called and decreased by one each time grub_net_receive_packet is called. Those packet count changes went into revision 4505 (Implement flow control for tftp). hmm, r4505 introduces a hard limit of 200 in grub-core/net/tftp.c, but the grub tarball seems to have a hard limit of 50, apparently introduced in r4508. come to think of it, i see grub_net_put_packet() (which increments packs.count) in grub-core/net/tftp.c, but i see no evidence that grub_net_remove_packet() ever gets called there. is there something else i should look into? --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.pxe, ARP-after-boot, DMA, and trouble
On Sat, 07 Apr 2012 01:36:44 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
In particular, i suspect that *after* the bootloader has turned over
control to the kernel (memtest in this case), the PXE-driven NIC is
continuing to DMA received packets into active RAM.
phcoder sent me the patch below to address the PXE DMA issue.
I tested it against the current bzr head.
My testing grub.cfg is just:
--
serial --speed=115200
terminal_input console serial
terminal_output console serial
linux16 (pxe)/memtest86+.bin console=ttyS0,115200n8
boot
--
Using grub bzr head without this patch, i get these RAM failures on
the net-booted ThinkCentre M70 within ~15 seconds on roughly every other
boot (i haven't found the right packets to inject to force the DMA to
happen consistently, alas).
Using grub bzr head with the patch, i have been unable to reproduce
a single RAM failures in more than 20 trials.
I think this patch resolves the issue, and should go into the mainline.
Thanks, phcoder!
--dkg
=== modified file 'grub-core/net/drivers/i386/pc/pxe.c'
--- grub-core/net/drivers/i386/pc/pxe.c 2012-02-08 18:26:01 +
+++ grub-core/net/drivers/i386/pc/pxe.c 2012-04-11 12:53:17 +
@@ -278,9 +278,14 @@
grub_pxe_close (const struct grub_net_card *dev __attribute__ ((unused)))
{
if (pxe_rm_entry)
-grub_pxe_call (GRUB_PXENV_UNDI_CLOSE,
- (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR,
- pxe_rm_entry);
+{
+ grub_pxe_call (GRUB_PXENV_UNDI_CLOSE,
+ (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR,
+ pxe_rm_entry);
+ grub_pxe_call (GRUB_PXENV_UNDI_SHUTDOWN,
+ (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR,
+ pxe_rm_entry);
+}
}
static grub_err_t
pgplVUhF2vmVX.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
grub.pxe, ARP-after-boot, DMA, and trouble
I've been recently using grub.pxe (from debian's version 1.99-17)
according to the instructions at [0] to boot memtest86+ [1] (from
debian's version 4.20-1.1) over the network on x86 machines. Due to the
problems described below, i'm using a serial console.
The grub configuration is very simple:
--
serial --speed=115200
terminal_input console serial
terminal_output console serial
menuentry 'memtest86+ serial console' {
set root='(pxe)'
echo 'loading memory tester...'
linux16 /memtest86+.bin console=ttyS0,115200n8
}
--
On some machines i've done this with, memtest86+ reports transient
memory failures very early in the run, and the failures seem to happen
even on brand new sticks of RAM, placed in any combination and order in
the hardware. The errors were transient -- sometimes i'd get as many as
~300 32-bit words of RAM failing, other times memtest could complete a
full pass with no errors.
The failures came during an early test where memtest86+ writes each
address's value to its own memory location, and then re-reads the memory
to verify.
Using the serial line, i was able to record the memory failures from a
run that had 24 words fail. I was able to transcribe them and convert
them to a hexdump format. These are the 24 words that failed (the
memory address indices are in the left-hand column):
*
00095d30 9c c8 e3 71 dc ff 00 65 32 4b a0 29 08 06 00 01
00095d40 08 00 06 04 00 01 00 65 32 4b a0 29 c0 a8 17 54
00095d50 00 00 00 00 00 00 c0 a8 17 86 55 55 55 55 55 55
00095d60 55 55 55 55 55 55 55 55 55 55 55 55 9a a2 8c 53
*
00097590 00 00 00 00 30 5d 09 00 40 00 00 00 04 00 00 00
000975a0 4d 4d 00 00 00 00 00 00 00 00 00 00 10 38 6a 94
*
The first block (of 16 words) appears to be an ARP request packet
From the local network's DHCP server to the failing machine (the MAC
addresses have been obfuscated here, and i didn't bother updating the
checksum to match)
The second block (of 8 words) appears to contain a pointer to the
first block, a size indicator, and some other stuff i don't recognize.
So i think what's happening is something like Matthew Garrett describes
in his recent work with UEFI [2], although i'm using BIOS and not UEFI.
In particular, i suspect that *after* the bootloader has turned over
control to the kernel (memtest in this case), the PXE-driven NIC is
continuing to DMA received packets into active RAM.
This seems pretty dangerous!
Would using pxe_unload before the close of the stanza prevent this
situation from happening (i regret i haven't been able to test it myself
because i haven't had access to the failing hardware since i completed
this diagnosis)? If so, it seems like that should be clearly documented
and strongly recommended in grub.texi.
Or, should grub be marking certain sections of memory as unavailable
somehow before handoff to the kernel?
Or is there some other way to avoid this sort of corruption?
I've seen similar failures now on pretty different hardware (a fairly
old Dell Optiplex GX260 SFF and a new Lenovo ThinkCentre M77).
Any ideas?
--dkg
[0] https://www.gnu.org/software/grub/manual/grub.html#Network
[1] http://www.memtest.org/
[2] http://mjg59.dreamwidth.org/11235.html
pgpfAXFZqs91T.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
what is the install_device argument for grub-mknetdir
according to the man page and grub-mknetdir --help, the usage is: grub-mknetdir [OPTION] install_device But it's not clear what the install_device should refer to, since you're really just preparing a directory -- there's no device needed, afaict. Can someone explain the need for this argument more clearly? Or give an example of what should go there? Thanks, --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub RAID heuristics (how can we avoid superfluous RAID member (2 found))
On Sat, 25 Feb 2012 16:49:00 -0500, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On Thu, 23 Feb 2012 06:43:23 +0100, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: [dkg wrote:] Select the smallest known block device that can completely enclose the RAID member. The larger block device(s) should not be considered to be exporting that RAID. I just built the latest (r4008) bzr head, which i believe includes the proposed changes, and installed it on a machine with two disks in RAID1: 0 root@trash:/home/dkg/src/grub/grub# cat /proc/partitions major minor #blocks name 80 19531250 sda 816266913 sda1 82 13256178 sda2 8 16 13260240 sdb 8 17 13258192 sdb1 90 13256064 md0 25303145728 dm-0 0 root@trash:/home/dkg/src/grub/grub# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[0] sda2[1] 13256064 blocks [2/2] [UU] unused devices: none 0 root@trash:/home/dkg/src/grub/grub# pvs PV VGFmt Attr PSize PFree /dev/md0 vg_trash0 lvm2 a-- 12.64g 9.64g 0 root@trash:/home/dkg/src/grub/grub# vgs VG#PV #LV #SN Attr VSize VFree vg_trash0 1 1 0 wz--n- 12.64g 9.64g 0 root@trash:/home/dkg/src/grub/grub# lvs LV VGAttr LSize Origin Snap% Move Log Copy% Convert root vg_trash0 -wi-ao 3.00g 0 root@trash:/home/dkg/src/grub/grub# it boots correctly on this setup, yay! booting to the grub command line, however, i do see some weirdness: grub ls (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (lvm/vg_trash0-root) grub insmod mdraid09 grub ls (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) (md/md0,msdos2) (md/md0,msdos1) (lvm/vg_trash0-root) grub rmmod mdraid09 grub ls (md/md0) (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) grub insmod mdraid09 grub ls (md/md0) (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) --dkg pgp7TMzghOykF.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub RAID heuristics (how can we avoid superfluous RAID member (2 found))
On Thu, 23 Feb 2012 06:43:23 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
phco...@gmail.com wrote:
[dkg wrote:]
Select the smallest known block device that can completely enclose the
RAID member. The larger block device(s) should not be considered to be
exporting that RAID.
phcoder pointed me to the attached patch for improved heuristics for
this case, which applies cleanly to the current head of bzr. Applied,
it removes the spurious error messages from grub-probe, as seen here
compared against debian's grub-probe 1.99-14:
0 root@trash:/home/dkg/src/grub/grub# grub-probe --target=device /
error: found two disks with the index 1 for RAID md0.
error: superfluous RAID member (2 found).
/dev/mapper/vg_trash0-root
0 root@trash:/home/dkg/src/grub/grub# ./grub-probe --target=device /
/dev/mapper/vg_trash0-root
0 root@trash:/home/dkg/src/grub/grub#
I think it's worth applying.
Thanks for your work on this, phcoder!
--dkg
=== modified file 'grub-core/disk/diskfilter.c'
--- grub-core/disk/diskfilter.c 2012-02-12 14:25:25 +
+++ grub-core/disk/diskfilter.c 2012-02-24 21:06:10 +
@@ -974,33 +974,33 @@
struct grub_diskfilter_lv *lv;
/* FIXME: Check whether the update time of the superblocks are
the same. */
+ if (pv-disk grub_disk_get_size (disk) = pv-part_size)
+ return GRUB_ERR_NONE;
+ pv-disk = grub_disk_open (disk-name);
+ if (!pv-disk)
+ return grub_errno;
/* This could happen to LVM on RAID, pv-disk points to the
raid device, we shouldn't change it. */
- if (! pv-disk)
- {
- pv-disk = grub_disk_open (disk-name);
- if (! pv-disk)
- return grub_errno;
- pv-part_start = grub_partition_get_start (disk-partition);
- pv-part_size = grub_disk_get_size (disk);
+ pv-start_sector -= pv-part_start;
+ pv-part_start = grub_partition_get_start (disk-partition);
+ pv-part_size = grub_disk_get_size (disk);
#ifdef GRUB_UTIL
- {
- grub_size_t s = 1;
- grub_partition_t p;
- for (p = disk-partition; p; p = p-parent)
- s++;
- pv-partmaps = xmalloc (s * sizeof (pv-partmaps[0]));
- s = 0;
- for (p = disk-partition; p; p = p-parent)
- pv-partmaps[s++] = xstrdup (p-partmap-name);
- pv-partmaps[s++] = 0;
- }
+ {
+ grub_size_t s = 1;
+ grub_partition_t p;
+ for (p = disk-partition; p; p = p-parent)
+ s++;
+ pv-partmaps = xmalloc (s * sizeof (pv-partmaps[0]));
+ s = 0;
+ for (p = disk-partition; p; p = p-parent)
+ pv-partmaps[s++] = xstrdup (p-partmap-name);
+ pv-partmaps[s++] = 0;
+ }
#endif
- if (start_sector != (grub_uint64_t)-1)
- pv-start_sector = start_sector;
- pv-start_sector += pv-part_start;
- }
+ if (start_sector != (grub_uint64_t)-1)
+ pv-start_sector = start_sector;
+ pv-start_sector += pv-part_start;
/* Add the device to the array. */
for (lv = array-lvs; lv; lv = lv-next)
if (!lv-became_readable_at lv-fullname is_lv_readable (lv))
=== modified file 'grub-core/disk/mdraid_linux.c'
--- grub-core/disk/mdraid_linux.c 2012-01-29 13:28:01 +
+++ grub-core/disk/mdraid_linux.c 2012-02-24 21:11:29 +
@@ -201,6 +201,11 @@
return NULL;
}
+ /* No need for explicit check that sb.size is 0 (unspecified) since
+ 0 = non-0 is false. */
+ if (((grub_disk_addr_t) grub_le_to_cpu32 (sb.size)) * 2 = size)
+return NULL;
+
/* FIXME: Check the checksum. */
level = grub_le_to_cpu32 (sb.level);
@@ -241,7 +246,8 @@
grub_snprintf (buf, sizeof (buf), md%d, grub_le_to_cpu32 (sb.md_minor));
return grub_diskfilter_make_raid (16, (char *) uuid,
grub_le_to_cpu32 (sb.raid_disks), buf,
-(sb.size) ? grub_le_to_cpu32 (sb.size) * 2
+(sb.size) ? ((grub_disk_addr_t)
+ grub_le_to_cpu32 (sb.size)) * 2
: sector,
grub_le_to_cpu32 (sb.chunk_size) 9,
grub_le_to_cpu32 (sb.layout),
pgp5yVvBiCXiu.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub RAID heuristics (how can we avoid superfluous RAID member (2 found))
On Thu, 23 Feb 2012 06:43:23 +0100, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: Try attached patch hrm, i get a segmentation fault from grub-probe / even without this patch when building from bzr trunk (r3964, i think). The test machine i've set up looks like this uses a common layering scheme: disk → partition → mdadm (0.90 superblock) → lvm → filesystem Here are the details and a backtrace of me trying: 0 root@trash:~# parted /dev/sda unit s print Model: ATA WDC WD200BB-75DE (scsi) Disk /dev/sda: 39062500s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start EndSize Type File system Flags 1 8192s 12542018s 12533827s primary 2 12550144s 39062499s 26512356s primary 0 root@trash:~# parted /dev/sdb unit s print Model: ATA QUANTUM FIREBALL (scsi) Disk /dev/sdb: 26520480s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start EndSize Type File system Flags 1 4096s 26520479s 26516384s primary 0 root@trash:~# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[0] sda2[1] 13256064 blocks [2/2] [UU] unused devices: none 0 root@trash:~# pvs PV VGFmt Attr PSize PFree /dev/md0 vg_trash0 lvm2 a-- 12.64g 9.64g 0 root@trash:~# vgs VG#PV #LV #SN Attr VSize VFree vg_trash0 1 1 0 wz--n- 12.64g 9.64g 0 root@trash:~# lvs LV VGAttr LSize Origin Snap% Move Log Copy% Convert root vg_trash0 -wi-ao 3.00g 0 root@trash:~# grep ' / ' /proc/mounts rootfs / rootfs rw 0 0 /dev/mapper/vg_trash0-root / ext3 rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0 0 root@trash:~# cd - /home/dkg/src/grub/grub 0 root@trash:/home/dkg/src/grub/grub# gdb ./grub-probe GNU gdb (GDB) 7.4-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/dkg/src/grub/grub/grub-probe...(no debugging symbols found)...done. (gdb) run -v / Starting program: /home/dkg/src/grub/grub/grub-probe -v / [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/libthread_db.so.1. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to /dev/mapper. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to /dev. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to md. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to dri. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to snd. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-path. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to cpu. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to vg_trash0. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to /dev. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to md. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to dri. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to snd. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-path. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to cpu. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to vg_trash0. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to disk. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-uuid. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-path. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-id. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to block. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to /dev. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to md. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to dri. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to snd. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-path. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to cpu. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to vg_trash0. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to disk. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-uuid. /home/dkg/src/grub/grub/grub-probe: info: changing current directory to by-path.
failed to build bzr head on powerpc (ieee1275)
In trying to test phcoder's patch for http://bugs.debian.org/611588 , i pulled the bzr head and built it (using --disable-werror to work around several remaining warnings about loop unrolling). I'm running into a failure with the translations, i think: 0 dkg@hollywood:~/src/grub/grub$ bzr info Standalone tree (format: 2a) Location: branch root: . Related branches: parent branch: http://bzr.savannah.gnu.org/r/grub/trunk/grub/ 0 dkg@hollywood:~/src/grub/grub$ ./autoreconf [...] 0 dkg@hollywood:~/src/grub/grub$ ./configure --enable-grub-mkfont --with-platform=ieee1275 --disable-werror [...] 0 dkg@hollywood:~/src/grub/grub$ make [...] Making all in po make[2]: Entering directory `/home/dkg/src/grub/grub/po' make grub.pot-update make[3]: Entering directory `/home/dkg/src/grub/grub/po' make[3]: *** No rule to make target `.././grub-core/kern/emu/console.c', needed by `grub.pot-update'. Stop. make[3]: Leaving directory `/home/dkg/src/grub/grub/po' make[2]: *** [grub.pot] Error 2 make[2]: Leaving directory `/home/dkg/src/grub/grub/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dkg/src/grub/grub' make: *** [all] Error 2 2 dkg@hollywood:~/src/grub/grub$ find . -name console.c ./grub-core/term/ieee1275/console.c ./grub-core/term/efi/console.c ./grub-core/term/i386/pc/console.c ./grub-core/term/arc/console.c ./grub-core/term/emu/console.c 0 dkg@hollywood:~/src/grub/grub$ Let me know if i can provide more useful information. --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
cruft left over from make uninstall [was: failed to build bzr head on powerpc (ieee1275)]
On 02/21/2012 09:30 PM, Mike Gilbert wrote: I ran into that myself this weekend. Solution: regenerate POTFILES.in. find . -name '*.c' -print | sort po/POTFILES.in Thanks, that did indeed let the build complete. i completed building it as a non-privileged user, and then as the superuser, i did: make install make uninstall That appears to have left a few files in /usr/local that i think it shouldn't have. I think the uninstall target might have drifted a bit: 0 root@hollywood:/home/dkg/src/grub/grub# find /usr/local/ | grep grub /usr/local/lib/grub /usr/local/lib/grub/powerpc-ieee1275 /usr/local/etc/grub.d /usr/local/share/grub /usr/local/share/grub/widthspec.h /usr/local/share/grub/ascii.pf2 /usr/local/share/grub/unicode.pf2 /usr/local/share/grub/euro.pf2 /usr/local/share/grub/ascii.h 0 root@hollywood:/home/dkg/src/grub/grub# --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: cruft left over from make uninstall [was: failed to build bzr head on powerpc (ieee1275)]
On 02/21/2012 10:23 PM, Mike Gilbert wrote: On Tue, Feb 21, 2012 at 10:01 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: make install make uninstall That appears to have left a few files in /usr/local that i think it shouldn't have. This is why I use my package manger (portage) to install *everything*. I also use my package manager (dpkg and apt) to install everything during normal use; however, phcoder wanted me to try some changes against trunk and my distro's packaging (debian) isn't tracking trunk directly. Even if debian was tracking GRUB's trunk directly, when upstream asks me to test against trunk, i try to test against vanilla trunk (without any distro patches) so i can rule out the distro as the source of any divergent expectations. Anyway, make uninstall should behave better than it did here, i think. --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: setting the system clock before launching operating system
On Sat 2008-09-13 00:52:47 -0400, Arthur Marsh wrote: Vesa Jääskeläinen wrote, on 2008-09-13 00:13: Geoff Karl wrote: I would like to be able to set the clock to a particular time automatically before launching an operating system. Anyone have any ideas if this can be done during the boot loader process? Yes it can be done. But why? Some machines (e.g. a Compaq Armada 1750) don't have the option to set the time via BIOS or set-up boot floppy. When the time had been lost, I'd have start-up problems with fsck checking when the file system had last been checked. The same is true for many older PowerPC machines whose mainboard batteries have begun to fail. Being able to automate the bootloader to say look, if the hardware clock thinks it is 1904 (or 1900, or 1970, or anytime before the turn of the century) it is probably wrong; set it to at least 2008 at every boot would be pretty useful. This is especially useful on 32-bit architectures with a default hardware epoch date so far in the past that crappier NTP implementations think that it's actually in the future. I've dealt with this at the OS level (for various OSes) on older PowerPC machines, and it's doable, but a pain. Being able to guarantee that no matter what OS you're booting, the initial clock will be at least set to time X would be pretty handy. --dkg pgpccKABlEKe4.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub-ieee1275 on powerpc says DEFAULT CATCH! and then drops me into Open Firmware
Hey folks-- I'm trying to create a grub-based rescue USB stick for PowerPC machines. I've successfully gotten one machine to boot to this device, and grub can see both the USB disk itself and the onboard (ide) HD. However, when i try to load a linux kernel from either disk, i get an error: grub linux (hd)/boot/vmlinux-2.6.25-2-powerpc DEFAULT CATCH!, code=300 at %SRR0: 00013ae4 %SRR1: 3030 (this is from my scribbled notes, not from a serial console, unfortunately). at this point, i get dropped to openfirmware, but it's in a sufficiently weird state that even mac-boot doesn't work for me. If i reboot the machine, i can boot normally (via ofboot/yaboot combination off of onboard disk). This is with 1.96+20080724-5 and the kernel from debian lenny. The machine in question is an old iBook (clamshell model) with 96M of RAM, described by lshw as: product: iBook (first generation) vendor: Copyright 1983-1999 Apple Computer, Inc. All Rights Reserved Any thoughts about what i might need to do to get grub to boot a linux kernel properly? Should i try to load something different from grub? Regards, --dkg 0 clam:~# cat /proc/cpuinfo processor : 0 cpu : 740/750 temperature : 54-56 C (uncalibrated) clock : 299.97MHz revision: 131.0 (pvr 0008 8300) bogomips: 33.15 timebase: 16644650 platform: PowerMac machine : PowerBook2,1 motherboard : PowerBook2,1 MacRISC Power Macintosh detected as : 64 (iBook (first generation)) pmac flags : 000d L2 cache: 512K unified pmac-generation : NewWorld 0 clam:~# pgplKMnFMKBtD.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pxebooting with GRUB 2
On Sat 2007-11-10 12:25:10 -0500, Marco Gerards wrote: It will be committed soon, now for real ;-) Thanks for the followup. i await with bated breath; netboot is an important feature for me! Let me know if there's a patchset i can test at some point as an end user. Sorry i don't have the skills/time/knowledge to contribute code in this case. Regards, --dkg pgpJZzsL4F9IS.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pxebooting with GRUB 2
On Sun 2007-09-30 12:07:38 -0400, Robert Millan wrote: WIP. Check latest mails from Marco on the subject. He sent patches implementing ethernet infrastructure and requested feedback. Ah, thanks. Are you referring to this, from two months ago? http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00011.html I couldn't find a more recent e-mail. And though the message suggests that the patchset will be in CVS within a week (i.e. mid-August), it doesn't look merged to me. i'm looking at CVS HEAD, though -- is there another branch i should be trying? I'm not sure what feedback i can give as i'm not a grub developer, and there doesn't appear to be enough in the patch (e.g. no IPv4 support) to make it something i can test as an end user. Marco, can you give another status report on netbooting? Thanks for the followup, --dkg pgpSn1eqUWMEb.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pxebooting with GRUB 2
On Mon 2007-09-24 20:49:55 -0400, Gregg C Levine wrote: To be honest I wasn't aware that anyone did do all of that. According to the other list members they want to accommodate the abillities of GRUB2 to be able to boot an operating system on other platforms, and then the concepts of network booting which was accomplished on the original GRUB-Legacy system. ah, i hadn't realized it was that low of a priority. thanks for the information. Is there a reason why you've not tried a network boot using GRUB-Legacy? Or are you not working on an X86 based platform? Perhaps i've been confused by the idea of what grub legacy means. Yes, i've tried and succeeded at pxebooting with a patched version of GRUB-legacy [0], but i thought i understood that new features/patches weren't being accepted into GRUB Legacy. In particular, i was hoping to see a pxe-capable grub or grub2 packaged cleanly for my distro of choice (debian), but interpreted a comment by Robert Millan [1] to imply that GRUB2 netbooting or PXEbooting was superior and better-supported in GRUB2. I probably didn't understand the context of his remarks well. I suppose i should go back to pushing for in-distro GRUB-Legacy PXE-booting support, if it's not a priority for GRUB2. I definitely like the idea of GRUB working on other platforms too, and i don't want to distract from that goal. Thanks for the help, the information, and the software. Regards, --dkg [0] http://os.inf.tu-dresden.de/~adam/grub/0.97/ [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217048#46 pgpr3tzmnksyt.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
pxebooting with GRUB 2
Hi folks-- I've searched high and low for documentation about how to get PXE booting working with GRUB 2, but i haven't had much luck. Can anyone give me pointers? What i've done so far - I found a brief mention on the wiki [0] and followed those instructions: cat pxeboot.img core.img pxegrub does create a PXE-bootable grub image, but once the image is loaded, GRUB 2 doesn't seem to be capable of downloading other files over the network (this includes being unable to download its own config file). I get dropped into a rescue GRUB shell, which appears to be only useful for pulling files off of a local disk -- but that sort of defeats the purpose. Here's what i see on the screen after the pxe boot: Welcome to GRUB! Entering into rescue mode... grub rescue looking at the logs of my TFTP and DHCP servers, i see the initial (boot ROM-generated) PXE interaction of a DHCPDISCOVER/OFFER/REQUEST/ACK handshake, and the initial TFTP download of the pxegrub file itself, and then nothing. What else do i need to to enable pulling files via TFTP? i've successfully pulled files off a TFTP server with a patched GRUB Legacy [1], but i'd like to support and use GRUB 2 if possible. Details --- FWIW, the above attempt was done using a Via Rhine NIC with functional PXE boot ROM. the version of GRUB 2 that i tried is the one in debian unstable at the moment (1.95+20070828-2), and i was using the core.img generated on this same debian unstable system that initially boots from a local disk. Maybe i need to regenerate a different core.img somehow? Final Questions --- Is there documentation somewhere that i missed? I'd love to get a pointer or two if it's out there. I'm also happy to help debug this, and to write up my notes on the wiki, if folks think that'd be useful. What next steps should i take to get network booting working? Do you have any advice? Thanks for making this useful tool, and for making it free. Regards, --dkg [0] http://grub.enbug.org/TestingOnX86#head-27ab6e1ddfd82d0c72737201a4e17e3a91ea1a24 [1] http://os.inf.tu-dresden.de/~adam/grub/0.97/pxegrub-0.97-os.3.gz ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
