grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Guidance on conflicts between GNU GRUB and proprietary software
Date: Tue, 28 Sep 2010 23:34:06 +0200	[thread overview]
Message-ID: <4CA25F4E.1050800@gmail.com> (raw)
In-Reply-To: <20100928211536.GW8579@caffeine.csclub.uwaterloo.ca>

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

On 09/28/2010 11:15 PM, Lennart Sorensen wrote:
> On Tue, Sep 28, 2010 at 10:58:31PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> On 09/28/2010 10:07 PM, Lennart Sorensen wrote:
>>     
>>> On Tue, Sep 28, 2010 at 09:43:25PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>   
>>>       
>>>> GPT has new types.
>>>>     
>>>>         
>>> GPT has an msdos partition type for itself for use in hybrid setups.
>>> I know GPT partition tables have new types, but GPT itself has a type
>>> reserved in the old dos partition table.
>>>   
>>>       
>> You probably mean the 0xee type. But it's used only to mark the whole
>> space as used. In our case it's a partition which is identified to have
>> all the data deleted. Let's just take a famous collision between Solaris
>> and Linux swap. I doubt that any of them willingly choose the type in
>> order to collide with other. If Linux relied solely on the partition
>> type to identify its swap it would be a disaster for dual-boot system.
>>     
>  
> Certainly true. Now there clearly are unused types.
Rather "not widely known to be used".
>   On the other
> hand given the lack of partition entries in the first place, needing a
> partition isn't very convinient at all.  
I never said "replace current method with another one" but "add another
one as an option"
> It might be a nice option to
> support though.  Of course I doubt anything prevents the user of a
> partition for grub already, given you could use an MBR that just goes
> to the active partition (ie: standard DOS/Windows behaviour), and then
> have grub be on that active partition, whatever the type may be.
>
>   
You confuse /boot and embedding.
>> Destroying the data which is on its rightful place is bad independently
>> what you use the place for, how important your usage is or how
>> "unimportant" you judge the current occupant.
>>     
> Well grub should only install where someone tells it to.
>
>   
You confuse again. Where boot code goes is specificied on command line.
Embedding zone is chosed in function of partition map. See "Re:
[grub-setup] New procedure to choose the embedding area" on 09/15/2010
10:11 PM +0200
>> I believe it's possible to have something something much more reliable.
>> We could have a tool grub-mkembed (analog of mkswap) which would mark
>> the partition as available for GRUB embedding (perhaps in addition of
>> checking type). This signature must be written in a way to be
>> overwritten when formatted in known filesystems
>>     
> Not sure you can pick a place and be certain all filesystems will
> overwrite it on format.  You can try, but it won't always work.
>
>   
We can put multiple signatures.
>>>> GRUB has a design principle of being cross-platform installable.
>>>> Moreover the same disk can contain multiple grub installation. I
>>>> personally regularly move the disk between yeeloong and amd64 laptop,
>>>> well it has only one GRUB since on yeeloong my GRUB is in flash but it
>>>> could easily have one on disk too.
>>>>     
>>>>         
>>> If two architectures expect sector 0 to contain boot code, then that
>>> can't work.  I certainly would not consider that a worthy design goal
>>> compared to lots of other things.
>>>
>>>   
>>>       
>> Some architestures are incompatible because of such reasons but many
>> others don't conflict in such ways.
>> When you abandon a design goal or give an exception you first have to
>> make sure that there is no way to reconcile the given features.
>>     
> Nice to support if possible, although given how short on partitions you
> are already with msdos partitions is really seems futile.
>
>   
Logical partitions are fine for most platforms.
>> Just one example: I'm ready to give an exception to multiterm design in
>> order to get the features required for ubuntu CDs but first I discussed
>> in order to find compromise which would result in less mess on codepath
>> intersections and it looks like there is actually one.
>> In this case taking PReP partition type would be unfounded.
>>     
> Well I think using a partition at all in the case of the msdos partition
> table is a huge inconvinience to people, and I suspect many won't be
> able to.
>
> it has become annoyingly common to see:
>
> System restore partition
> Windows System partition
> Windows partition
>
> That leaves one primary partition on a typical system these days.  So to
> make more than one partition, that one has to be extended.  Now where
> can grub go?
>
>   
Logical partition for embedding is fine too.
> If the system maker had been nice, they would have used GPT instead and
> those 3 partitions would not have been a problem.  But of course windows
> doesn't know how to boot from GPT on a normal BIOS based system (unlike
> most other OSs that have no such problem).
>   
see "gptsync"
> If people are dual booting, using the track 0 area may be a bad thing.
> Unfortunately people that a dual booting are most likely to have partition
> limitations making it the only option that works.
>
>   
s,people dualbooting, people having crapware + some other cases.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

  reply	other threads:[~2010-09-28 21:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-23 22:19 Guidance on conflicts between GNU GRUB and proprietary software Colin Watson
2010-09-24  0:27 ` Lennart Sorensen
2010-09-24 14:09   ` Richard Stallman
2010-09-28  4:44     ` richardvoigt
2010-09-28  4:55       ` Bogdan
2010-09-28  8:04         ` Colin Watson
2010-09-28  9:10           ` Bogdan
2010-09-28  9:41             ` Colin Watson
2010-09-28  9:51               ` Bogdan
2010-09-28 10:25                 ` Colin Watson
2010-09-28 10:40                   ` Bogdan
2010-09-28 11:49                     ` Colin Watson
2010-09-28 14:50             ` Lennart Sorensen
2010-09-28 15:05               ` Bogdan
2010-09-28 18:18               ` Grub2 Install Image Dee Sharpe
2010-09-28 21:45                 ` Dmitry Ilyin
2010-09-28 15:40           ` Guidance on conflicts between GNU GRUB and proprietary software Phillip Susi
2010-09-28 16:18             ` Colin Watson
2010-09-28 17:52               ` Phillip Susi
2010-09-28 19:05           ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-28 19:15             ` Lennart Sorensen
2010-09-28 19:43               ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-28 20:07                 ` Lennart Sorensen
2010-09-28 20:58                   ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-28 21:15                     ` Lennart Sorensen
2010-09-28 21:34                       ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-09-28 19:22             ` Phillip Susi
2010-09-28 21:46             ` Grégoire Sutre
2010-09-28 22:11               ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-29 10:00                 ` Grégoire Sutre
2010-09-28 19:11           ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-28 14:57       ` Lennart Sorensen
2010-09-28  9:01     ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-09-24 10:57 ` Brendan Trotter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CA25F4E.1050800@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).