Re: --recheck option
2012/7/5 Jordan Uggla > On Thu, Jul 5, 2012 at 5:19 AM, yannubu...@gmail.com > wrote: > > Dear GRUB devs/helpers, > > > > A) Which are the situations where the --recheck option of grub-install > must > > NOT be used? why grub-install wouldn't systematically probe a device map > by > > default? > > With grub 2.00, it does. > http://www.gnu.org/software/grub/manual/grub.html#Device-map . > > > > > B) Some people recommend to use "grub-install /dev/sdX && grub-install > > --recheck /dev/sdX", do you think it is correct/useful? > > As explained in the above documentation, grub utilities no longer need > a device.map file. Back when they did still need one, the first time > someone ran grub-install it would write a device.map (if one didn't > already exist). If that got out sync somehow then a later grub-install > might fail, and if that happened using the --recheck option (which > would write a new device.map, overwriting the old one) might allow the > installation to succeed. > > Now, grub-install probes on the fly if no device.map exists, and never > creates a device.map file itself, and so "grub-install --recheck ..." > now actually simply deletes the device.map file, causing grub-install > to go back to the default state of probing on the fly. > > Running grub-install twice is redundant, and adding the '--recheck' is > also usually not needed option at this point but won't hurt anything > (except in very specific situations like when you're passing an LVM > logical volume to a virtual machine as if it were a normal disk, in > which case you should know what you're doing and have a backup of your > device.map anyway). > > So the advice is a little silly at this point, but not harmful. > > -- > Jordan Uggla (Jordan_U on irc.freenode.net) > If I understood well, - we should recommend using --recheck for 1.98<=GRUB<2.00. Advanced users using device.map will know if they don't need --recheck. - using --recheck or not makes no difference for GRUB>=2.00 Am I correct? (is the --recheck option kept in 2.00+ for retro-compatibility?) Thanks a lot Yann ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: --recheck option
On Thu, Jul 5, 2012 at 5:19 AM, yannubu...@gmail.com wrote: > Dear GRUB devs/helpers, > > A) Which are the situations where the --recheck option of grub-install must > NOT be used? why grub-install wouldn't systematically probe a device map by > default? With grub 2.00, it does. http://www.gnu.org/software/grub/manual/grub.html#Device-map . > > B) Some people recommend to use "grub-install /dev/sdX && grub-install > --recheck /dev/sdX", do you think it is correct/useful? As explained in the above documentation, grub utilities no longer need a device.map file. Back when they did still need one, the first time someone ran grub-install it would write a device.map (if one didn't already exist). If that got out sync somehow then a later grub-install might fail, and if that happened using the --recheck option (which would write a new device.map, overwriting the old one) might allow the installation to succeed. Now, grub-install probes on the fly if no device.map exists, and never creates a device.map file itself, and so "grub-install --recheck ..." now actually simply deletes the device.map file, causing grub-install to go back to the default state of probing on the fly. Running grub-install twice is redundant, and adding the '--recheck' is also usually not needed option at this point but won't hurt anything (except in very specific situations like when you're passing an LVM logical volume to a virtual machine as if it were a normal disk, in which case you should know what you're doing and have a backup of your device.map anyway). So the advice is a little silly at this point, but not harmful. -- Jordan Uggla (Jordan_U on irc.freenode.net) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
--recheck option
Dear GRUB devs/helpers, A) Which are the situations where the --recheck option of grub-install must NOT be used? why grub-install wouldn't systematically probe a device map by default? B) Some people recommend to use "grub-install /dev/sdX && grub-install --recheck /dev/sdX", do you think it is correct/useful? Regards Yann ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Measurements during boot
Hi, I'm currently looking to add support to grub2 to provide code/data measurement to the TPM on supported PC's (if you want more information on this topic, google search "root of trust for reporting", otherwise I'm happy to explain in a further post or email). I've begun writing some interfaces to the hardware (TPM), but was wondering what the best way of structuring this entire operation might be. To make my current goal clear, I'm only beginning with the multiboot module as a starting point (but it would be preferable if it was generic enough to be widely useable in any loader modules), and I'm currently aiming for the boot loader to be used in a PXE environment, so am not concerned in measuring separate stages (my understanding for PXE at the moment is that everything is compiled together into a single image which is downloaded and measured from a server by a PXE boot rom, I don't intend to download separate grub modules afterwards). No matter how I look at it, I feel that the only possible solution will be one which edits the loader code to insert a call which measures the kernel and module (initrd, not grub modules) code, just before boot. Is it worthwhile however hooking it in such a way that a user could create a line such as: measure multiboot /path/to/kernel kernel-cmd-line-args measure module /path/to/module or: measure multiboot /path/to/kernel kernel-cmd-line-args module /path/to/module as opposed to the usual configuration which is just: multiboot /path/to/kernel kernel-cmd-line-args module /path/to/module in their grub.cfg. Otherwise I could just hard code the measurement process into the multiboot loader process, possibly making it optional at compile time with a #define? Thanks in advance for your time and input. Nick ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Measurements during boot
Hi, I'm currently looking to add support to grub2 to provide code/data measurement to the TPM on supported PC's (if you want more information on this topic, google search "root of trust for reporting", otherwise I'm happy to explain in a further post or email). I've begun writing some interfaces to the hardware (TPM), but was wondering what the best way of structuring this entire operation might be. To make my current goal clear, I'm only beginning with the multiboot module as a starting point (but it would be preferable if it was generic enough to be widely useable in any loader modules), and I'm currently aiming for the boot loader to be used in a PXE environment, so am not concerned in measuring separate stages (my understanding for PXE at the moment is that everything is compiled together into a single image which is downloaded and measured from a server by a PXE boot rom, I don't intend to download separate grub modules afterwards). No matter how I look at it, I feel that the only possible solution will be one which edits the loader code to insert a call which measures the kernel and module (initrd, not grub modules) code, just before boot. Is it worthwhile however hooking it in such a way that a user could create a line such as: measure multiboot /path/to/kernel kernel-cmd-line-args measure module /path/to/module or: measure multiboot /path/to/kernel kernel-cmd-line-args module /path/to/module as opposed to the usual configuration which is just: multiboot /path/to/kernel kernel-cmd-line-args module /path/to/module in their grub.cfg. Otherwise I could just hard code the measurement process into the multiboot loader process, possibly making it optional at compile time with a #define? Thanks in advance for your time and input. Nick ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
