grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Refuse to install on XFS destroying its superblock


From: address@hidden
Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock
Date: Sat, 17 Oct 2009 11:12:28 -0500

On Sat, Oct 17, 2009 at 7:09 AM, Vladimir 'phcoder' Serbinenko
<address@hidden> 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  <address@hidden>
>>>>>
>>>>> +  * 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).

>
>
> --
> Regards
> Vladimir 'phcoder' Serbinenko
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]