Re: [RFC] Allow separate boot block and core.img location?

Re: [RFC] Allow separate boot block and core.img location?

[joe faith]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

----- Original Message -----
From: Chris Murphy
Sent: 01/16/14 04:04 PM
To: The development of GNU GRUB
Subject: Re: [RFC] Allow separate boot block and core.img location?

Is there a good reason why we don't have a separate partition for core.img? It doesn't seem like it's an OK idea for anything to be using the unallocated MBR gap, it's essentially a free for all. So why not an 0xEA partition of 1MB that's the MBR equivalent of the GPT BIOS Boot partition? I don't know if it even necessarily requires use of a primary partition if the boot.img code in the MBR simply points to an LBA to load. If that's the case core.img could be in an extended partition. And once GRUB is running, it doesn't care about primary or extended partitions anyway, right? When using TrueCrypt whole disk encryption, for example, extended partitions are not supported (with WinXP anyway).
That leaves you with a maximum of 4 partitions - often not enough to spare one for grub (especially in multi-boot setups).

[-- Attachment #2: Type: text/html, Size: 1940 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Chris Murphy]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]


On Jan 16, 2014, at 7:13 PM, joe faith <dzrdmwjx@gmx.com> wrote:

>  
>> 
>> ----- Original Message -----
>> From: Chris Murphy
>> Sent: 01/16/14 04:04 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>  
>> Is there a good reason why we don't have a separate partition for core.img? It doesn't seem like it's an OK idea for anything to be using the unallocated MBR gap, it's essentially a free for all. So why not an 0xEA partition of 1MB that's the MBR equivalent of the GPT BIOS Boot partition? I don't know if it even necessarily requires use of a primary partition if the boot.img code in the MBR simply points to an LBA to load. If that's the case core.img could be in an extended partition. And once GRUB is running, it doesn't care about primary or extended partitions anyway, right? 
> When using TrueCrypt whole disk encryption, for example, extended partitions are not supported (with WinXP anyway).
> That leaves you with a maximum of 4 partitions - often not enough to spare one for grub (especially in multi-boot setups).

I must be having a problem counting:

1. GRUB
2. unencrypted "boot" for Windows/Truecrypt
3. Truecrypt encrypted "primary" for Windows
4. extended


Chris Murphy

[-- Attachment #2: Type: text/html, Size: 2645 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

On 21.01.2014 19:02, Chris Murphy wrote:
>>> 3. Truecrypt encrypted "primary" for Windows
Use truecrypt loader. That's funny how truecrypt guys push their agenda
but never there when it comes to coding or even testing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Chris Murphy]

On Jan 17, 2014, at 5:01 AM, joe faith <dzrdmwjx@gmx.com> wrote:

>  
>> 
>> ----- Original Message -----
>> From: Chris Murphy
>> Sent: 01/16/14 11:55 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>  
>> I must be having a problem counting:
>>  
>> 1. GRUB
>> 2. unencrypted "boot" for Windows/Truecrypt
>> 3. Truecrypt encrypted "primary" for Windows
>> 4. extended
>>  
>>  
>> Chris Murphy
>  
> Everyone else may not necessaily have the same requirements as you.

No I'm suggesting fairness, that GRUB get its own partition for those layouts that can support it. 


> Some of us might want to have a separate partition for data or even additional OSs.

Nothing I said is incompatible with partition lunacy.

> Also, I think I mentioned earlier that TrueCrypt FDE doesn't allow extended/logical partitions (with XP).
>  
> How about:
> 1. Unencrypted boot
> 2. Windows XP (truecrypt)
> 3. Windows 7 (truecrypt)
> 4. Linux root

Adding Windows 7 is changing the goal posts. The context was one linux and one Windows with TrueCrypt. So please explain how GRUB can't or shouldn't have its own partition. And also if you can, clarify that TrueCrypt really writes important metadata to the unallocated space in the MBR gap - because that seems like a really ill conceived design.

Also, linux root does not require a primary partition. If you're using GRUB it can even find /boot on something exotic like an XFS formatted LVM2 LV.


Chris Murphy

Re: [RFC] Allow separate boot block and core.img location?

[joe faith]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

----- Original Message -----
From: Chris Murphy
Sent: 01/16/14 11:55 PM
To: The development of GNU GRUB
Subject: Re: [RFC] Allow separate boot block and core.img location?

I must be having a problem counting:

1. GRUB
2. unencrypted "boot" for Windows/Truecrypt
3. Truecrypt encrypted "primary" for Windows
4. extended

Chris Murphy
Everyone else may not necessaily have the same requirements as you.
Some of us might want to have a separate partition for data or even additional OSs.
Also, I think I mentioned earlier that TrueCrypt FDE doesn't allow extended/logical partitions (with XP).
How about:
1. Unencrypted boot
2. Windows XP (truecrypt)
3. Windows 7 (truecrypt)
4. Linux root

[-- Attachment #2: Type: text/html, Size: 2068 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Chris Murphy]

> From: Andrey Borzenkov
> Sent: 12/16/13 02:36 PM
> To: grub-devel@gnu.org
> Subject: [RFC] Allow separate boot block and core.img location?
>  
> There are many users using dual boot with Windows and Linux. In this 
> configuration installing grub in MBR unfortunately breaks at least some 
> updates of Windows 8 (update fails). And installing grub in partition 
> has all sort of known problems with blocklists. 

Is there a good reason why we don't have a separate partition for core.img? It doesn't seem like it's an OK idea for anything to be using the unallocated MBR gap, it's essentially a free for all. So why not an 0xEA partition of 1MB that's the MBR equivalent of the GPT BIOS Boot partition? I don't know if it even necessarily requires use of a primary partition if the boot.img code in the MBR simply points to an LBA to load. If that's the case core.img could be in an extended partition. And once GRUB is running, it doesn't care about primary or extended partitions anyway, right?


Chris Murphy

Re: [RFC] Allow separate boot block and core.img location?

[joe faith]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

May I also suggest that "--core-img-location" parameter accept a block-list in some format, in addition to the device identifier?grub-install --boot-block-location=/dev/sda --core-img-location=/dev/sda[63+1985] => embed core image in the 1985 sectors starting at LBA 63 on /dev/sda This would be helpful in dealing with certain software that tend to use the MBR area to store their configuration. For example, TrueCrypt disk encryption software uses LBA 62 (0x3E) to store the volume header of the system volume. I know that the use of the MBR area by any such software is not approriate, however, some extra flexibility in the grub-installer will certainly address some of these issues. Cheers!
----- Original Message -----
From: Andrey Borzenkov
Sent: 12/16/13 02:36 PM
To: grub-devel@gnu.org
Subject: [RFC] Allow separate boot block and core.img location?

There are many users using dual boot with Windows and Linux. In this configuration installing grub in MBR unfortunately breaks at least some updates of Windows 8 (update fails). And installing grub in partition has all sort of known problems with blocklists. What about allowing separate locations for boot block and core.img? I.e. something like grub-install --boot-block-location=/dev/sda1 --core-img-location=/dev/sda This has all advantages of embedding core.img while allowing leaving MBR alone. Actually we could assume default --core-img-location, meaning that for grub-install --boot-block-location=/dev/sda1 we assume that core.img has to be embedded in /dev/sda unless proved otherwise :) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 2984 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Chris Murphy]

On Dec 19, 2013, at 9:31 AM, joe fresh <dzrdmwjx@gmx.com> wrote:
> The intent there was to install the boot block (boot.img) into the first sector of sda1, which is what my suggested workaround would have done as well.
> Also, if sda1 happens to be a fat or ntfs volume, this would need to be tweaked to ensure that the critical volume parameters are preserved.

You'd have to proscribe XFS from this, it doesn't have the space in the first sector that you require. I'm sure there are other examples.

> The assumption in both cases is that the user knows what they are doing…

Given the reality, exhibits A, B, C, D, and so on, this seems like a seriously unwarranted assumption. Users want to do all kinds of crazy things while also not learning necessarily esoteric facts about booting. I think the ship has sailed quite a while ago that ordinary users can be expected to know what they're doing in this realm of computing. It's complicated enough that even individual experts have developed highly specialized knowledge that their peers don't have.

Chris Murphy

Re: [RFC] Allow separate boot block and core.img location?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

On 19.12.2013 17:31, joe fresh wrote:
> The assumption in both cases is that the user knows what they are doing...
The reverse is usually true.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[joe fresh]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

sda1 was just an example taken from the original request:grub-install --boot-block-location=/dev/sda1 --core-img-location=/dev/sda The intent there was to install the boot block (boot.img) into the first sector of sda1, which is what my suggested workaround would have done as well.
Also, if sda1 happens to be a fat or ntfs volume, this would need to be tweaked to ensure that the critical volume parameters are preserved.
The assumption in both cases is that the user knows what they are doing...

Cheers!
----- Original Message -----
From: Lennart Sorensen
Sent: 12/19/13 09:34 AM
To: The development of GNU GRUB
Subject: Re: [RFC] Allow separate boot block and core.img location?

On Thu, Dec 19, 2013 at 05:28:16AM -0500, joe fresh wrote: > Isn't this as simple as: > > grub-install /dev/sda > dd if=/dev/sda of=/dev/sda1 bs=512 count=1 > followed by restoring DOS MBR... ? sda1 might not like having it's first sector overwritten. -- Len Sorensen _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 2489 bytes --]

Re: [RFC] Allow separate boot block and core.img location?

[Lennart Sorensen]

On Thu, Dec 19, 2013 at 05:28:16AM -0500, joe fresh wrote:
> Isn't this as simple as:
> 
> grub-install /dev/sda
> dd if=/dev/sda of=/dev/sda1 bs=512 count=1
> followed by restoring DOS MBR... ?

sda1 might not like having it's first sector overwritten.

-- 
Len Sorensen

Re: [RFC] Allow separate boot block and core.img location?

[joe fresh]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Isn't this as simple as:

grub-install /dev/sda
dd if=/dev/sda of=/dev/sda1 bs=512 count=1
followed by restoring DOS MBR... ?

Cheers!
----- Original Message -----
From: Andrey Borzenkov
Sent: 12/16/13 02:36 PM
To: grub-devel@gnu.org
Subject: [RFC] Allow separate boot block and core.img location?

There are many users using dual boot with Windows and Linux. In this configuration installing grub in MBR unfortunately breaks at least some updates of Windows 8 (update fails). And installing grub in partition has all sort of known problems with blocklists. What about allowing separate locations for boot block and core.img? I.e. something like grub-install --boot-block-location=/dev/sda1 --core-img-location=/dev/sda This has all advantages of embedding core.img while allowing leaving MBR alone. Actually we could assume default --core-img-location, meaning that for grub-install --boot-block-location=/dev/sda1 we assume that core.img has to be embedded in /dev/sda unless proved otherwise :) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 2386 bytes --]

[RFC] Allow separate boot block and core.img location?

[Andrey Borzenkov]

There are many users using dual boot with Windows and Linux. In this
configuration installing grub in MBR unfortunately breaks at least some
updates of Windows 8 (update fails). And installing grub in partition
has all sort of known problems with blocklists.

What about allowing separate locations for boot block and core.img?
I.e. something like

grub-install --boot-block-location=/dev/sda1
--core-img-location=/dev/sda

This has all advantages of embedding core.img while allowing leaving
MBR alone. Actually we could assume default --core-img-location, meaning
that for

grub-install --boot-block-location=/dev/sda1

we assume that core.img has to be embedded in /dev/sda unless proved
otherwise :)