All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock
Date: Sun, 18 Oct 2009 18:44:57 +0200	[thread overview]
Message-ID: <4ADB4609.7030103@gmail.com> (raw)
In-Reply-To: <2e59e6970910170912h332e1077n2fc26afb4bd64928@mail.gmail.com>

richardvoigt@gmail.com wrote:
> On Sat, Oct 17, 2009 at 7:09 AM, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>   
>> Robert Millan wrote:
>>     
>>> On Sat, Oct 17, 2009 at 01:43:37PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>>
>>>       
>>>> Robert Millan wrote:
>>>>
>>>>         
>>>>> On Sat, Oct 17, 2009 at 12:18:05AM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>>>>
>>>>>
>>>>>           
>>>>>>  2009-10-16  Vladimir Serbinenko  <phcoder@gmail.com>
>>>>>>
>>>>>> +  * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS superblock.
>>>>>> +  (options): New option --destroy-xfs.
>>>>>> +  (main): Handle --destroy-xfs.
>>>>>>
>>>>>>
>>>>>>             
>>>>> I gave this some more thought, and I think this could be less ad-hoc.  We're
>>>>> treating XFS as if it were a "weird", unique thing just because it isn't biased
>>>>> towards DOS-style boot like most filesystems are.
>>>>>
>>>>> Instead, I've done something more generic, using our standard filesystem
>>>>> probing engine which should be more reliable than a single memcmp.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> The danger is that fs_probe may reject filesystem as valid just because
>>>> it's newer than expected.
>>>>
>>>>         
>>> What do you mean with "reject filesystem as valid"?
>>>
>>>
>>>       
>> Sorry for being unclear. I just meant that if some XFS structures are
>> updated then our xfs driver won't recognise it as xfs
>>     
>
>
> Then instead of blacklisting xfs, why not whitelist filesystems which
> are known to have usable blocks for embedding (doesn't the number of
> blocks vary with filesystem anyway?) and an override parameter
> (--into-unrecognized-fs).
>
>   
In long term it's the best possibility but in this case we're too near
to a release. What I want is just to avoid XFS pitfall many users may
step into
>> --
>> Regards
>> Vladimir 'phcoder' Serbinenko
>> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>     
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 




  reply	other threads:[~2009-10-18 16:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-16 10:56 [PATCH] Refuse to install on XFS destroying its superblock Vladimir 'phcoder' Serbinenko
2009-10-16 14:03 ` Vladimir 'phcoder' Serbinenko
2009-10-16 16:01   ` Jordi Mallach
2009-10-16 18:38     ` Robert Millan
2009-10-16 20:09       ` Vladimir 'phcoder' Serbinenko
2009-10-16 20:52         ` Robert Millan
2009-10-16 21:08           ` Vladimir 'phcoder' Serbinenko
2009-10-16 21:53             ` Robert Millan
2009-10-16 22:18               ` Vladimir 'phcoder' Serbinenko
2009-10-17 11:25                 ` Robert Millan
2009-10-17 11:43                   ` Vladimir 'phcoder' Serbinenko
2009-10-17 12:00                     ` Robert Millan
2009-10-17 12:06                       ` Felix Zielcke
2009-10-17 12:09                       ` Vladimir 'phcoder' Serbinenko
2009-10-17 16:12                         ` richardvoigt
2009-10-18 16:44                           ` Vladimir 'phcoder' Serbinenko [this message]
2009-10-18 15:46                         ` Robert Millan
2009-10-18 16:30                           ` Vladimir 'phcoder' Serbinenko
2009-10-20 10:18                             ` Robert Millan
2009-10-20 10:51                               ` Vladimir 'phcoder' Serbinenko
2009-10-25  0:01                                 ` Robert Millan

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=4ADB4609.7030103@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.