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
