Re: is it possible to add a new filter to detect unusable partition types

[Zdenek Kabelac <zdenek.kabelac@gmail.com>]

Dne 19. 12. 24 v 5:48 Michael Chang napsal(a):
> On Wed, Dec 18, 2024 at 06:05:54PM +0100, Thomas Weißschuh wrote:
>> On 2024-12-18 15:44:45+0100, Karel Zak wrote:
>>> On Wed, Dec 18, 2024 at 11:12:59AM GMT, Zdenek Kabelac wrote:
>>
>> [..]
>>
>>>> And in the same way blkid should expose installed grub loader - currently
>>>> the partition with installed grub looks 'empty' with blkid....
>>>
>>> The issue I see is that boot loaders can coexist with filesystems on
>>> the same device. This can lead to unexpected warnings when attempting
>>> to view the contents of the device using mkfs tools.
>>
>> Isn't this specifically about the grub second stage on GPT systems
>> inside a dedicated partition?
> 
> Yes, GPT has no unallocated space similar to the MBR gap in the MSDOS
> partition table that can be repurposed for grub second stage, therefore
> a dedicated partition has to be defined and allocated. A similar scheme
> is also used in PowerPC, where a dedicated firmware PReP boot partition
> must be allocated for the boot code.

Hi

Yep - it's obvious grub needs to have a space to store its data.
In fact if a device would be 'just & only' a PV, such a PV actually has 
prepared empty space to be consumed by grub - (see  'pvcreate 
--bootloaderareasize)  - which probably never reached its audience - so when 
the user is using PV lvm2 he should not need a special dedicated partition 
(theoretically).

But all that is said here is that choosing some 'random' GUID GPT partition 
type really doesn't change anything in Linux - all tools in Linux are scanning 
content of device - checking for  'partition type' is highly unusual and 
pretty much undefined.

So the focus should go to blkid being able to report that device is occupied 
by some content.

> 
>> There should be no valid coexistence with a filesystem.
>>
>> So having a probe in blkid looks reasonable to me.

Speaking of this - there was use in old ages (and I believe it's still support 
by lvm2) the usage of a PV & MBR at the same time (it's also the reason why 
the PV header is storing it's LABELONE on 2nd. sector (512b)

This has also caused some troubles in past to properly identify device content.

Also blkid already can identify multiple signatures on the same device so it's 
just about the priority which one will be then shown by 'udev' as primary.
lvm2 also checks and clears all signatures one-by-one...

>>
>> Not that it helps in the specific case mentioned above, where everybody
>> is using --force anyways.
> 
> That's the reason I think adding such a check in grub-install doesn't
> help at all. After adding the check, I believe the tools managing the
> bootloader installation will start to use wipefs or enforce --force to
> grub-install to make sure no leftover can get in the way. In that sense,
> it seems like unnecessary breaking change to the toolings.

I guess we may not move forward with this logic...
(aka it's ok change lvm2 to not wipe, but it's fine grub will overwrite anything)

lvm2 is for long time trying to advocate against using '--force' regularly.
In some cases we've introduced even 2nd. --force required to be entered if the 
compatibility usage would be broken otherwise.

Thus the proper logic should be that some 'operations' that currently do need 
--force  - may have it's own dedicated option - i.e. in my case  grub usually 
doesn't really like to store it's data on the partition in use - so maybe 
there can be an option just for this aka --in-use-is-ok y|n

Similarly lvm2 has  'pvcreate --zero y'  to clear device content 
unconditionally - so there is no need to use --force for such case - although 
it takes time to teach other tools to use options the right way....

Regard

Zdenek