help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Diagon
Subject: Re: Using "grub-mkimage -c" for a USB holding multiple /boot partitions.
Date: Fri, 19 Dec 2014 01:52:04 -0800
User-agent: Zoho Mail

Ok!  I think we're beginning to grok each other, now!  :)

(I'm liberally reordering, cutting & pasting ...)

---- On Thu, 18 Dec 2014 23:59:46 -0800 Andrei Borzenkov<address@hidden> wrote 
---- 
 > В Thu, 18 Dec 2014 23:22:37 -0800 Diagon <address@hidden> пишет: 

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

Yes, I see that now.

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

Ok, one of my confusions about chainloading:

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

Yes, I was not clear about chainloading a file via it's _name_.  I thought it 
could only be done by block lists; but I get it now.  I can "chainload 
(hd0,msdos2)/grub/core.img".  That will be like using Partition 2 to boot OS2.
 
 > 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. 

Ok, so to be clear, I think what will work is a hybrid of our two ideas.  I 
think I understand the solution to now be:

USB = [MBR-grub...Partition 0...Partition 1...Partition 2...Partition 3....]

grub is installed once, pointing to a grub.cfg located in Partition 0.
that grub.cfg executes the logic:

If (this is laptop) 
then (chainload Partition 1's core.img, running partition 1's grub.cfg and 
booting the HD that is present)

If (this is desktop) 
then (chainload Partition 2's core.img, running partition 2's grub.cfg and 
booting some other HD that is present)

else (chainload Partition 3's core.img, running partition 3's grub.cfg and 
booting the OS sitting in Partition 3)

The only thing necessary here is that:

(1) we can stop the OS updates from ever touching either the grub installed 
adjacent to the MBR, or Partition 0.
(2) we are able to use some logic to identify what machine we are on

Regarding (1), you suggest that I figure out how to tell the OS to generate 
it's core.img, but to not to install grub anywhere, or at least put it 
somewhere harmless.  I'll look into how to do that.

Regarding (2):

> If you are using LUKS, it has UUID. 

This is not true.  I have detached headers.  I worked very hard to do that.  
The headers sit in the initramfs.  This behaves very much like a disk created 
by cryptsetup, without LUKS.

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

If I know what machine I'm on, based on some characteristic of the hardware, 
then I'll know what disk I have.  This is why Jordan was suggesting "hwmatch"; 
but there are no docs.  Can you tell me anything about how it works?

----------

And, I think I am clear (and to anyone who comes by later) we are not doing 
this:

 > 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 

We _are_ creating a fixed, unchanging /boot/grub in Partition 0, but we are 
also separating each OS's /boot directory, containing core.img, modules and 
grub.cfg, into it's own partition.

Also, the following is a misunderstanding.  Each machine has a different HDD.  
I'm always booting "HDD Partition 1".  It's just that it's a different HDD, 
depending on the machine.
 
 > if HDD partition1 found --------> No, "If machine 1 found"
 >   boot core.img from partition1 -----> which then boots the HDD in machine 1
 
 > if HDD partition2 found ---------> "If machine 2 found"
 >   boot core.img from partition2 ------> which then boots the HDD in machine 2

/D








reply via email to

[Prev in Thread] Current Thread [Next in Thread]