All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.