Re: Using "grub-mkimage -c" for a USB holding multiple /boot partitions.

[Diagon]

Andrei - thank you for your input.  See below. 
 
---- On Thu, 18 Dec 2014 22:29:20 -0800 Andrei Borzenkov  wrote ----  
 
> В Thu, 18 Dec 2014 17:45:24 -0800 Diagon <address@hidden> пишет:  
>> ---- On Thu, 18 Dec 2014 16:31:23 -0800 Jordan Uggla <address@hidden> wrote 
>> ----  
>>> On Thu, Dec 18, 2014 at 12:35 PM, Diagon <address@hidden> wrote:  
>>>> I see that I can install a config file into grub, using "grub-mkimage -c". 
>>>>  
 
> No, you do not. grub-mkimage is internal tool (and is to large extent  
> superseded in current upstream version);  
 
Ok, I'll take your word for it.  Notice that this was described in the v.2.00 
manual.  Section 5.4, as I linked in my first post. 
 
> embedded configuration is intended to get access to /boot/grub  
> directory only   
 
Notice that what I am describing here is indeed an attempt to get access to the 
/boot/grub directory.  It's just that I need to get to the one that's correct 
for the machine I happen to be on at the moment. 
 
> and is autogenerated.  If you want to create standalone bootloader image,  
> use grub-mkstandalone.  
 
Ok, I'm taking a look.  That's in the man pages, but not in the v.2.02 info 
docs that I can find.  It seems the project is moving very fast!   
 
>>>> I'd like the config file to do something like this:  
>>>>  
>>>> If (this is my laptop) then (run the config file in Partition 1)  
>>>> else if (this is my desktop) then (run the config file in Partition 2)  
>>>> else (run the config file in Partition 3)  
  
>>> The above doesn't seem to depend on having an embedded config at all.  
>>> I highly recommend simply having a grub.cfg file on the USB drive that  
>>> implements this logic, and using a standard grub-install invocation to  
>>> install grub.  
 
[...] 
 
>> Jordan- please correct me if I'm wrong, but my reasoning was that by this 
>> approach, all updates performed by the various OS's could remain automatic 
>> (save for my having to figure out how to tweak this one addition, a small 
>> config in core.img). Otherwise, on any OS update that updates grub, the next 
>> boot will take me to the grub.cfg in the partition associated with that OS. 
>> That grub.cfg would then need to have the above logic. This would have to be 
>> true for each OS.  
 
> That's why a lot of people have dedicated partition where grub is installed 
> and which chainloads (in broad sense) bootloaders from other partitions 
> where operating systems are present. 
 
Andrei - I'm a bit confused.  I'm sure you're not saying I should be 
chainloading grubs, right?  Are you suggesting then that my core.img access a 
config file in Partition 0, which executes the logic above, and runs the proper 
grub.cfg in Partition 1, 2 or 3?  The problem I see with this is that I will 
have to re-install every second day (as you say below), because my OS will be 
updating.  If the OS is the one associated with, say, Partition 2, then if it 
reinstalls grub, grub will now be pointing to Partition 2, rather than 
Partition 0. So every time my OS updates, I'll have to go in there and 
reinstall to make it point to Partition 0.  Am I misunderstanding? 
 
> Unless you plan to reinstall every second day, the most simple solution in 
> your 
> case is to match by filesystem UUID which is guaranteed to be unique and 
> stable.  
 
As I said in my first post, my disks are all encrypted with either no headers 
or headers in the initramfs.  There are no visible UUIDs on the disks, so I can 
not use them to identify the proper /boot directory for the particular machine 
I am on at the moment.  The suggestion by Jordan was to use "hwmatch", though I 
can't find any documentation on how it works. 
 
>And how OS update is going to override anything on your USB stick?  
 
On update, the OS is going to write to it's associated /boot partition, and it 
will overwrite grub on the USB any time the updater runs grub-install, which it 
does occasionally. 
 
/D