All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock
Date: Fri, 16 Oct 2009 23:53:43 +0200	[thread overview]
Message-ID: <20091016215343.GA9378@thorin> (raw)
In-Reply-To: <4AD8E0CF.9080509@gmail.com>

On Fri, Oct 16, 2009 at 11:08:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> > On Fri, Oct 16, 2009 at 10:09:41PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >   
> >> Robert Millan wrote:
> >>     
> >>> On Fri, Oct 16, 2009 at 06:01:56PM +0200, Jordi Mallach wrote:
> >>>   
> >>>       
> >>>> On Fri, Oct 16, 2009 at 04:03:01PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >>>>     
> >>>>         
> >>>>> +  if (memcmp (tmp_img, "XFSB", 4) == 0)
> >>>>> +    grub_util_error ("Can't install on XFS.");
> >>>>>       
> >>>>>           
> >>>> Can this error message give some more detail on what the problem is?
> >>>>     
> >>>>         
> >>> I suggest something like:
> >>>
> >>>   grub_util_warn ("Refusing to overwrite XFS meta-data.");
> >>>
> >>> This is more informative, and with grub_util_warn() user has an opportunity to
> >>> override it if she knows what she's doing.
> >>>
> >>>   
> >>>       
> >> Installing with blocklists/to partition is considered
> >> backward-compatibility feature. We never supported a config with XFS why
> >> we would want bw-compat for it?
> >>     
> >
> > Because we can't reliably tell if it's a config with XFS, only the user can.
> > This is an issue for both MBR or PBR installs.
> >
> > Maybe "XFSB" is only a remnant from one of this disk / partition former
> > lifes.  Maybe it's a valid XFS but user no longer cares about it.  Or
> > maybe a DOS-style label was created on top of it, without overwriting the first
> > 440 bytes.  Or maybe another filesystem had overwritten most XFS metadata
> > but preserved the first block (this is conceivable since other filesystems
> > tend to avoid using the first block).
> >
> > If user has to workaround GRUB heuristics by dd'ing zeros into a partition
> > before running grub-install, this is a sign GRUB isn't doing the right thing.
> >
> >   
> Well, ok. But then I would ask to use a separate --force e.g.
> --force-destroy-xfs since users and distributions tend to use --force
> too much

Ok.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



  reply	other threads:[~2009-10-16 21:53 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 [this message]
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
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=20091016215343.GA9378@thorin \
    --to=rmh@aybabtu.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.