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

[Andrei Borzenkov]

В Thu, 18 Dec 2014 23:22:37 -0800
Diagon <address@hidden> пишет:
>  
> > 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!  

No, the project is moving too slow ... :(
 
>  
> >>>> 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?

That is exactly what I say.

  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?

No. First, grub.cfg is version and OS dependent; second, unfortunately,
there is not proper separation between binary (modules) location and
configuration file(s) location. What I say is, that primary grub should
execute core.img from each partition as payload. You do it using
multiboot command.

  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

Primary grub will load secondary core.img by name. Name always remains
the same, also after update.

  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? 

Ah, sorry, I now realized confusion. Do not use "USB stick that hold
multiple boot partitions". Use USB stick with *one* /boot/grub and
grub.cfg that basically does

if HDD partition1 found
  boot core.img from partition1

if HDD partition2 found
  boot core.img from partition2

...

>  
> > 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. 

If you are using LUKS, it has UUID. If you are not using LUKS, there is
no way to know where your encrypted partition is anyway. You MUST have
something that allows you to identify it.

>  
> >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. 

You original scheme is not going to work for at least one reason -
there is no guarantee that grub binaries will be compatible between
distributions. So you cannot build core.img on one system and point
it to modules from another system. And in your scheme you will have
single core.img loaded initially. The right way to implement it is to
load core.img from target system and let it proceed.

So make USB stick *once* and do not touch it. Configure your OS on each
partition to only create grub.cfg without installing grub on disk if
possible, or to install grub somewhere else (I'd still make it
different partition for each). Then your USB stick will not be
overwritten on updates.