Re: Can't find a solution to a failed secure boot kernel loading
That was it, I created a new without that EKU and everything works! Thank you very much, this was not easy to find, unfortunately :( Esp. when some official pages like here https://ubuntu.com/blog/how-to-sign-things-for-secure-boot still list it as a needed EKU. On Tue, May 10, 2022 at 4:59 PM Łukasz Piątkowski wrote: > Huh, I've never seen that before... thanks, I'm gonna give it a try and > report back! > > On Tue, May 10, 2022 at 4:44 PM Dimitri John Ledkov < > dimitri.led...@canonical.com> wrote: > >> On Tue, 10 May 2022 at 15:07, Łukasz Piątkowski >> wrote: >> > >> > What I'm trying to do is to sign a mainline kernel built by ubuntu ( >> https://kernel.ubuntu.com/~kernel-ppa/mainline/) with my private key, >> that is already enrolled to MOK, and boot it with Secure Boot. >> > >> > > the MOK key as generated by Ubuntu/Debian tooling, creates a signing >> certificate that self-limits itself to only support Kernel Module signing. >> > >> > OK, that explains why the key in `/var/lib/shim-signed/mok` doesn't >> work. Still, I have created my own key as well (listed below for >> inspection, it has code signing extension), enrolled that key in MOK and >> signed the ubuntu mainline kernel (the kernel I'm trying to boot) with it. >> The result is exactly the same. I was using exactly the same procedure a >> few ubuntu editions back and it was definitely working. From what I learned >> so far, this might be related to the BootHole bug ( >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713) that was >> fixed some time ago. >> > >> > My generated key is: >> > >> > root@T495:~/mok# openssl x509 -in MOK.pem -text -noout >> > Certificate: >> > Data: >> > Version: 3 (0x2) >> > Serial Number: >> > 42:61:86:b2:29:3d:ca:eb:98:87:ae:3d:74:95:c7:f2:63:8f:8a:3b >> > Signature Algorithm: sha256WithRSAEncryption >> > Issuer: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure >> Boot Signing, emailAddress = exam...@example.com >> > Validity >> > Not Before: Feb 18 19:28:16 2020 GMT >> > Not After : Jan 25 19:28:16 2120 GMT >> > Subject: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure >> Boot Signing, emailAddress = exam...@example.com >> > Subject Public Key Info: >> > Public Key Algorithm: rsaEncryption >> > Public-Key: (2048 bit) >> > Modulus: [cut] >> > Exponent: 65537 (0x10001) >> > X509v3 extensions: >> > X509v3 Subject Key Identifier: >> > >> EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6 >> > X509v3 Authority Key Identifier: >> > >> EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6 >> > X509v3 Basic Constraints: critical >> > CA:FALSE >> > X509v3 Extended Key Usage: >> > Code Signing, 1.3.6.1.4.1.311.10.3.6, >> 1.3.6.1.4.1.2312.16.1.2 >> >> This is bad... certs that have 1.3.6.1.4.1.2312.16.1.2 cannot be used >> to sign kernels. >> >> Your cert must _not_ have 1.3.6.1.4.1.2312.16.1.2 EKU set on it. >> >> You cannot use the same certificate to sign both kernel and modules. >> >> > Netscape Comment: >> > OpenSSL Generated Certificate >> > Signature Algorithm: sha256WithRSAEncryption >> > Signature Value: [cut] >> > >> > On Tue, May 10, 2022 at 3:26 PM Dimitri John Ledkov < >> dimitri.led...@canonical.com> wrote: >> >> >> >> the MOK key as generated by Ubuntu/Debian tooling, creates a signing >> >> certificate that self-limits itself to only support Kernel Module >> >> signing. >> >> Signatures made by such certificate, are not trusted by shim for the >> >> purpose of code signing of bootloaders (i.e. grub) or kernels (i.e. >> >> linux). >> >> I also responded this on stackoverflow. >> >> >> >> The automatically generated MOK key is only usable to sign kernel >> >> modules, i.e. self-built DKMS modules. >> >> >> >> -- >> >> okurrr, >> >> >> >> Dimitri >> >> >> >> On Tue, 10 May 2022 at 11:33, Łukasz Piątkowski >> wrote: >> >> > >> >> > Hi everyone - I'm new here! >> >> > >> >> > Sorry for going with my problem directly to the grub-devel maling >> list, but I'm pretty sure my problem is GRUB related. Still, I've spent >> some hours trying to find a solution on the Internet and I failed :( So, >> here it comes - if anyone has time to explain my problem to a layman, it >> would be awesome. Even better, if you can maybe answer here on >> stackoverflow, where it can be easier to find, I believe ( >> https://unix.stackexchange.com/questions/701612/cant-load-self-signed-kernel-with-secure-boot-on-bad-shim-signature >> ). >> >> > >> >> > I'm running ubuntu with Secure Boot on. Everything works fine when I >> use a kernel that comes packaged from cannonical. Still, I have issues >> running a self-signed kernel (this is actually an externally built kernel, >> that I have verified and want to use for my ow
Re: Can't find a solution to a failed secure boot kernel loading
On Wed, 11 May 2022 at 11:14, Łukasz Piątkowski wrote: > > That was it, I created a new without that EKU and everything works! Thank you > very much, this was not easy to find, unfortunately :( Esp. when some > official pages like here > https://ubuntu.com/blog/how-to-sign-things-for-secure-boot still list it as a > needed EKU. > Indeed in that blog post's section "What about kernels and bootloaders?" is out of date, not only one needs DER cert, one needs a cert without modules EKU set =/ I opened https://github.com/canonical-web-and-design/ubuntu.com/issues/11595 to see if it can be corrected. https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/ImageSigning Is the authoritative documentation (and sibling pages) that we do maintain and keep accurate. They look correct to me. > On Tue, May 10, 2022 at 4:59 PM Łukasz Piątkowski wrote: >> >> Huh, I've never seen that before... thanks, I'm gonna give it a try and >> report back! >> >> On Tue, May 10, 2022 at 4:44 PM Dimitri John Ledkov >> wrote: >>> >>> On Tue, 10 May 2022 at 15:07, Łukasz Piątkowski wrote: >>> > >>> > What I'm trying to do is to sign a mainline kernel built by ubuntu >>> > (https://kernel.ubuntu.com/~kernel-ppa/mainline/) with my private key, >>> > that is already enrolled to MOK, and boot it with Secure Boot. >>> > >>> > > the MOK key as generated by Ubuntu/Debian tooling, creates a signing >>> > > certificate that self-limits itself to only support Kernel Module >>> > > signing. >>> > >>> > OK, that explains why the key in `/var/lib/shim-signed/mok` doesn't work. >>> > Still, I have created my own key as well (listed below for inspection, it >>> > has code signing extension), enrolled that key in MOK and signed the >>> > ubuntu mainline kernel (the kernel I'm trying to boot) with it. The >>> > result is exactly the same. I was using exactly the same procedure a few >>> > ubuntu editions back and it was definitely working. From what I learned >>> > so far, this might be related to the BootHole bug >>> > (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713) that was >>> > fixed some time ago. >>> > >>> > My generated key is: >>> > >>> > root@T495:~/mok# openssl x509 -in MOK.pem -text -noout >>> > Certificate: >>> > Data: >>> > Version: 3 (0x2) >>> > Serial Number: >>> > 42:61:86:b2:29:3d:ca:eb:98:87:ae:3d:74:95:c7:f2:63:8f:8a:3b >>> > Signature Algorithm: sha256WithRSAEncryption >>> > Issuer: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure >>> > Boot Signing, emailAddress = exam...@example.com >>> > Validity >>> > Not Before: Feb 18 19:28:16 2020 GMT >>> > Not After : Jan 25 19:28:16 2120 GMT >>> > Subject: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure >>> > Boot Signing, emailAddress = exam...@example.com >>> > Subject Public Key Info: >>> > Public Key Algorithm: rsaEncryption >>> > Public-Key: (2048 bit) >>> > Modulus: [cut] >>> > Exponent: 65537 (0x10001) >>> > X509v3 extensions: >>> > X509v3 Subject Key Identifier: >>> > >>> > EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6 >>> > X509v3 Authority Key Identifier: >>> > >>> > EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6 >>> > X509v3 Basic Constraints: critical >>> > CA:FALSE >>> > X509v3 Extended Key Usage: >>> > Code Signing, 1.3.6.1.4.1.311.10.3.6, >>> > 1.3.6.1.4.1.2312.16.1.2 >>> >>> This is bad... certs that have 1.3.6.1.4.1.2312.16.1.2 cannot be used >>> to sign kernels. >>> >>> Your cert must _not_ have 1.3.6.1.4.1.2312.16.1.2 EKU set on it. >>> >>> You cannot use the same certificate to sign both kernel and modules. >>> >>> > Netscape Comment: >>> > OpenSSL Generated Certificate >>> > Signature Algorithm: sha256WithRSAEncryption >>> > Signature Value: [cut] >>> > >>> > On Tue, May 10, 2022 at 3:26 PM Dimitri John Ledkov >>> > wrote: >>> >> >>> >> the MOK key as generated by Ubuntu/Debian tooling, creates a signing >>> >> certificate that self-limits itself to only support Kernel Module >>> >> signing. >>> >> Signatures made by such certificate, are not trusted by shim for the >>> >> purpose of code signing of bootloaders (i.e. grub) or kernels (i.e. >>> >> linux). >>> >> I also responded this on stackoverflow. >>> >> >>> >> The automatically generated MOK key is only usable to sign kernel >>> >> modules, i.e. self-built DKMS modules. >>> >> >>> >> -- >>> >> okurrr, >>> >> >>> >> Dimitri >>> >> >>> >> On Tue, 10 May 2022 at 11:33, Łukasz Piątkowski >>> >> wrote: >>> >> > >>> >> > Hi everyone - I'm new here! >>> >> > >>> >> > Sorry for going with my problem directly to the grub-devel maling >>> >> > list, but I'm pretty sure my problem is GRUB related. Still, I've >>> >> > spent some hour
multibooting Linux distros with UEFI Secure Boot
This seems related to thread: "How to boot Windows when Bitlocker enabled with key sealed in TPM External" https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html A given NVRAM entry points to a particular distro shim+GRUB, and it's not possible to use either chainloader or configfile to forward to another distro's GRUB. If GRUB wants to support the multiboot Linux case, it needs some way of discovering other distro's shim+GRUB comb in NVRAM and on the EFI system volume, to populate the GRUB menu. And then the user can select that distro in the GRUB menu, which causes GRUB to use --bootnext to do a one-time boot using that UEFI boot entry, thus loading that distro's signed shim+GRUB combo. Or, is this just not a priority for the foreseeable future, and users will have to use the UEFI firmware's built-in boot manager for this use case? Thanks, -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
multibooting Linux distros with UEFI Secure Boot
Hi, A given NVRAM entry points to a particular distro shim+GRUB, and it's not possible to use either chainloader or configfile to forward to another distro's GRUB. If GRUB wants to support the multiboot Linux case, it needs some way of discovering other distro's shim+GRUB comb in NVRAM and on the EFI system volume, to populate the GRUB menu. And then the user can select that distro in the GRUB menu, which causes GRUB to use --bootnext to do a one-time boot using that UEFI boot entry, thus loading that distro's signed shim+GRUB combo. Or, is this just not a priority for the foreseeable future, and users will have to use the UEFI firmware's built-in boot manager for this use case? This seems related to thread: "How to boot Windows when Bitlocker enabled with key sealed in TPM External" https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html Thanks, -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
a GRUB command to show the UEFI built-in boot manager
Hi, There's GRUB command "fwsetup" to bring the user from GRUB to the firmware's setup menu. Could there be a command that brings the user to the firmware's built-in boot manager? a.k.a. boot order, a.k.a. boot selection? I'm offhand not seeing a UEFI command to bring up this specific firmware menu though... Thanks, -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 0/1] plainmount: Support plain encryption mode.
On Tue, 10 May 2022 19:16:06 +
Maxim Fomin wrote:
> --- Original Message ---
> On Thursday, May 5th, 2022 at 6:09, Glenn Washburn
> wrote:
>
> > Hi Maxim,
> >
> > I just want to reiterate Daniel, for v3, please use --threaded when
> > using format-patch and send-email. It'll help reviewers see all the
> > emails in the patch series together.
>
> It is complicated for me because I write from email service which a) does not
> have simple
> SMTP connection and b) is blocked in my country (I access it through VPN). I
> think I need to
> change my email provider for git commit author to send patches (because grub
> does not accept
> patches when commit author email differs from email sender, right?). I will
> try to fix these
> problems in the next patch version.
Another option is to create a single patch, with no cover letter. You
can add extra information that would have gone in the cover letter in
the single patch after the first line containing only '---'. Of course,
this won't work with a multiple patch series, but this one should work.
> > On Sat, 02 Apr 2022 20:02:17 +
> > Maxim Fomin ma...@fomin.one wrote:
> > > +Setup access to encrypted in plain mode device. Password can be
> > > specified in
> > > +two ways: as a secret passphrase or as a byte array from keyfile or
> > > device
> > > +block with the option @option{-d}. Passphrase can be provided
> > > interactively
> > > +from console or with option @option{-p}. Keyfile/device block can be a
> > > regular
> > > +file or some partition/disk. The length of the key from keyfile/device
> > > block
> >
> >
> > I think instead of "device block" you mean "block device" here. I think
> > the above should be rewritten as:
> >
> > Setup access to encrypted in plain mode device. Password can be
> > specified in two ways: as a secret passphrase or as a byte array from
> > a keyfile with the option @option{-d}. Passphrase can be provided
> > interactively from console or with option @option{-p}. The keyfile
> > can be either a path to a regular file or a block device. The length
> > of the key from keyfile
>
> When I wrote 'device block' I meant to say 'piece' of 'block device' because
> writing just 'block device' could be wrongly intepreted that the whole
> partition
> acts as passphrase which is strange. I think specifying 'segment' in the
> sentence
> 'path to a regular file or a block device segment' will be more clear.
You could mention using blocklist syntax to use a specified range of
sectors. I think you should just get rid of the support for sending a
disk device as an argument. This can be supported just as well with the
blocklist syntax.
> > > +static const struct grub_arg_option options[] =
> > > + {
> > > + / TRANSLATORS: It's still restricted to this module only. */
> > > + {"hash", 'h', 0, N_("Password hash"), 0, ARG_TYPE_STRING},
> > > + {"cipher", 'c', 0, N_("Password cipher"), 0, ARG_TYPE_STRING},
> > > + {"offset", 'o', 0, N_("Device offset"), 0, ARG_TYPE_STRING},
> > > + {"disk-size", 'b', 0, N_("Device size"), 0, ARG_TYPE_STRING},
> >
> >
> > I'm failing to see why this option is needed. What's the reasoning
> > behind wanting this? Would it be sufficient to create a loopback device
> > of the required size using the blocklist syntax?
>
> Probably yes, I didn't think about loopback device. This option allows to
> set disk size explicitly when for some reason disk firmware reports wrong
> size to grub. If such feature can be provided with loopback device, than it
> can be removed from here. I will check this in the next version.
>
> > > + {"key-size", 's', 0, N_("Key size (in bits)"), 0, ARG_TYPE_INT},
> > > + {"sector-size", 'S', 0, N_("Device sector size"), 0, ARG_TYPE_INT},
> > > + {"password", 'p', 0, N_("Password (key)"), 0, ARG_TYPE_STRING},
> > > + {"keyfile", 'd', 0, N_("Keyfile/disk path"), 0, ARG_TYPE_STRING},
> > > + {"keyfile-offset", 'O', 0, N_("Keyfile offset."), 0, ARG_TYPE_STRING},
> > > + {0, 0, 0, 0, 0, 0}
> > > + };
> > > +
> > > +struct grub_plainmount_args
> > > +{
> > > + char *key_data, *cipher, *mode, *hash, *keyfile;
> > > + grub_size_t offset, size, key_size, sector_size, keyfile_offset;
> > > + grub_disk_t disk;
> > > +};
> > > +typedef struct grub_plainmount_args *grub_plainmount_args_t;
> >
> >
> > The reason that I created the cargs code in cryptomount was to not have
> > to change the backend function interfaces when new features were added.
> > I don't think this quite applies here, since there are not backends. I
> > don't really like that this struct is being used instead of decent
> > function signatures. I'm not adamantly opposed to using this struct,
> > but I would prefer that it not be used and only pass in needed data to
> > each function.
>
> Yes, initially I wrote the module as a backend to cryptomount.
> I will fix it in the next version.
>
> > > + return grub_error (GRUB_ERR_BAD_ARGUMENT,
> > > + N_("cannot set key from password. "
> > > + "Check keysize/has
Re: [PATCH] efi: Set text-mode console resolution to maximum supported
On Tue, 10 May 2022 13:57:08 +0200 Gerd Hoffmann wrote: > On Fri, May 06, 2022 at 07:59:15PM -0500, Glenn Washburn wrote: > > Hi Gerd, > > > > Thanks for taking a look at the patch. > > > > On Fri, 6 May 2022 12:39:52 +0200 > > Gerd Hoffmann wrote: > > > > > Hi, > > > > > > > On some buggy EFI firmwares, GRUB is started with the console resolution > > > > set to the maximum but the output console EFI object has the mode set as > > > > 0, which is the minimum supported mode of 80x25 characters. This causes > > > > strange behavior at the GRUB shell where output can fill the screen, but > > > > the prompt is at line 80 in the middle of the screen. > > > > > > This behavior might not be ideal, but it's clearly within the specs and > > > not buggy. What firmware do you talk about btw? > > > > I have only a cursory understanding of the spec and fairly new to EFI. > > Could you elaborate on which spec(s) and where this behavior is > > described? > > Well, 80x25 is the only text mode which must be supported by the > firmware. Supporting larger modes is optional. > > I think the firmware is also free to choose the default text mode, > and the implementations I've seen so far seem to be conservative > and use 80x25 or 80x50 by default even in case the screen is larger. That kind of surprises me. When in mode 80x25 or 80x50 is the display not at its native resolution? For instance, when I put mine into 80x25, the display is clearly not at its native resolution, and not even the full physical screen is used, unlike at native resolution. The display is in a box centered on the physical display and the character glyphs are much larger and visibly more pixelated. In your experience, are other firmwares at 80x25 using native resolution or like mine some lower resolution? My surprise is that firmware authors would want the default display to look like that (maybe they don't care because its not considered user-facing). Another interesting thing I just found out is that the text is displayed much faster in 80x25 mode. I have 4 available modes 80x25, 120x36, 128x40, and 240x80 (or there abouts, going off memory). To test the speed, I'm cating a largish file, and doing a wall clock time. It seems that speed scales proportionally to the mode area size, maybe quadratically. So the max mode is much longer than the min mode, like 5-6 times longer. This despite the min mode writing more lines because of line wrapping. When running with debug=all there are times I've had to just reboot. So it seems I can't have the best of both worlds, a large display and fast text output. > > Trying to make sense of your assertion, my inexperienced reading of > > some relevant (but perhaps not all relevant) portions of the spec lead > > me to conclude that this behavior may not violate the spec because the > > spec isn't very clear on this. For instance, looking at the UEFI 2.9 > > version of the spec in section 12.4 on page 454 in table 12-4 "EFI > > Cursor Location/Advance Rules" there is reference to "bottom of the > > display". What is the display? Does being in a particular "mode" of > > cols x rows dimensions encompass all the pixels of the physical screen? > > If it doesn't, is the display all the pixels or just the ones being > > used for the columns x rows character output of a particular mode? > > Typically text mode uses a windows centered on the GOP. That is at > least what standared edk2 is doing and also the behavior you can see > when using ovmf in qemu. I'm not sure I understand this. I assume by GOP you're referring to UEFI's Graphics Output Protocol. But we're not using that here. Unless you're saying that the GOP is used internally by the firmware for some text modes. > > To be more verbose as to the issue I'm seeing, the computer boots to > > GRUB with the display resolution at native, 1920x1080, but only uses > > what appears to be the top left 800x600 pixels for the 80x25 text mode > > _initially_. So running "lsmod", for instance, uses the full height of > > the screen when outputing text and the screen starts scrolling at the > > bottom of the screen. But when it finished the GRUB shell prompt is > > about midway down from the top and typing overwrites some of lsmod > > output. > > That sounds buggy indeed. I've never seen such behavior on a graphical > screen. It sounds like the behavior I see when using efi shell on a > serial console with the xterm having more lines than efi text mode. Yes, I can imagine that being similar. I wonder if this can be detected by setting the cursor position to the last row and first column, calling OutputString() with the string "\n", then checking the current cursor position in mode to see if its greater than the max line number for this mode. If that works, keep writing "\n" until the current cursor line number stops changing, then search for a mode with that number of rows and set to that mode. I'm not sure I care to do the work of writing and testing that tho
[PATCH] net: Fix incorrect condition for calling grub_net_tcp_retransmit()
The commit 848724273e4 (net/net: Avoid unnecessary calls to grub_net_tcp_retransmit()) needs to have its condition inverted to avoid unnecessary calls to grub_net_tcp_retransmit(). As it is, it creates many unnecessary calls and does not call grub_net_tcp_retransmit() when needed. The call to grub_net_tcp_retransmit() should only be made when grub_net_cards does _not_ equal NULL, meaning that there are potentially network cards that need tcp retransmission. Signed-off-by: Glenn Washburn --- grub-core/net/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-core/net/net.c b/grub-core/net/net.c index 88ea49fee..2b6771523 100644 --- a/grub-core/net/net.c +++ b/grub-core/net/net.c @@ -1634,7 +1634,7 @@ grub_net_poll_cards_idle_real (void) || ctime >= card->last_poll + card->idle_poll_delay_ms) receive_packets (card, 0); } - if (grub_net_cards == NULL) + if (grub_net_cards != NULL) grub_net_tcp_retransmit (); } -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/7] docs: Fix spelling typo and remove unnecessary spaces
Signed-off-by: Glenn Washburn
---
docs/grub-dev.texi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi
index 617e155a0..47a8e3826 100644
--- a/docs/grub-dev.texi
+++ b/docs/grub-dev.texi
@@ -967,13 +967,13 @@ If it works next stage is to have heap, console and timer.
To have the heap working you need to determine which regions are suitable for
heap usage, allocate them from firmware and map (if applicable). Then call
-grub_mm_init_region (vois *start, grub_size_t s) for every of this region.
+grub_mm_init_region (void *start, grub_size_t s) for every of this region.
As a shortcut for early port you can allocate right after _end or have
a big static array for heap. If you do you'll probably need to come back to
this later. As for output console you should distinguish between an array of
text, terminfo or graphics-based console. Many of real-world examples don't
fit perfectly into any of these categories but one of the models is easier
-to be used as base. In second and third case you should add your platform to
+to be used as base. In second and third case you should add your platform to
terminfokernel respectively videoinkernel group. A good example of array of
text is i386-pc (kern/i386/pc/init.c and term/i386/pc/console.c).
Of terminfo is ieee1275 (kern/ieee1275/init.c and term/ieee1275/console.c).
@@ -1930,7 +1930,7 @@ use in GRUB at this time:
@item BDF
Inefficient storage; uses ASCII to describe properties and
hexadecimal numbers in ASCII for the bitmap rows.
-@item PCF
+@item PCF
Many format variations such as byte order and bitmap padding (rows
padded to byte, word, etc.) would result in more complex code to
handle the font format.
@@ -2051,8 +2051,8 @@ bit in the byte. For the sake of compact storage, rows
are not padded
to byte boundaries (i.e., a single byte may contain bits belonging to
multiple rows). The last byte of the bitmap @strong{is} padded with zero
bits in the bits positions to the right of the last used bit if the
-bitmap data does not fill the last byte.
-
+bitmap data does not fill the last byte.
+
The length of the @strong{bitmap data} field is (@var{width} * @var{height} +
7) / 8
using integer arithmetic, which is equivalent to ceil(@var{width} *
@var{height} / 8) using real number arithmetic.
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/7] Various docs improvements
The first 4 patches need no explanation. The 5th patch creates a new section just for loader commands and moves loader commands to that section from the general commands section. Patch #6 adds an itemized list of currently under-documented loader commands to the text part of the loader command section. And patch #7 adds a new section for undocumented commands and contains an itemized list of undocumented commands (now minimally documented!) These two lists of undocumented commands was partially generated by grepping for command registration in the source and pulling out the registered command name and help string. The hope is that these two lists will make it easier for non-programmers (or anyone) to contribute to GRUB by choosing a command to flesh out. Also, I wanted this list so that I have a way to quickly see all the available commands to choose potentially interesting ones for use. So far I've found some commands that I didn't know existed. I don't particularly like how patch #6 renders to html, with the justification of the two itemized lists (one of the undocumented loader commands and the other the documented loader commands) being different. I'm open to suggestiong on how this might be improved. Glenn Glenn Washburn (7): docs: Fix spelling typo and remove unnecessary spaces docs: Make note that sendkey is only available on i386-pc docs: Make note of i386-pc specific usage of halt command docs: Markup loader commands with @command tag docs: Create command section for loader commands docs: Add under documented loader commands to beginning of loader section docs: Add section for general undocumented commands docs/grub-dev.texi | 10 +- docs/grub.texi | 376 +++-- 2 files changed, 269 insertions(+), 117 deletions(-) -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/7] docs: Make note of i386-pc specific usage of halt command
The --no-apm option is only available on the i396-pc target.
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index c5310fdec..e003be7ca 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4567,10 +4567,10 @@ type are omitted, then the partition will be inactive.
@node halt
@subsection halt
-@deffn Command halt @option{--no-apm}
-The command halts the computer. If the @option{--no-apm} option
-is specified, no APM BIOS call is performed. Otherwise, the computer
-is shut down using APM.
+@deffn Command halt [@option{--no-apm}[
+The command halts the computer. On the i386-pc target, the @option{--no-apm}
+option, or short @option{-n}, is specified, no APM BIOS call is performed.
+Otherwise, the computer is shut down using APM on that target.
@end deffn
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 5/7] docs: Create command section for loader commands
Move loader commands documented in the general commands list into the
loader command section.
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 220 ++---
1 file changed, 116 insertions(+), 104 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index d96f08722..eea575e0c 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3830,6 +3830,7 @@ shell}.
@menu
* Menu-specific commands::
+* Loader commands::
* General commands::
* Command-line and menu entry commands::
* Networking commands::
@@ -3917,6 +3918,121 @@ All options are the same as in the @command{menuentry}
command
@end deffn
+@node Loader commands
+@section The list of various loader commands
+
+These commands are used to load necessary components to boot desired OS.
+
+@menu
+* chainloader:: Chain-load another boot loader
+* initrd:: Load a Linux initrd
+* initrd16::Load a Linux initrd (16-bit mode)
+* linux:: Load a Linux kernel
+* linux16:: Load a Linux kernel (16-bit mode)
+@comment * xen_*:: Xen boot commands for AArch64
+* xen_hypervisor:: Load xen hypervisor binary (only on AArch64)
+* xen_module:: Load xen modules for xen hypervisor (only on
AArch64)
+@end menu
+
+
+@node chainloader
+@subsection chainloader
+
+@deffn Command chainloader [@option{--force}] file
+Load @var{file} as a chain-loader. Like any other file loaded by the
+filesystem code, it can use the blocklist notation (@pxref{Block list
+syntax}) to grab the first sector of the current partition with @samp{+1}.
+If you specify the option @option{--force}, then load @var{file} forcibly,
+whether it has a correct signature or not. This is required when you want to
+load a defective boot loader, such as SCO UnixWare 7.1.
+@end deffn
+
+
+@node initrd
+@subsection initrd
+
+@deffn Command initrd file [file @dots{}]
+Load, in order, all initial ramdisks for a Linux kernel image, and set
+the appropriate parameters in the Linux setup area in memory. This may only
+be used after the @command{linux} command (@pxref{linux}) has been run. See
+also @ref{GNU/Linux}.
+@end deffn
+
+
+@node initrd16
+@subsection initrd16
+
+@deffn Command initrd16 file [file @dots{}]
+Load, in order, all initial ramdisks for a Linux kernel image to be booted in
+16-bit mode, and set the appropriate parameters in the Linux setup area in
+memory. This may only be used after the @command{linux16} command
+(@pxref{linux16}) has been run. See also @ref{GNU/Linux}.
+
+This command is only available on x86 systems.
+@end deffn
+
+
+@node linux
+@subsection linux
+
+@deffn Command linux file @dots{}
+Load a Linux kernel image from @var{file}. The rest of the line is passed
+verbatim as the @dfn{kernel command-line}. Any initrd must be reloaded
+after using this command (@pxref{initrd}).
+
+On x86 systems, the kernel will be booted using the 32-bit boot protocol.
+Note that this means that the @samp{vga=} boot option will not work; if you
+want to set a special video mode, you will need to use GRUB commands such as
+@samp{set gfxpayload=1024x768} or @samp{set gfxpayload=keep} (to keep the
+same mode as used in GRUB) instead. GRUB can automatically detect some uses
+of @samp{vga=} and translate them to appropriate settings of
+@samp{gfxpayload}. The @command{linux16} command (@pxref{linux16}) avoids
+this restriction.
+@end deffn
+
+
+@node linux16
+@subsection linux16
+
+@deffn Command linux16 file @dots{}
+Load a Linux kernel image from @var{file} in 16-bit mode. The rest of the
+line is passed verbatim as the @dfn{kernel command-line}. Any initrd must
+be reloaded after using this command (@pxref{initrd16}).
+
+The kernel will be booted using the traditional 16-bit boot protocol. As
+well as bypassing problems with @samp{vga=} described in @ref{linux}, this
+permits booting some other programs that implement the Linux boot protocol
+for the sake of convenience.
+
+This command is only available on x86 systems.
+@end deffn
+
+
+@node xen_hypervisor
+@subsection xen_hypervisor
+
+@deffn Command xen_hypervisor file [arguments] @dots{}
+Load a Xen hypervisor binary from @var{file}. The rest of the line is passed
+verbatim as the @dfn{kernel command-line}. Any other binaries must be
+reloaded after using this command.
+This command is only available on AArch64 systems.
+@end deffn
+
+
+@node xen_module
+@subsection xen_module
+
+@deffn Command xen_module [--nounzip] file [arguments]
+Load a module for xen hypervisor at the booting process of xen.
+The rest of the line is passed verbatim as the module command line.
+Modules should be loaded in the following order:
+ - dom0 kernel image
+ - dom0 ramdisk if present
+ - XSM policy if present
+This command is only available on AArch64 systems.
+@end deffn
+
+
@node General commands
@section The list of general commands
@@ -4034,7 +4150,6 @@ you forget
[PATCH 4/7] docs: Markup loader commands with @command tag
Also, add period to terminate sentence.
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index e003be7ca..d96f08722 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1005,13 +1005,14 @@ kopenbsd payload this is disabled by default.
Aditionally behaviour of
initial ramdisk depends on command line options. Several distributors provide
the image for this purpose or it's integrated in their standard ramdisk and
activated by special option. Consult your kernel and distribution manual for
-more details. Other loaders like appleloader, chainloader (BIOS, EFI,
coreboot),
-freedos, ntldr and plan9 provide no possibility of loading initial ramdisk and
+more details. Other loaders like @command{appleloader}, @command{chainloader}
+(BIOS, EFI, coreboot), @command{freedos}, @command{ntldr}, @command{plan9}
+and @command{truecrypt} provide no possibility of loading initial ramdisk and
as far as author is aware the payloads in question don't support either initial
ramdisk or discovering loopback boot in other way and as such not bootable this
way. Please consider alternative boot methods like copying all files
from the image to actual partition. Consult your OS documentation for
-more details
+more details.
@node LVM cache booting
@section Booting from LVM cache logical volume
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/7] docs: Make note that sendkey is only available on i386-pc
Signed-off-by: Glenn Washburn --- docs/grub.texi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/grub.texi b/docs/grub.texi index 11c66160e..c5310fdec 100644 --- a/docs/grub.texi +++ b/docs/grub.texi @@ -5103,7 +5103,9 @@ Insert keystrokes into the keyboard buffer when booting. Sometimes an operating system or chainloaded boot loader requires particular keys to be pressed: for example, one might need to press a particular key to enter "safe mode", or when chainloading another boot loader one might send -keystrokes to it to navigate its menu. +keystrokes to it to navigate its menu. + +Note: This command is currently only available on the i386-pc target. You may provide up to 16 keystrokes (the length of the BIOS keyboard buffer). Keystroke names may be upper-case or lower-case letters, digits, -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 6/7] docs: Add under documented loader commands to beginning of loader section
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 36
1 file changed, 36 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index eea575e0c..91512e317 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3922,6 +3922,42 @@ All options are the same as in the @command{menuentry}
command
@section The list of various loader commands
These commands are used to load necessary components to boot desired OS.
+Many of the loader commands are not sufficiently documented. The following is
+a list of commands that could use more documentation:
+
+@itemize @bullet
+@item @command{appleloader} - Boot BIOS-based system.
+@item @command{freedos} - Load FreeDOS kernel.sys.
+@item @command{kfreebsd_loadenv} - Load FreeBSD env.
+@item @command{kfreebsd_module_elf} - Load FreeBSD kernel module (ELF).
+@item @command{kfreebsd_module} - Load FreeBSD kernel module.
+@item @command{kfreebsd} - Load kernel of FreeBSD.
+@item @command{knetbsd_module_elf} - Load NetBSD kernel module (ELF).
+@item @command{knetbsd_module} - Load NetBSD kernel module.
+@item @command{knetbsd} - Load kernel of NetBSD.
+@item @command{kopenbsd} - Load kernel of OpenBSD.
+@item @command{kopenbsd_ramdisk} - Load kOpenBSD ramdisk.
+@item @command{legacy_initrd_nounzip} - Simulate grub-legacy `modulenounzip'
command
+@item @command{legacy_initrd} - Simulate grub-legacy `initrd' command
+@item @command{legacy_kernel} - Simulate grub-legacy `kernel' command
+@item @command{module2} - Load a multiboot 2 module.
+@item @command{module} - Load a multiboot module.
+@item @command{multiboot2} - Load a multiboot 2 kernel.
+@item @command{multiboot} - Load a multiboot kernel.
+@item @command{ntldr} - Load NTLDR or BootMGR.
+@item @command{plan9} - Load Plan9 kernel.
+@item @command{pxechainloader} - Load a PXE image.
+@item @command{truecrypt} - Load Truecrypt ISO.
+@item @command{xnu_kernel64} - Load 64-bit XNU image.
+@item @command{xnu_kernel} - Load XNU image.
+@item @command{xnu_kextdir} - Load XNU extension directory.
+@item @command{xnu_kext} - Load XNU extension.
+@item @command{xnu_mkext} - Load XNU extension package.
+@item @command{xnu_ramdisk} - Load XNU ramdisk. It will be available in OS as
md0.
+@item @command{xnu_resume} - Load an image of hibernated XNU.
+@item @command{xnu_splash} - Load a splash image for XNU.
+@end itemize
+
@menu
* chainloader:: Chain-load another boot loader
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 7/7] docs: Add section for general undocumented commands
The section is an itemized list of commands that are not listed else where
in the command sections.
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 101 +
1 file changed, 101 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index 91512e317..3b5522b0a 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3834,6 +3834,7 @@ shell}.
* General commands::
* Command-line and menu entry commands::
* Networking commands::
+* Undocumented commands::
@end menu
@@ -5818,6 +5819,106 @@ net_set_vlan efinet1 0
@end deffn
+@node Undocumented commands
+@section The list of commands currently undocumented
+Unfortunately, not all GRUB commands are documented at this time due to
+developer resource constraints. One way to contribute back to the GRUB
+project would be to help document these commands, and submit patches or
+ideas to the mailing list. The following is a (most likely incomplete)
+list of undocumented or poorly documented commands and not all of them
+are allowed for all platforms. Running the command help from within the
+GRUB shell may provide more information on parameters and usage.
+
+@itemize @bullet
+@item @command{all_functional_test} - Run all functional tests.
+@item @command{backtrace} - Print backtrace.
+@item @command{boottime} - Show boot time statistics.
+@item @command{cacheinfo} - Get disk cache info.
+@item @command{cbmemc} - Show CBMEM console content.
+@item @command{cmosset} - Set bit at BYTE:BIT in CMOS.
+@item @command{coreboot_boottime} - Show coreboot boot time statistics.
+@item @command{dump} - Show memory contents.
+@item @command{efiemu_loadcore} - Load and initialize EFI emulator.
+@item @command{efiemu_prepare} - Finalize loading of EFI emulator.
+@item @command{efiemu_unload} - Unload EFI emulator.
+@item @command{exit} - Exit from GRUB.
+@item @command{extract_entries_configfile} - Load another config file but take
only menu entries.
+@item @command{extract_entries_source} - Load another config file without
changing context but take only menu entries.
+@item @command{extract_legacy_entries_configfile} - Parse legacy config in new
context taking only menu entries
+@item @command{extract_legacy_entries_source} - Parse legacy config in same
context taking only menu entries
+@item @command{extract_syslinux_entries_configfile} - Execute syslinux config
in new context taking only menu entries
+@item @command{extract_syslinux_entries_source} - Execute syslinux config in
same context taking only menu entries
+@item @command{fakebios} - Create BIOS-like structures for backward
compatibility with existing OS.
+@item @command{file} - Check if FILE is of specified type.
+@item @command{fix_video} - Fix video problem.
+@item @command{fpswa} - Display FPSWA version.
+@item @command{functional_test} - Run all loaded functional tests.
+@item @command{fwsetup} - Reboot into firmware setup menu.
+@item @command{gdbstub_break} - Break into GDB
+@item @command{gdbstub} - Start GDB stub on given port
+@item @command{gdbstub_stop} - Stop GDB stub
+@item @command{hdparm} - Get/set ATA disk parameters.
+@item @command{hexdump} - Show raw contents of a file or memory.
+@item @command{hexdump_random} - Hexdump random data.
+@item @command{inb} - Read 8-bit value from PORT.
+@item @command{inl} - Read 32-bit value from PORT.
+@item @command{inw} - Read 16-bit value from PORT.
+@item @command{jpegtest} - Tests loading of JPEG bitmap.
+@item @command{keymap} - Load a keyboard layout.
+@item @command{legacy_check_password} - Simulate grub-legacy `password'
command in menu entry mode
+@item @command{legacy_configfile} - Parse legacy config in new context
+@item @command{legacy_password} - Simulate grub-legacy `password' command
+@item @command{legacy_source} - Parse legacy config in same context
+@item @command{loadbios} - Load BIOS dump.
+@item @command{lsacpi} - Show ACPI information.
+@item @command{lsapm} - Show APM information.
+@item @command{lscoreboot} - List coreboot tables.
+@item @command{lsdev} - List devices.
+@item @command{lsefi} - Display EFI handles.
+@item @command{lsefimmap} - Display EFI memory map.
+@item @command{lsefisystab} - Display EFI system tables.
+@item @command{lsmmap} - List memory map provided by firmware.
+@item @command{lspci} - List PCI devices.
+@item @command{lssal} - Display SAL system table.
+@item @command{lsspd} - Print Memory information.
+@item @command{macppcbless} - Bless DIR of HFS or HFS+ partition for PPC macs.
+@item @command{mactelbless} - Bless FILE of HFS or HFS+ partition for intel
macs.
+@item @command{net_set_vlan} - Set an interface's vlan id.
+@item @command{outb} - Write 8-bit VALUE to PORT.
+@item @command{outl} - Write 32-bit VALUE to PORT.
+@item @command{outw} - Write 16-bit VALUE to PORT.
+@item @command{pcidump} - Show raw dump of the PCI configuration space.
+@item @command{pngtest} - Tests loading of PNG bitmap.
+@item @command{read_byte} - Read 8-bit value f
[PATCH] efi: Add missing header from efi/console_control.h
Signed-off-by: Glenn Washburn
---
include/grub/efi/console_control.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/grub/efi/console_control.h
b/include/grub/efi/console_control.h
index 7c358fcdb..bb5fd038e 100644
--- a/include/grub/efi/console_control.h
+++ b/include/grub/efi/console_control.h
@@ -23,6 +23,8 @@
#ifndef GRUB_EFI_CONSOLE_CONTROL_HEADER
#define GRUB_EFI_CONSOLE_CONTROL_HEADER1
+#include
+
#define GRUB_EFI_CONSOLE_CONTROL_GUID \
{ 0xf42f7782, 0x12e, 0x4c12, \
{ 0x99, 0x56, 0x49, 0xf9, 0x43, 0x4, 0xf7, 0x21 } \
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/2] Add efitextmode command
This patch add the efitextmode command which is used for showing all available text output modes and setting a specific mode. Its basically the equivalent of the EFI Shell's "mode" command and its output looks similar. The main difference is that its shows the mode number in the listing and takes a mode number when setting the mode. As a convenience it can take arguments "min" or "max" to set to the minimum or maximum mode. Glenn Glenn Washburn (2): efi: Add efitextmode command for getting/setting the text mode resolution docs: Add documentation for the efitextmode command docs/grub.texi | 23 ++ grub-core/Makefile.core.def | 6 ++ grub-core/commands/efi/efitextmode.c | 118 +++ 3 files changed, 147 insertions(+) create mode 100644 grub-core/commands/efi/efitextmode.c -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/2] efi: Add efitextmode command for getting/setting the text mode resolution
This command is meant to behave similarly to the 'mode' command of the EFI
Shell application. One difference is that to set the mode the mode number
is given, not the rows and columns of the desired mode. Also supported are
the arguments "min" and "max", which set the mode to the minimum and
maximum mode respectively as calculated by the columns * rows of that mode.
Signed-off-by: Glenn Washburn
---
grub-core/Makefile.core.def | 6 ++
grub-core/commands/efi/efitextmode.c | 118 +++
2 files changed, 124 insertions(+)
create mode 100644 grub-core/commands/efi/efitextmode.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 726f51be7..b22e48f0f 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -813,6 +813,12 @@ module = {
enable = efi;
};
+module = {
+ name = efitextmode;
+ efi = commands/efi/efitextmode.c;
+ enable = efi;
+};
+
module = {
name = blocklist;
common = commands/blocklist.c;
diff --git a/grub-core/commands/efi/efitextmode.c
b/grub-core/commands/efi/efitextmode.c
new file mode 100644
index 0..fb72aa6f3
--- /dev/null
+++ b/grub-core/commands/efi/efitextmode.c
@@ -0,0 +1,118 @@
+/* efitextmode.c - command to get/set text mode resolution */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2003,2005,2006,2007,2009 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see
[PATCH 2/2] docs: Add documentation for the efitextmode command
Signed-off-by: Glenn Washburn
---
docs/grub.texi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index 3b5522b0a..50ef28edd 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4202,6 +4202,7 @@ you forget a command, you can run the command
@command{help}
* distrust::Remove a pubkey from trusted keys
* drivemap::Map a drive to another
* echo::Display a line of text
+* efitextmode:: Set/Get text output mode resolution
* eval::Evaluate agruments as GRUB commands
* export:: Export an environment variable
* false:: Do nothing, unsuccessfully
@@ -4638,6 +4639,28 @@ character will print that character.
@end deffn
+@node efitextmode
+@subsection efitextmode
+
+@deffn Command efitextmode [min | max | mode_num]
+When used with no arguments displays all available text output modes. The
+set mode determines the columns and rows of the text display when in
+text mode. An asterisk, @samp{*}, will be at the end of the line of the
+currently set mode.
+
+Otherwise the command only takes a single parameter, which can be
+@samp{min}, @samp{max}, or a mode number given by the listing when run
+with no arguments. These arguments set the mode to the minimum, maximum,
+and particular mode respectively.
+
+By default GRUB will start in whatever mode the EFI firmware defaults to.
+There are firmwares known to setup the default mode such that output
+behaves strangely. Setting the mode can fix this.
+
+Note: This command is only available on EFI platforms.
+@end deffn
+
+
@node eval
@subsection eval
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/4] tests: Show host determined fs UUID when hfs UUID test fails
On failure, the hfs test should show both the host and GRUB determined fs UUID. Prior to this change, both outputs where generated by GRUB, which is less helpful in determining the cause of failure. Signed-off-by: Glenn Washburn --- tests/util/grub-fs-tester.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in index 3c1d712de..d323665d2 100644 --- a/tests/util/grub-fs-tester.in +++ b/tests/util/grub-fs-tester.in @@ -1353,7 +1353,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do : else echo UUID FAIL - echo "$LSOUT" + echo "$FSUUID" echo "$GRUBUUID" for lodev in $LODEVICES; do blkid "$lodev" -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/4] tests: Add /sbin and /usr/sbin to path in partmap test
The partmap test requires no elevated privileges. However, it uses parted
which can be used as a normal user, but is usually located in /sbin or
/usr/bin (eg. on Debian systems). Whereas the normal user does not usually
have /sbin or /usr/sbin added to their path, thus parted will not be found
causing the test to abort. Add /sbin and /usr/sbin to the path for the
partmap test so that the test can run successfully as an unprivileged user.
Signed-off-by: Glenn Washburn
---
tests/partmap_test.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/partmap_test.in b/tests/partmap_test.in
index a73c473b0..4138e88fe 100644
--- a/tests/partmap_test.in
+++ b/tests/partmap_test.in
@@ -19,6 +19,8 @@ set -e
parted=parted
grubshell=@builddir@/grub-shell
+PATH="$PATH:/sbin:/usr/sbin"
+
. "@builddir@/grub-core/modinfo.sh"
create_disk_image () {
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/4] formatting: Remove whitespace between N_ macro and open parenthesis
Signed-off-by: Glenn Washburn
---
grub-core/commands/macbless.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/grub-core/commands/macbless.c b/grub-core/commands/macbless.c
index 85cefd0f7..3d761452a 100644
--- a/grub-core/commands/macbless.c
+++ b/grub-core/commands/macbless.c
@@ -220,12 +220,10 @@ GRUB_MOD_INIT(macbless)
{
cmd = grub_register_command ("mactelbless", grub_cmd_macbless,
N_("FILE"),
- N_
- ("Bless FILE of HFS or HFS+ partition for intel
macs."));
+ N_("Bless FILE of HFS or HFS+ partition for
intel macs."));
cmd_ppc =
grub_register_command ("macppcbless", grub_cmd_macbless, N_("DIR"),
- N_
- ("Bless DIR of HFS or HFS+ partition for PPC
macs."));
+ N_("Bless DIR of HFS or HFS+ partition for PPC
macs."));
}
GRUB_MOD_FINI(macbless)
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/4] Miscellaneous fixes/improvements
Patch #1: When the HFS UUID test fails it shows two GRUB generated outputs.
There should be one GRUB output and one host system output, like the other
filesystems output. In this case it should show the host generated HFS UUID
which is not matching with the GRUB generated one.
Patch #2: If tests are run as non-root user, /sbin and /usr/sbin are usually
not in the path, which will cause the partmap test to fail because it can
not find parted (in /usr/sbin on Debian). However, this test does not require
root privileges to run successfully, so add those paths to the PATH to allow
partmap to successfully run as a non-root user.
Patch #3: I believe the policy is that invocations of the N_ macro should
have no whitespace before the '('. This fixes that in a couple invocations.
Patch #4: The crypto and cryptodisk headers are not needed by the probe user
space utility (maybe they were at one time?). So remove them.
Glenn
Glenn Washburn (4):
tests: Show host determined fs UUID when hfs UUID test fails
tests: Add /sbin and /usr/sbin to path in partmap test
formatting: Remove whitespace between N_ macro and open parenthesis
util/probe.c: Remove unused header includes
grub-core/commands/macbless.c | 6 ++
tests/partmap_test.in | 2 ++
tests/util/grub-fs-tester.in | 2 +-
util/probe.c | 2 --
4 files changed, 5 insertions(+), 7 deletions(-)
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 4/4] util/probe.c: Remove unused header includes
Signed-off-by: Glenn Washburn --- util/probe.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/util/probe.c b/util/probe.c index 05a6d1462..81d91cf59 100644 --- a/util/probe.c +++ b/util/probe.c @@ -36,8 +36,6 @@ #include #include #include -#include -#include #include -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] docs: Add documentation for the efitextmode command
Dear Glenn,
Thank you for the patch. Two small nits.
Am 12.05.22 um 05:07 schrieb Glenn Washburn:
Signed-off-by: Glenn Washburn
*Add documentation for …* could be abbreviated to *Document …* in the
git commit message summary.
---
docs/grub.texi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index 3b5522b0a..50ef28edd 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4202,6 +4202,7 @@ you forget a command, you can run the command
@command{help}
* distrust::Remove a pubkey from trusted keys
* drivemap::Map a drive to another
* echo::Display a line of text
+* efitextmode:: Set/Get text output mode resolution
* eval::Evaluate agruments as GRUB commands
* export:: Export an environment variable
* false:: Do nothing, unsuccessfully
@@ -4638,6 +4639,28 @@ character will print that character.
@end deffn
+@node efitextmode
+@subsection efitextmode
+
+@deffn Command efitextmode [min | max | mode_num]
+When used with no arguments displays all available text output modes. The
+set mode determines the columns and rows of the text display when in
+text mode. An asterisk, @samp{*}, will be at the end of the line of the
+currently set mode.
+
+Otherwise the command only takes a single parameter, which can be
+@samp{min}, @samp{max}, or a mode number given by the listing when run
+with no arguments. These arguments set the mode to the minimum, maximum,
+and particular mode respectively.
+
+By default GRUB will start in whatever mode the EFI firmware defaults to.
+There are firmwares known to setup the default mode such that output
The verb *set up* is spelled with a space.
+behaves strangely. Setting the mode can fix this.
Should your device be mentioned in the documentation, and one of the
strangeness be described?
+
+Note: This command is only available on EFI platforms.
+@end deffn
+
+
@node eval
@subsection eval
Kind regards,
Paul
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] efi: Add efitextmode command for getting/setting the text mode resolution
Dear Glenn,
Thank you for the patch.
Am 12.05.22 um 05:07 schrieb Glenn Washburn:
This command is meant to behave similarly to the 'mode' command of the EFI
Shell application. One difference is that to set the mode the mode number
is given, not the rows and columns of the desired mode. Also supported are
the arguments "min" and "max", which set the mode to the minimum and
maximum mode respectively as calculated by the columns * rows of that mode.
Did you test this also with QEMU and OVMF?
Kind regards,
Paul
Signed-off-by: Glenn Washburn
---
grub-core/Makefile.core.def | 6 ++
grub-core/commands/efi/efitextmode.c | 118 +++
2 files changed, 124 insertions(+)
create mode 100644 grub-core/commands/efi/efitextmode.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 726f51be7..b22e48f0f 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -813,6 +813,12 @@ module = {
enable = efi;
};
+module = {
+ name = efitextmode;
+ efi = commands/efi/efitextmode.c;
+ enable = efi;
+};
+
module = {
name = blocklist;
common = commands/blocklist.c;
diff --git a/grub-core/commands/efi/efitextmode.c
b/grub-core/commands/efi/efitextmode.c
new file mode 100644
index 0..fb72aa6f3
--- /dev/null
+++ b/grub-core/commands/efi/efitextmode.c
@@ -0,0 +1,118 @@
+/* efitextmode.c - command to get/set text mode resolution */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2003,2005,2006,2007,2009 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see
