Re: Grub PARTUUID vs UUID
Please don't post the exact same mail as response to another message, it's both ignored and considered annoying. On 24.10.2013 05:53, FireIcer wrote: Message: 5 Date: Thu, 24 Oct 2013 01:37:06 +0100 From: FireIcer f1r31...@gmail.com To: grub-devel@gnu.org Subject: Grub PARTUUID vs UUID Message-ID: 52686bb2.2030...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hey I am looking at the impact in general with changing the grub-mkconfig scan not to pickup and update the grub.cfg with the UUID code but the PARTUUID code instead. At present the situation forces the user to enable a working initramfs to work around grub2. Why is this a problem? well because initramfs can be used to decorate ones boot display and many other things other than it's intended use. This means that UUID as a parameter in the grub.cfg wont work. I understand that Windows partitions use a shortened UUID only, so compatibility needs to be able to differentiate between the two types. UUID for windows partitions and PARTUUID for other GPT partitions. I cant understand why UUID's were used rather than PARTUUID's. If the code was modified to use PARTUUID's instead, what would be the impact on compatibility on a large scale. If people enable the option in Grub to use PARTUUID's then surely they would know to setup GPT disks. I feel it should be encouraged to remove the MBR tables as it is old and useless not to mention tied in to microsoft products. Now we have an Intel contribution GPT which works much better is it not right that we encourage the use of GPT over MBR? The point of this post is to raise alarm to the fact UUID's wont work without initramfs or initrd as so to read the UUID but the kernel can read PARTUUID without the use of initrd. Would that not be far better to not rely on init ram filesystem? A option/switch parameter when using mkconfig to output the cfg file maybe? Thanks f1r31c3r -- Message: 6 Date: Thu, 24 Oct 2013 03:07:00 +0200 From: Vladimir '?-coder/phcoder' Serbinenko phco...@gmail.com To: grub-devel@gnu.org Subject: Re: Grub PARTUUID vs UUID Message-ID: 526872b4.4080...@gmail.com Content-Type: text/plain; charset=utf-8 On 24.10.2013 02:37, FireIcer wrote: Hey I am looking at the impact in general with changing the grub-mkconfig scan not to pickup and update the grub.cfg with the UUID code but the PARTUUID code instead. At present the situation forces the user to enable a working initramfs to work around grub2. Why is this a problem? well because initramfs can be used to decorate ones boot display and many other things other than it's intended use. This means that UUID as a parameter in the grub.cfg wont work. I understand that Windows partitions use a shortened UUID only, so compatibility needs to be able to differentiate between the two types. UUID for windows partitions and PARTUUID for other GPT partitions. I cant understand why UUID's were used rather than PARTUUID's. If the code was modified to use PARTUUID's instead, what would be the impact on compatibility on a large scale. Please do not confuse how GRUB finds disks itself and what is passed as root= parameter. Those are separate discussions and second one touches exclusively grub-mkconfig. If people enable the option in Grub to use PARTUUID's then surely they would know to setup GPT disks. I feel it should be encouraged to remove the MBR tables as it is old and useless not to mention tied in to microsoft products. Completely wrong. MBR partition table does not imply any microsoft product. It's used for very different disks in different systems, some of them never had windows at all. Also this is wrong to say that there is no partition ID in MBR. There is MBRID which is concatenated with partition offset to give the ID. Now we have an Intel contribution GPT which works much better is it not right that we encourage the use of GPT over MBR? Intel is very low on my esteem with all the crapware which got out of it recently. The point of this post is to raise alarm to the fact UUID's wont work without initramfs or initrd as so to read the UUID but the kernel can read PARTUUID without the use of initrd. Would that not be far better to not rely on init ram filesystem? This sounds like Linux limitation, doesn't it? A option/switch parameter when using mkconfig to output the cfg file maybe? I don't see any patch attached. --- I have done more investigating and hacking regarding the UUID vs PARTUUID. You are correct, sorry for getting it wrong in my last message, yes Grub finds disks via UUID. It is unfortunate the kernel works like this at present. A dilemma, dig into the kernel code and find out if or stick to my workaround that is not ideal. I have found that if i put PARTUUID=x... into the /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT then it
Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com 10/23/13 7:02 PM GrUB - which iiuc stays in memory after transferring control - could export its file system support to its descendants). Xen shouldn't need to load any file after multiboot2 entry point. The needed files would already be in memory with pointers to them passed. I should have said to its chainloaded descendants. If you insist on being able to load directly from EFI, then IMO the best way is to have a PE executable with one of sections containing Xen and code which would load remaining files to memory and call common entry point. I think you've been told before - this is what has been working already for quite some time. Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
How to setup grub with /boot inside luks+vm ?
Hello list, I have the grub2 (1.99-27+deb7u2 ) working with luks+lvm but /boot not included in lvm... Can grub2 call /boot from luks+lvm ? If yes, can anyone please share the configuration please ? Thanks ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to setup grub with /boot inside luks+vm ?
On 24.10.2013 11:28, J B wrote: Hello list, I have the grub2 (1.99-27+deb7u2 ) working with luks+lvm but /boot not included in lvm... Can grub2 call /boot from luks+lvm ? If yes, can anyone please share the configuration please ? Not the version that you use. Thanks ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: While technically a violation of the UEFI spec, I think this can be worked around by considering the disk GPT if the first entry in the MBR is type 0xEE. I don't know of a hybrid MBR implementation where an entry other than the first is 0xEE. Well everyone other than Microsoft seems to understand how useful support for hybrid setups can be and hence support them. But if there is no 0xEE entry at all, this is identical to a formerly GPT disk repartitioned as MBR by a utility that doesn't know anything about GPT, and thus doesn't erase the stale GPT data - and therefore must be treated as MBR. That is true. That does not mean there must ONLY be a 0xEE entry. So perhaps this test is difficult because it's GPT on BIOS, with a limited space BIOS boot partition. However, I think on UEFI computers this should still work with one valid GPT, rather than not boot at all. There's a lot more space for this there. Certainly if using the BIOS boot partition, there really isn't much of a space excuse anymore, unless you run into limitations on how much ram you can use in early boot. Both primary and backup GPTs are preserved in this case since the primary is in LBA 1 and 2, and only LBA 0 is overwritten with the new MBR. UEFI spec says if the MBR signature of 0xaa55 is intact, and there isn't an 0xEE entry, and the partition entries are rational (physically on disk and don't overlap), then the two GPTs are considered stale and the disk is MBR. The primary header contains the location of the backup GPT. If the header is sufficiently corrupt, and the backup GPT can't be located, then that's the same as an invalid backup GPT, and in that case fail. My point is we shouldn't fail when there is a valid locatable backup GPT. The whole point of having a second GPT is obviated with the current behavior. Sometimes backups are designed in and never used. I don't recall ever seeing any indication Microsoft ever used the second copy of the FAT for anything other than filesystem repair tools. I don't think we can work around this kind of hardware vendor sabotage. If it looks like a valid GPT, but is actually stale, if it's used and contains incorrect information, then boot fails. Better to try than not try at all. It's certainly uncommon. A Google search: corrupt primary gpt only turns up 1900 results. But it is possible. And this isn't the only mishandling I'm finding, so it's not like GRUB is unique. In fact just now by changing only a single byte in the primary GPT table (I changed the E to an F in the BIOS boot partition type UUID), the kernel suddenly has no idea what disklabel the disk is, and fails to mount rootfs. So I need to track that down too, but it seems like it knows the primary GPT table is corrupt, but then fails to use the backup GPT for some reason. An argument against GRUB doing all of this work: maybe the bootloader should be able to blindly trust the primary GPT table with no validity checks? And instead rely on (presently non-existent) checks by the underlying OS to fixi this problem? Something like an fsck_gpt, seeing as nothing else is in a good position to both check and fix such GPTs other than a partition tool. Perhaps. Certainly simpler. I do wonder how Windows handles booting with a corrupt primary GPT. Would you happen to know? (A quick google search didn't find an answer to the question unfortunately). The UEFI spec says Software should ask a user for confirmation before restoring the primary GPT and yet it also requires the unspecified software fix the primary GPT if corrupt. The spec actually uses the word must. So per usual, the spec has rather lofty demands. So it must fix it after asking the user for confirmation? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
How to pick a kernel to boot ?
Hi, I have a simple question about grub2 which I can not find satisfying answer to. What is a proper way to pick a kernel to boot from in case I have multiple kernels installed ? Note that picking the right kernel from the menu is not an option I do not always have access to the console. With grub legacy, this was easy. Simply edit /boot/grub/menu.lst and pick the right number. All the information I need are in that file. So what is a recommended way to do this with grub2 ? Thanks! -Lukas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to pick a kernel to boot ?
On Thu, Oct 24, 2013 at 04:46:19PM +0200, Lukáš Czerner wrote: Hi, I have a simple question about grub2 which I can not find satisfying answer to. What is a proper way to pick a kernel to boot from in case I have multiple kernels installed ? Note that picking the right kernel from the menu is not an option I do not always have access to the console. With grub legacy, this was easy. Simply edit /boot/grub/menu.lst and pick the right number. All the information I need are in that file. So what is a recommended way to do this with grub2 ? Same thing in /boot/grub/grub.cfg. There is default with a number. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to pick a kernel to boot ?
On 10/24/2013 12:44 PM, Lennart Sorensen wrote: On Thu, Oct 24, 2013 at 04:46:19PM +0200, Lukáš Czerner wrote: Hi, I have a simple question about grub2 which I can not find satisfying answer to. What is a proper way to pick a kernel to boot from in case I have multiple kernels installed ? Note that picking the right kernel from the menu is not an option I do not always have access to the console. With grub legacy, this was easy. Simply edit /boot/grub/menu.lst and pick the right number. All the information I need are in that file. So what is a recommended way to do this with grub2 ? Same thing in /boot/grub/grub.cfg. There is default with a number. Sorry ... some how left the list off my initial reply ... To set a default to boot, use grub2-set-default [kernel entry number] To boot a kernel once and keep the default the same (ie, boot a kernel one time) grub2-reboot [kernel entry number] I've noticed a lot of people messing with /boot/grub2/grub.conf ... you shouldn't have to do that to select a kernel to boot. P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Oct 24, 2013, at 7:39 AM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: While technically a violation of the UEFI spec, I think this can be worked around by considering the disk GPT if the first entry in the MBR is type 0xEE. I don't know of a hybrid MBR implementation where an entry other than the first is 0xEE. Well everyone other than Microsoft seems to understand how useful support for hybrid setups can be and hence support them. Support is a very strong word. They're basically a craptastic workaround for prior unfortunate choices. Apple uses them, it hardly supports them. Their tools routinely nuke hybrid MBRs in favor of PMBRs rendering the secondary OS unbootable; if the MBR and GPT aren't sync'd, they will bone the correct MBR with wrong GPT information, rendering the secondary OS unbootable and data inaccessible. And it does this silently. I think it's OK to tiptoe around hybrid MBRs, and do something sensible, if possible. Supporting them is out of scope because there's no standard or agreed upon way to interpret them. But if there is no 0xEE entry at all, this is identical to a formerly GPT disk repartitioned as MBR by a utility that doesn't know anything about GPT, and thus doesn't erase the stale GPT data - and therefore must be treated as MBR. That is true. That does not mean there must ONLY be a 0xEE entry. Well, there must be only an 0xEE entry to treat the disk as a pure GPT disk. Once there's 0xEE and 1-3 additional entries, it's a hybrid logic, very few combinations of which are sane. When the MBR and GPT don't agree with each other, which on Macs is actually somewhat common once you've used Bootcamp Assistant, because users think it's OK to resize OS X volumes in OS X Disk Utility, and then use free space to either create an additional OS X partition, or grow an existing Windows partition from within Windows. Oops, now the MBR and GPT don't agree with each other, so which one is correct? Well, it's ambiguous. With a few exceptions, there's actually no way to know what's correct, which is why hybrid MBRs are ultimately shit. But again, I'm fine dodging piles of crap rather than cleaning up other people's messes. I do wonder how Windows handles booting with a corrupt primary GPT. Would you happen to know? (A quick google search didn't find an answer to the question unfortunately). I haven't tested it because I don't have a UEFI machine here, only Apple EFI. So I'm stuck with CSM-BIOS mode booting of Windows, which means it will only use MBR. I haven't figured out UEFI within qemu/kvm, and if that can boot Windows in UEFI mode. The UEFI spec says Software should ask a user for confirmation before restoring the primary GPT and yet it also requires the unspecified software fix the primary GPT if corrupt. The spec actually uses the word must. So per usual, the spec has rather lofty demands. So it must fix it after asking the user for confirmation? Yes it's just being silly. But the take away is that (partitioning) tools are behaving wrongly if they understand GPT, yet ignore or can't fix problems with either GPT. The spec only says software, it doesn't specify what software, so I'm assuming partitioning tools. Obviously the kernel is software, but it's not in a position to ask the user anything. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Windows 7 won't boot properly IF keyboard input is made during grub boot timeout
I'm seeing a funny behavior which I think is caused by GRUB leaving the HW in some state that Windows is not expecting. Here is the scenario. In my new Haswell system, I installed an Ubuntu-based custom OS in a dual-boot configuration with the existing Win7 OEM. The grub menu has Ubuntu 1st and Windows 7 as second choice. If I power up the machine and use the arrow keys to move the highlighter cursor from the Ubuntu entry to the Win7 entry, Windows will choke during loading. The graphics will be all garbled. Eventually (many minutes 10 mins), windows does boot. Now, here is the funny thing. If I boot and don't touch any keys and simply let the grub boot timer expire and boot the selected entry (which happens to be Windows 7 since it was the last one I booted), then Windows will boot fine. This is reproducible about 90% of the time. Any time a key is touched during the count down, Windows will chock up during its booting process. The other 10% of the time, Windows will boot normally. Is this a known problem with my grub version 1.99 (1.99-21ubuntu3.9)? Any suggestions on what I should look to try to fix in the source code? Thanks in advance. Roger R. Cruz ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] Documentation cleanup in response to ML discussion.
Go ahead
On 22.10.2013 01:15, Jon McCune wrote:
[v0] Accepted with modifications by phcoder@
[v1] Introduce subsections within Security
[v1] Correct errors regarding public key files not being automatically
signature-checked in trust and verify_detached
[v1] Replace check_signatures=enforce with check_signatures set to enforce
[v1] Move detailed discussion of using signatures out of check_signatures
environment variable description
[v1] Use long form for option flags to security-relevant commands
[v2] Explain the key fingerprint format for distrust and list_trusted.
[v2] Eliminates references to grub-mkimage and UEFI Secure Boot.
[v3] Updates in response to addition of --skip-sig to trust and
verify_detached
Signed-off-by: Jon McCune jonmcc...@google.com
---
docs/grub.texi | 197
-
1 file changed, 112 insertions(+), 85 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 40eb9ed..8b0b76b 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -98,8 +98,7 @@ This edition documents version @value{VERSION}.
* Environment:: GRUB environment variables
* Commands::The list of available builtin commands
* Internationalisation::Topics relating to language support
-* Security::Authentication and authorisation
-* Security and signatures:: Verifying digital signatures in GRUB
+* Security::Authentication, authorisation, and signatures
* Platform limitations::The list of platform-specific limitations
* Platform-specific operations:: Platform-specific operations
* Supported kernels:: The list of supported kernels
@@ -3006,20 +3005,7 @@ chain-loaded system, @pxref{drivemap}.
@subsection check_signatures
This variable controls whether GRUB enforces digital signature
-validation (@pxref{Security and signatures}) on all loaded files. If
-@code{check_signatures=enforce}, then every attempt by the GRUB
-@file{core.img} to load another file @file{foo} (e.g., a loadable
-module, a configuration file, or a Linux kernel) implicitly invokes
-@code{verify_detached foo foo.sig} (@pxref{verify_detached}).
-@code{foo.sig} must contain a valid digital signature over the
-contents of @code{foo}, which can be verified with a public key
-currently trusted by GRUB (@pxref{list_trusted}, @pxref{trust}, and
-@pxref{distrust}). If validation fails, then file @file{foo} cannot
-be opened. This failure may halt or otherwise impact the boot
-process. An initial trusted public key can be embedded within the
-GRUB @file{core.img} using the @code{--pubkey} option to
-@command{grub-mkimage} (@pxref{Invoking grub-install}).
-
+validation on loaded files. @xref{Using digital signatures}.
@node chosen
@subsection chosen
@@ -3998,10 +3984,15 @@ but rather replaces it completely.
@deffn Command distrust pubkey_id
Remove public key @var{pubkey_id} from GRUB's keyring of trusted keys.
-These keys are used to validate signatures when
-@code{check_signatures=enforce} (@pxref{check_signatures}), and by some
-invocations of @command{verify_detached} (@pxref{verify_detached}).
-@xref{Security and signatures} for more information.
+@var{pubkey_id} is the last four bytes (eight hexadecimal digits) of
+the GPG v4 key id, which is also the output of @command{list_trusted}
+(@pxref{list_trusted}). Outside of GRUB, the key id can be obtained
+using @code{gpg --fingerprint}).
+These keys are used to validate signatures when environment variable
+@code{check_signatures} is set to @code{enforce}
+(@pxref{check_signatures}), and by some invocations of
+@command{verify_detached} (@pxref{verify_detached}). @xref{Using
+digital signatures}, for more information.
@end deffn
@node drivemap
@@ -4264,56 +4255,58 @@ This command is only available on x86 systems.
@node list_env
@subsection list_env
-@deffn Command list_env [@option{-f} file]
+@deffn Command list_env [@option{--file} file]
List all variables in the environment block file. @xref{Environment block}.
-The @option{-f} option overrides the default location of the environment
-block.
+The @option{--file} option overrides the default location of the
+environment block.
@end deffn
@node list_trusted
@subsection list_trusted
@deffn Command list_trusted
-List all public keys trusted by GRUB for validating signatures. These
-public keys are used implicitly when environment variable
-@code{check_signatures=enforce} (@pxref{check_signatures}), and by some
-invocations of @command{verify_detached}. @xref{Security and
-signatures} for more information.
+List all public keys trusted by GRUB for validating signatures.
+The output is in GPG's v4 key fingerprint format (i.e., the output of
+@code{gpg --fingerprint}). The least significant four bytes (last
+eight hexadecimal digits) can be used as an
