* [RFC] Allow separate boot block and core.img location?
@ 2013-12-16 19:36 Andrey Borzenkov
0 siblings, 0 replies; 13+ messages in thread
From: Andrey Borzenkov @ 2013-12-16 19:36 UTC (permalink / raw)
To: grub-devel
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 :)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
@ 2013-12-19 10:28 joe fresh
2013-12-19 14:34 ` Lennart Sorensen
2014-01-16 21:04 ` Chris Murphy
0 siblings, 2 replies; 13+ messages in thread
From: joe fresh @ 2013-12-19 10:28 UTC (permalink / raw)
To: The development of GNU GRUB, grub-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2013-12-19 10:28 joe fresh
@ 2013-12-19 14:34 ` Lennart Sorensen
2014-01-16 21:04 ` Chris Murphy
1 sibling, 0 replies; 13+ messages in thread
From: Lennart Sorensen @ 2013-12-19 14:34 UTC (permalink / raw)
To: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2013-12-19 10:28 joe fresh
2013-12-19 14:34 ` Lennart Sorensen
@ 2014-01-16 21:04 ` Chris Murphy
1 sibling, 0 replies; 13+ messages in thread
From: Chris Murphy @ 2014-01-16 21:04 UTC (permalink / raw)
To: The development of GNU GRUB
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
@ 2013-12-19 16:31 joe fresh
2013-12-19 18:18 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-19 22:54 ` Chris Murphy
0 siblings, 2 replies; 13+ messages in thread
From: joe fresh @ 2013-12-19 16:31 UTC (permalink / raw)
To: The development of GNU GRUB
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2013-12-19 16:31 joe fresh
@ 2013-12-19 18:18 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-19 22:54 ` Chris Murphy
1 sibling, 0 replies; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-19 18:18 UTC (permalink / raw)
To: grub-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2013-12-19 16:31 joe fresh
2013-12-19 18:18 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-12-19 22:54 ` Chris Murphy
1 sibling, 0 replies; 13+ messages in thread
From: Chris Murphy @ 2013-12-19 22:54 UTC (permalink / raw)
To: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
@ 2014-01-16 16:56 joe faith
0 siblings, 0 replies; 13+ messages in thread
From: joe faith @ 2014-01-16 16:56 UTC (permalink / raw)
To: The development of GNU GRUB, grub-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
@ 2014-01-17 2:13 joe faith
2014-01-17 4:55 ` Chris Murphy
0 siblings, 1 reply; 13+ messages in thread
From: joe faith @ 2014-01-17 2:13 UTC (permalink / raw)
To: The development of GNU GRUB
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2014-01-17 2:13 joe faith
@ 2014-01-17 4:55 ` Chris Murphy
0 siblings, 0 replies; 13+ messages in thread
From: Chris Murphy @ 2014-01-17 4:55 UTC (permalink / raw)
To: The development of GNU GRUB
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
@ 2014-01-17 12:01 joe faith
2014-01-21 18:02 ` Chris Murphy
0 siblings, 1 reply; 13+ messages in thread
From: joe faith @ 2014-01-17 12:01 UTC (permalink / raw)
To: The development of GNU GRUB
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Allow separate boot block and core.img location?
2014-01-17 12:01 joe faith
@ 2014-01-21 18:02 ` Chris Murphy
2014-01-22 14:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 13+ messages in thread
From: Chris Murphy @ 2014-01-21 18:02 UTC (permalink / raw)
To: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-01-22 14:57 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-16 19:36 [RFC] Allow separate boot block and core.img location? Andrey Borzenkov
-- strict thread matches above, loose matches on Subject: below --
2013-12-19 10:28 joe fresh
2013-12-19 14:34 ` Lennart Sorensen
2014-01-16 21:04 ` Chris Murphy
2013-12-19 16:31 joe fresh
2013-12-19 18:18 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-19 22:54 ` Chris Murphy
2014-01-16 16:56 joe faith
2014-01-17 2:13 joe faith
2014-01-17 4:55 ` Chris Murphy
2014-01-17 12:01 joe faith
2014-01-21 18:02 ` Chris Murphy
2014-01-22 14:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).