From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>,
Glass Su <glass.su@suse.com>, Heming Zhao <heming.zhao@suse.com>
Cc: "linux-lvm@lists.linux.dev" <linux-lvm@lists.linux.dev>,
mchang@suse.com, grub-devel@gnu.org, util-linux@vger.kernel.org
Subject: Re: is it possible to add a new filter to detect unusable partition types
Date: Tue, 17 Dec 2024 15:32:50 -0500 [thread overview]
Message-ID: <Z2HgqxuHQ0elvy8T@itl-email> (raw)
In-Reply-To: <ec0d03c0-40b0-4719-a020-9bae7a3241ec@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]
On Tue, Dec 17, 2024 at 11:21:26AM +0100, Zdenek Kabelac wrote:
> Dne 17. 12. 24 v 10:13 Glass Su napsal(a):
> >
> > > On Dec 17, 2024, at 16:34, Heming Zhao <heming.zhao@suse.com> wrote:
> > >
> > > Hi LVM2 maintainers,
> > >
> > > One of SUSE's customers encountered an issue with LVM2. The user created several partitions, one of which was marked as "BIOS boot" (4) instead of "LINUX LVM" (8E). Subsequently, the user ran pvcreate/vgcreate/lvcreate on this partition. During a system update, grub2-install installed GRUB2 in the "BIOS boot" partition, resulting in LVM2 metadata corruption.
> > >
> > > The root cause of this issue is that grub2-install targets the "BIOS boot" partition when this lvm2 device is specified for installation. If the user had initially marked the partition as "LINUX LVM", grub2-install would not have chosen this partition.
> > >
> > > On the other hand, it would be beneficial if LVM2 could implement a new filter or a filter function to detect and exclude the "BIOS boot" partition from being considered a valid target for LVM2 device creation. This could involve issuing a warning or error message to alert the user of the potential conflict. This may also help user to notice the issue more easily.
>
> Hi
>
> lvm2 is using blkid to detect 'present' signature on a block device - and
> normally prompt to confirm wiping such signature.
>
> We may possibly add similar logic for 'partition signatures'.
>
> However there is still the plain fact that lvm2 with --force or even just
> '--yes' option is assumed to simply proceed and clean&clear such
> conflicting signatures and simply makes the block device to be a PV.
>
> All that said IMHO primary bug here is within 'grub2-install' which simply
> should not be blindingly overwriting block device which is in use - this
> should be fixed ASAP as there is the biggest risk of data loss, although I
> guess everyone is using 'grub2-install --force' - as without this option
> (even in my personal experience) is typically refusing to do any work....
>
> And same applies to most UI tools I've seen that use lvm2 - all seem to be
> pushing '--force & --yes' with each it emitted lvm2 command...
If prompts were in a machine-parsable format, tools that used lvm2 could
differentiate between ones that should automatically be responded to
with "yes" and ones that should not.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-12-17 20:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 8:34 is it possible to add a new filter to detect unusable partition types Heming Zhao
2024-12-17 9:13 ` Glass Su
[not found] ` <43D73CB9-32E4-405E-93A9-E985C94F4A9E__33327.0934455626$1734427189$gmane$org@suse.com>
2024-12-17 10:21 ` Zdenek Kabelac
2024-12-17 12:45 ` Michael Chang
2024-12-17 20:32 ` Demi Marie Obenour [this message]
[not found] ` <yjiu3c3e4aknayawhw7lw52kev6fvp4wm6n6wte4t27hx3fr4u__21682.4523567752$1734439545$gmane$org@cc5bu2ij2ia3>
2024-12-18 10:12 ` Zdenek Kabelac
2024-12-18 14:44 ` Karel Zak
2024-12-18 17:05 ` Thomas Weißschuh
2024-12-19 4:48 ` Michael Chang
[not found] ` <jcqrtifxjk2adtngyykvyoffh6ab3twulqra4ugq7satddqob7__49168.7655843393$1734583719$gmane$org@rngyhl7nuyhk>
2024-12-19 10:50 ` Zdenek Kabelac
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=Z2HgqxuHQ0elvy8T@itl-email \
--to=demi@invisiblethingslab.com \
--cc=glass.su@suse.com \
--cc=grub-devel@gnu.org \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@lists.linux.dev \
--cc=mchang@suse.com \
--cc=util-linux@vger.kernel.org \
--cc=zdenek.kabelac@gmail.com \
/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).