* Re: is it possible to add a new filter to detect unusable partition types
From: Michael Chang @ 2024-12-19 4:48 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Karel Zak, Zdenek Kabelac, Glass Su, Heming Zhao,
linux-lvm@lists.linux.dev, grub-devel, util-linux
In-Reply-To: <860960db-bb66-453c-a392-1495690bb2ff@t-8ch.de>
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.
See Also:
https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation
> There should be no valid coexistence with a filesystem.
>
> So having a probe in blkid looks reasonable to me.
>
> 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.
Thanks,
Michael
>
>
> Thomas
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Thomas Weißschuh @ 2024-12-18 17:05 UTC (permalink / raw)
To: Karel Zak
Cc: Zdenek Kabelac, Michael Chang, Glass Su, Heming Zhao,
linux-lvm@lists.linux.dev, grub-devel, util-linux
In-Reply-To: <hdqz3hun3f5ftfwvimlopkmuujimtz5ilovkuajqesy6p4a7jd@7w6nkryhr2y7>
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?
There should be no valid coexistence with a filesystem.
So having a probe in blkid looks reasonable to me.
Not that it helps in the specific case mentioned above, where everybody
is using --force anyways.
Thomas
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Karel Zak @ 2024-12-18 14:44 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Michael Chang, Glass Su, Heming Zhao, linux-lvm@lists.linux.dev,
grub-devel, util-linux
In-Reply-To: <dbc7728b-352b-4982-a171-d8f177388a19@gmail.com>
On Wed, Dec 18, 2024 at 11:12:59AM GMT, Zdenek Kabelac wrote:
> Sorry to say this, but the fact the 'someone' has created 'GUID' for GPT
> with the name 'BIOS boot' doesn't really make anything in the Linux world -
> so far I was not even aware such partition type exists (not using this
> myself).
Yes, partition types are a legacy from the previous century. They have
very limited relevance in today's world. They may make sense for
things like firmwares or Systemd Discoverable Partitions, but in most
cases, it is only the device content that matters. It is important to
note that we have no way of synchronizing device content and device
types. Additionally, for Linux, device types have had no meaning since
the beginning.
> Well protection needs to be from all sides here - otherwise it makes no
> sense. When the grub sees some signature, it must be telling to a user and
> not just let user to loose his data blindly.
Yes, this behavior should be standard for all mkfs-like and
partitioning tools. The use of --force should be required in order to
perform any potentially risky actions.
> 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.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Zdenek Kabelac @ 2024-12-18 10:12 UTC (permalink / raw)
To: Michael Chang
Cc: Glass Su, Heming Zhao, linux-lvm@lists.linux.dev, grub-devel,
util-linux
In-Reply-To: <yjiu3c3e4aknayawhw7lw52kev6fvp4wm6n6wte4t27hx3fr4u__21682.4523567752$1734439545$gmane$org@cc5bu2ij2ia3>
Dne 17. 12. 24 v 13:45 Michael Chang napsal(a):
> 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....
>
> IMHO, the BIOS Boot partition is dedicated to grub boot code and cannot
> be shared with other software. Any attempt other than grub writing to
Hi
Sorry to say this, but the fact the 'someone' has created 'GUID' for GPT with
the name 'BIOS boot' doesn't really make anything in the Linux world - so far
I was not even aware such partition type exists (not using this myself).
It's never even been submitted to lvm2 as something to be understood by tool
till this thread.
There are over 220 types shown by 'cfdisk' just for GPT and there is a
completely different set for DOS partition types...
So how should we know which type is lvm2 allowed to 'use' freely ?
Should we now store somewhere those 'hundreds' GUID where there is something
with Linux in its name ?
I don't think this is a practical thing to do in lvm2 nor in many other
userland tools that are doing something with block devices.
There should likely be something in blkid telling other Linux tools 'don't
touch this device unless you are XYZ' eventually you use some --force override
option.
> For LVM root with legacy BIOS boot, having a BIOS Boot partition is
> mandatory, otherwise grub won't have usable space to embed the boot code
> in the GPT partition layout, and you won't be able to boot or access a
> functional system in the first place. That said, the BIOS Boot partition
> is in use by grub before it is mistakenly used to create a PV and extend
> the LVM root onto it. It is unlikely that GRUB is overwriting it. In
> such cases, it's more likely the other way around.
Well protection needs to be from all sides here - otherwise it makes no sense.
When the grub sees some signature, it must be telling to a user and not just
let user to loose his data blindly.
And in the same way blkid should expose installed grub loader - currently the
partition with installed grub looks 'empty' with blkid....
Regards
Zdenek
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Demi Marie Obenour @ 2024-12-17 20:32 UTC (permalink / raw)
To: Zdenek Kabelac, Glass Su, Heming Zhao
Cc: linux-lvm@lists.linux.dev, mchang, grub-devel, util-linux
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 --]
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Michael Chang @ 2024-12-17 12:45 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Glass Su, Heming Zhao, linux-lvm@lists.linux.dev, grub-devel,
util-linux
In-Reply-To: <ec0d03c0-40b0-4719-a020-9bae7a3241ec@gmail.com>
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....
IMHO, the BIOS Boot partition is dedicated to grub boot code and cannot
be shared with other software. Any attempt other than grub writing to
this area should be prohibited, it should not be the other way around.
Furthermore, adding such check could lead to unexpected failures if the
data is a leftover.
Grub does not write blindly, it checks that the partition is indeed a
BIOS Boot partition before writing to it, as the user is required to
explicitly set the partition type.
For LVM root with legacy BIOS boot, having a BIOS Boot partition is
mandatory, otherwise grub won't have usable space to embed the boot code
in the GPT partition layout, and you won't be able to boot or access a
functional system in the first place. That said, the BIOS Boot partition
is in use by grub before it is mistakenly used to create a PV and extend
the LVM root onto it. It is unlikely that GRUB is overwriting it. In
such cases, it's more likely the other way around.
Thanks,
Michael
>
> 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...
>
> Regards
>
> Zdenek
>
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Zdenek Kabelac @ 2024-12-17 10:21 UTC (permalink / raw)
To: Glass Su, Heming Zhao
Cc: linux-lvm@lists.linux.dev, mchang, grub-devel, util-linux
In-Reply-To: <43D73CB9-32E4-405E-93A9-E985C94F4A9E__33327.0934455626$1734427189$gmane$org@suse.com>
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...
Regards
Zdenek
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Glass Su @ 2024-12-17 9:13 UTC (permalink / raw)
To: Heming Zhao; +Cc: linux-lvm@lists.linux.dev, mchang, grub-devel, util-linux
In-Reply-To: <826b5136-7ee1-4664-98d6-a3441883f53e@suse.com>
> 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.
>
> Best regards,
> Heming
Also Cc util-linux@vger.kernel.org and grub-devel@gnu.org as it’s not an issue with lvm but also other fs progs.
It would be great if we can enhance libblkid to avoid data loss even caused by user mistakes.
—
Su
^ permalink raw reply
* Re: [PATCH] tests: add skips when IPv6 is not supported
From: Karel Zak @ 2024-12-16 10:47 UTC (permalink / raw)
To: LiviaMedeiros; +Cc: util-linux, LiviaMedeiros
In-Reply-To: <2097ed76-2ed6-40da-9912-01774316370f@cirno.name>
On Fri, Dec 13, 2024 at 08:38:27PM GMT, LiviaMedeiros wrote:
> tests/functions.sh | 6 ++++++
> tests/ts/lsfd/mkfds-tcp6 | 1 +
> tests/ts/lsfd/mkfds-udp6 | 1 +
> tests/ts/lsfd/option-inet | 1 +
> 4 files changed, 9 insertions(+)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: v2.40.3 plan
From: Karel Zak @ 2024-12-16 10:17 UTC (permalink / raw)
To: Chris Hofstaedtler; +Cc: util-linux
In-Reply-To: <tcyqzu65my54wgqt4twjcdtb5vayvoojareuzkfnbx6pev7osa@lhea5femzoia>
Hi Chris,
On Tue, Dec 10, 2024 at 04:03:49PM GMT, Chris Hofstaedtler wrote:
> I think it would be nice to add the following three commits from
All three commits were cherry-picked to the stable branch. Thank you
for the suggestion.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Theodore Ts'o @ 2024-12-15 3:20 UTC (permalink / raw)
To: Demi Marie Obenour; +Cc: Karel Zak, util-linux
In-Reply-To: <d1ad846b-def1-403d-be62-aac78e06fdc3@gmail.com>
On Sat, Dec 14, 2024 at 05:08:54PM -0500, Demi Marie Obenour wrote:
> > From what I can tell, the Discoverable Partition Table specification,
> > at least as defined here[1] only supports explicit file system types
> > supplied by the GPT partition table.
> >
> > [1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
>
> It’s the other way around: the GPT only provides the mountpoint,
> never the type. That’s why I filed an issue [1] asking for
> per-filesystem-type UUIDs.
Bleah, you're right. Other partition tables, including MBR(!) used
the "partiton type" to be the kind of file system. (For example,
0x07h meant OS/2, 0x09 meant QNX/Coherent/OS-9, 0x0Bh meant FAT32 with
CHS addressing, 0x0Ch meat FAT32 with LBA, 39h meant Plan9, etc.)
When I saw "partition type" in the UEFI spec, I thought they were
seeing the path of wisdom and moving away from in-band signaling to an
explicit type specification --- but you're right, looking at the UEFI
spec more closely, it's about how the file system is to be used, not
the file system type.
(It's really not even the mount point, since
773f91ef-66d4-49b5-bd83-d683bf40ad16 means "per-user home partition",
but since the UUID doesn't specify the username, you would't know
whether it was supposed to be mounted in /home/lucy, or /home/snoopy,
or /home/charlie_brown. Yelch....)
> I’m not too worried about this, and instead am of the opinion that it
> needs to be fixed on the blkid side (by ignoring the ZFS superblock).
I disagree; blkid's *job* is to detect the file system type, and just
ignoring all ZFS superblocks means that it won't be able to detect ZFS
file systems, which would be sad. And having some kind of arbitrary
preference where blkid were to say, "well, if it's ambiguous whether a
block device is ext4 or btrfs or ZFS, I'll just arbitrarily say ext4
because I like ext4 more" is well, arbitrary.
The best way to solve this is to either have users use "wipefs -a
/dev/hdXX" before running a mkfs program, but in the spirit of being
kind to users[1] who don't know about wipefs, or for distro installers
that don't bother to call wipefs, I'm perfectly happy to teach
mkfs.ext4 how to make the right thing happen automatically. I just
need to know how to zap ZFS superbloks.
BTW, in practice this happens automatically for SSD's, since we will
call BLKDISCARD on the entire device, for better FTL GC performance.
But for HDD's, we will need to explicitly write zeroes in the correct
location.
Cheers,
- Ted
[1] Using a variation from Struck and White's "The Elements of Style"
where they said, "always write with a deep empathy towards the
reader", we should strive to program with deep empathy towards the
user. :-)
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Demi Marie Obenour @ 2024-12-14 22:08 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Karel Zak, util-linux
In-Reply-To: <20241211133808.GB1912640@mit.edu>
On 12/11/24 8:38 AM, Theodore Ts'o wrote:
> On Tue, Dec 10, 2024 at 06:28:28PM -0500, Demi Marie Obenour wrote:
>>>> Was https://github.com/util-linux/util-linux/issues/1305 a
>>>> collision between ZFS and ext4?
>>>
>>> Yes, but in this case, ZFS was incorrectly detected. As you can see
>>> from the bug report, blkid ended with an "ambiguous result" error.
>
> mke2fs (mkfs.ext4) does attempt to zero the typical locations where
> conflicting superblocks might be found. The ext4 metadata is located
> at the beginning of the file system, except for the first 1k, which we
> leave zero out on all platforms except for Sparc (the exact reason is
> lost in the midsts of time, since it pre-exists git, but as I recall
> Sparc had something critical that would cause its BIOS to lose its
> marbles if we zeroed it out), and we also zero out the very end of the
> disk where the MD superblock is located.
>
> It sounds like ZFS is putting its superblock someplace random that
> mke2fs ext4 doesn't know about. If someone wants to do the research
> to let me know what needs to be zeroed out to zap the ZFS superblock,
> please feel to file a bug against e2fsck (or better yet, send me a
> patch :-P ) and I'll be happy to add support for it.
I’m not too worried about this, and instead am of the opinion that it
needs to be fixed on the blkid side (by ignoring the ZFS superblock).
>>>> /etc/fstab provides an explicit filesystem type. The Discoverable
>>>> Partition Specification doesn't.
>
> From what I can tell, the Discoverable Partition Table specification,
> at least as defined here[1] only supports explicit file system types
> supplied by the GPT partition table.
>
> [1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
It’s the other way around: the GPT only provides the mountpoint,
never the type. That’s why I filed an issue [1] asking for
per-filesystem-type UUIDs.
[1]: https://github.com/uapi-group/specifications/issues/132
> My personal preference is this *is* the best way to do things; the
> main reason why we have blkid is because of the disaster which is the
> MSDOS FAT partition table, where there was only a single byte used for
> the partition type, that (a) was largely ignored by other x86
> operating systems, and (b) wasn't under our control, so we couldn't
> define a new partition type each time we introduced a new Linux file
> system.
>
> In general, having explicit file system types, whether it is in
> /etc/fstab, or in the GPT partition table, is the better way to go.
> Using blkid is ideally the fallback when the best possible way doesn't
> work, since it will ultimately always be a "best efforts" sort of
> thing.
Thanks for confirming what I expected.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: [PATCH] tests: add skips when IPv6 is not supported
From: Masatake YAMATO @ 2024-12-13 16:05 UTC (permalink / raw)
To: 9; +Cc: util-linux, livia
In-Reply-To: <2097ed76-2ed6-40da-9912-01774316370f@cirno.name>
From: LiviaMedeiros <9@cirno.name>
Subject: [PATCH] tests: add skips when IPv6 is not supported
Date: Fri, 13 Dec 2024 20:38:27 +0800
> From: LiviaMedeiros <livia@cirno.name>
>
> Before this change on systems with disabled IPv6 (e.g. `CONFIG_IPV6 is
> not set` in kernel config), `lsfd/mkfds-tcp6` and `lsfd/mkfds-udp6`
> were failing, and `lsfd/option-inet` was hanging forever, making it
> impossible to complete the tests.
>
> Signed-off-by: LiviaMedeiros <livia@cirno.name>
> ---
> tests/functions.sh | 6 ++++++
> tests/ts/lsfd/mkfds-tcp6 | 1 +
> tests/ts/lsfd/mkfds-udp6 | 1 +
> tests/ts/lsfd/option-inet | 1 +
> 4 files changed, 9 insertions(+)
>
> diff --git a/tests/functions.sh b/tests/functions.sh
> index 630166871..add50440b 100644
> --- a/tests/functions.sh
> +++ b/tests/functions.sh
> @@ -1195,3 +1195,9 @@ function ts_check_enosys_syscalls {
> function ts_skip_docker {
> test -e /.dockerenv && ts_skip "unsupported in docker environment"
> }
> +
> +function ts_check_ipv6 {
> + if [ ! -e /proc/net/if_inet6 ]; then
> + ts_skip "IPv6 is not supported"
> + fi
> +}
> diff --git a/tests/ts/lsfd/mkfds-tcp6 b/tests/ts/lsfd/mkfds-tcp6
> index bffa630c4..414777f4a 100755
> --- a/tests/ts/lsfd/mkfds-tcp6
> +++ b/tests/ts/lsfd/mkfds-tcp6
> @@ -23,6 +23,7 @@ ts_init "$*"
> ts_check_test_command "$TS_CMD_LSFD"
> ts_check_test_command "$TS_HELPER_MKFDS"
> ts_check_native_byteorder
> +ts_check_ipv6
> ts_skip_docker
>
> ts_cd "$TS_OUTDIR"
> diff --git a/tests/ts/lsfd/mkfds-udp6 b/tests/ts/lsfd/mkfds-udp6
> index 26bdacd7c..59b1c06a2 100755
> --- a/tests/ts/lsfd/mkfds-udp6
> +++ b/tests/ts/lsfd/mkfds-udp6
> @@ -23,6 +23,7 @@ ts_init "$*"
> ts_check_test_command "$TS_CMD_LSFD"
> ts_check_test_command "$TS_HELPER_MKFDS"
> ts_check_native_byteorder
> +ts_check_ipv6
> ts_skip_docker
>
> ts_cd "$TS_OUTDIR"
> diff --git a/tests/ts/lsfd/option-inet b/tests/ts/lsfd/option-inet
> index 7ca883751..f679f121d 100755
> --- a/tests/ts/lsfd/option-inet
> +++ b/tests/ts/lsfd/option-inet
> @@ -24,6 +24,7 @@ ts_skip_docker
>
> ts_check_test_command "$TS_CMD_LSFD"
> ts_check_test_command "$TS_HELPER_MKFDS"
> +ts_check_ipv6
>
> ts_check_prog "mkfifo"
>
> --
> 2.47.1
>
Looks good to me.
Reviewed-by: Masatake YAMATO <yamato@redhat.com>
^ permalink raw reply
* [PATCH] tests: add skips when IPv6 is not supported
From: LiviaMedeiros @ 2024-12-13 12:38 UTC (permalink / raw)
To: util-linux; +Cc: LiviaMedeiros
From: LiviaMedeiros <livia@cirno.name>
Before this change on systems with disabled IPv6 (e.g. `CONFIG_IPV6 is
not set` in kernel config), `lsfd/mkfds-tcp6` and `lsfd/mkfds-udp6` were
failing, and `lsfd/option-inet` was hanging forever, making it
impossible to complete the tests.
Signed-off-by: LiviaMedeiros <livia@cirno.name>
---
tests/functions.sh | 6 ++++++
tests/ts/lsfd/mkfds-tcp6 | 1 +
tests/ts/lsfd/mkfds-udp6 | 1 +
tests/ts/lsfd/option-inet | 1 +
4 files changed, 9 insertions(+)
diff --git a/tests/functions.sh b/tests/functions.sh
index 630166871..add50440b 100644
--- a/tests/functions.sh
+++ b/tests/functions.sh
@@ -1195,3 +1195,9 @@ function ts_check_enosys_syscalls {
function ts_skip_docker {
test -e /.dockerenv && ts_skip "unsupported in docker environment"
}
+
+function ts_check_ipv6 {
+ if [ ! -e /proc/net/if_inet6 ]; then
+ ts_skip "IPv6 is not supported"
+ fi
+}
diff --git a/tests/ts/lsfd/mkfds-tcp6 b/tests/ts/lsfd/mkfds-tcp6
index bffa630c4..414777f4a 100755
--- a/tests/ts/lsfd/mkfds-tcp6
+++ b/tests/ts/lsfd/mkfds-tcp6
@@ -23,6 +23,7 @@ ts_init "$*"
ts_check_test_command "$TS_CMD_LSFD"
ts_check_test_command "$TS_HELPER_MKFDS"
ts_check_native_byteorder
+ts_check_ipv6
ts_skip_docker
ts_cd "$TS_OUTDIR"
diff --git a/tests/ts/lsfd/mkfds-udp6 b/tests/ts/lsfd/mkfds-udp6
index 26bdacd7c..59b1c06a2 100755
--- a/tests/ts/lsfd/mkfds-udp6
+++ b/tests/ts/lsfd/mkfds-udp6
@@ -23,6 +23,7 @@ ts_init "$*"
ts_check_test_command "$TS_CMD_LSFD"
ts_check_test_command "$TS_HELPER_MKFDS"
ts_check_native_byteorder
+ts_check_ipv6
ts_skip_docker
ts_cd "$TS_OUTDIR"
diff --git a/tests/ts/lsfd/option-inet b/tests/ts/lsfd/option-inet
index 7ca883751..f679f121d 100755
--- a/tests/ts/lsfd/option-inet
+++ b/tests/ts/lsfd/option-inet
@@ -24,6 +24,7 @@ ts_skip_docker
ts_check_test_command "$TS_CMD_LSFD"
ts_check_test_command "$TS_HELPER_MKFDS"
+ts_check_ipv6
ts_check_prog "mkfifo"
--
2.47.1
^ permalink raw reply related
* I urge you to understand my viewpoint accurately.
From: TCWM180122 @ 2024-12-13 4:26 UTC (permalink / raw)
To: util-linux
I am Tomasz Chmielewski, a Portfolio Manager and Chartered
Financial Analyst affiliated with Iwoca Poland Sp. Z OO in
Poland. I have the privilege of working with distinguished
investors who are eager to support your company's current
initiatives, thereby broadening their investment portfolios. If
this proposal aligns with your interests, I invite you to
respond, and I will gladly share more information to assist you.
Yours sincerely,
Tomasz Chmielewski Warsaw, Mazowieckie,
Poland.
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Theodore Ts'o @ 2024-12-11 13:38 UTC (permalink / raw)
To: Demi Marie Obenour; +Cc: Karel Zak, util-linux
In-Reply-To: <155cef10-48b4-42f0-bacf-b9e1d7394206@gmail.com>
On Tue, Dec 10, 2024 at 06:28:28PM -0500, Demi Marie Obenour wrote:
> >> Was https://github.com/util-linux/util-linux/issues/1305 a
> >> collision between ZFS and ext4?
> >
> > Yes, but in this case, ZFS was incorrectly detected. As you can see
> > from the bug report, blkid ended with an "ambiguous result" error.
mke2fs (mkfs.ext4) does attempt to zero the typical locations where
conflicting superblocks might be found. The ext4 metadata is located
at the beginning of the file system, except for the first 1k, which we
leave zero out on all platforms except for Sparc (the exact reason is
lost in the midsts of time, since it pre-exists git, but as I recall
Sparc had something critical that would cause its BIOS to lose its
marbles if we zeroed it out), and we also zero out the very end of the
disk where the MD superblock is located.
It sounds like ZFS is putting its superblock someplace random that
mke2fs ext4 doesn't know about. If someone wants to do the research
to let me know what needs to be zeroed out to zap the ZFS superblock,
please feel to file a bug against e2fsck (or better yet, send me a
patch :-P ) and I'll be happy to add support for it.
> >> /etc/fstab provides an explicit filesystem type. The Discoverable
> >> Partition Specification doesn't.
From what I can tell, the Discoverable Partition Table specification,
at least as defined here[1] only supports explicit file system types
supplied by the GPT partition table.
[1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
My personal preference is this *is* the best way to do things; the
main reason why we have blkid is because of the disaster which is the
MSDOS FAT partition table, where there was only a single byte used for
the partition type, that (a) was largely ignored by other x86
operating systems, and (b) wasn't under our control, so we couldn't
define a new partition type each time we introduced a new Linux file
system.
In general, having explicit file system types, whether it is in
/etc/fstab, or in the GPT partition table, is the better way to go.
Using blkid is ideally the fallback when the best possible way doesn't
work, since it will ultimately always be a "best efforts" sort of
thing.
That being said, I suspect that if you ask, file system maintainers
will be happy to try to make things work better --- just send us a
patch or tell us what we need to do. ZFS is not a native Linux file
system, and blkid pre-dates ZFS, so it's not something that I bothered
testing. It doesn't help that I had absolutely zero interest in
dealing with Sun deliberately making the CDDL incompatible with the
GPL, and Larry Elison potentially trying to sue us into the ground. :-)
Cheers,
- Ted
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Demi Marie Obenour @ 2024-12-10 23:28 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <y7tl6b7pviy7ubstwprmw57ubquf777orkp56h45r7ab3xjfek@t3qjqzehfwnp>
On 12/10/24 6:16 AM, Karel Zak wrote:
> On Tue, Dec 10, 2024 at 12:11:49AM GMT, Demi Marie Obenour wrote:
>> On 12/9/24 5:26 AM, Karel Zak wrote:
>>>
>>> Hi Demi,
>>>
>>> On Sat, Dec 07, 2024 at 08:45:32PM GMT, Demi Marie Obenour wrote:
>>>> Is there a guarantee that if all data before the filesystem superblock is
>>>> zero, and that the filesystem never writes to this region, libblkid (and
>>>> thus, presumably, mount(8)) will always mount the filesystem with the
>>>> correct filesystem type, even if e.g. someone writes a file containing
>>>> a superblock of a different filesystem and the filesystem happens to put
>>>> it where that superblock is valid?
>>>
>>> the libblkid library offers multiple modes, with "safe mode" being the
>>> default for detecting filesystems. In this mode, the library checks
>>> for any additional valid superblocks on the device. There are
>>> exceptions for certain filesystems on CD/DVD media (such as udf and
>>> iso), but for regular filesystems, sharing the same device is not
>>> allowed.
>>>
>>> There is also an option to specify that a superblock is only valid if
>>> no other area is using it (using blkid_probe_set_wiper() and
>>> blkid_probe_use_wiper()). However, this is only used for LVM and
>>> bcache.
>>>
>>> The library does not require that there are zeros before the
>>> superblock, as not all mkfs-like programs zero out all areas.
>>>
>>> In recent years, there have been no reports of collisions. In the
>>> entire history of the library, the only collisions I can recall are
>>> with swap areas and luks, and occasionally with poorly detected FAT
>>> filesystems (due to the messy design of FAT).
>>
>> Was https://github.com/util-linux/util-linux/issues/1305 a
>> collision between ZFS and ext4?
>
> Yes, but in this case, ZFS was incorrectly detected. As you can see
> from the bug report, blkid ended with an "ambiguous result" error.
Should blkid instead stop at the first valid superblock when probing
filesystems for mounting?
>>> I believe the situation would be the same even without the
>>> Discoverable Partition Specification. The kernel always divides the
>>> whole disk into partitions, and libblkid/mount utilizes these
>>> partitions. Therefore, the filesystems are automatically separated by
>>> the partition table.
>>
>> /etc/fstab provides an explicit filesystem type. The Discoverable
>> Partition Specification doesn't.
>
> You can use the "auto" file system type in fstab. It is also common
> for people to not use the "-t <type>" option on the mount(8) command
> line.
>
> However, if you are paranoid, then specifying the file system type in
> fstab and avoiding Discoverable Partitions is a good choice.
Does that mean that Discoverable Partitions are a bad idea for any
filesystem that is not read-only? Can you explain “if you are
paranoid”?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: v2.40.3 plan
From: Chris Hofstaedtler @ 2024-12-10 15:03 UTC (permalink / raw)
To: util-linux; +Cc: Karel Zak
In-Reply-To: <4wnkdjqtwlx5pjeknj7wqmk5bgftoyzpqijqguekcepcdyrgmn@pofpabk4awvg>
Hi Karel,
* Karel Zak <kzak@redhat.com> [241210 12:45]:
> Please refer to the following link for the current patches in the
> branch: https://github.com/util-linux/util-linux/commits/stable/v2.40/
>
> If there is anything missing or if you would like to add something to
> the release, please let me know.
I think it would be nice to add the following three commits from
master; they either apply as is or with an automatic merge done by
git:
commit 6227b2b0585ee2ccf224cf70c7144296a814a4ab
Author: Thomas Weißschuh <thomas@t-8ch.de>
AuthorDate: Tue Apr 9 11:00:26 2024 +0200
Commit: Thomas Weißschuh <thomas@t-8ch.de>
CommitDate: Tue Apr 9 11:10:16 2024 +0200
logger: correctly format tv_usec
tv_usec is an unspecified signed integer type.
The format string %u assumes an unsigned int, which is incorrect.
Especially on 32bit big-endian, where it can lead to invalid values.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/util-linux/afef1b770ad80d50660bb2c53a0a8330b88d1049.camel@physik.fu-berlin.de/
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
commit 5ebf0edb0a0531cba801c7791543c610725bf944
Author: Chris Hofstaedtler <zeha@debian.org>
AuthorDate: Tue Apr 9 10:34:59 2024 +0200
Commit: Karel Zak <kzak@redhat.com>
CommitDate: Tue Apr 9 13:48:37 2024 +0200
audit-arch.h: add defines for m68k, sh
John Paul Adrian Glaubitz points out that libseccomp needs to release 2.6.0,
too.
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Chris Hofstaedtler <zeha@debian.org>
commit 6fc5b5af4bfea4e3115cddb2c1716b3120bb3d4f
Author: Karel Zak <kzak@redhat.com>
AuthorDate: Thu Jul 11 13:26:30 2024 +0200
Commit: Karel Zak <kzak@redhat.com>
CommitDate: Thu Jul 11 13:26:30 2024 +0200
agetty: add "systemd" to --version output
Signed-off-by: Karel Zak <kzak@redhat.com>
> The next release, v2.41-rc1, is expected to be released at the end of
> December or in January.
Good to know. There is no release timeline yet for Debian trixie, so
depending on that and when you think 2.41 final might arrive, we
could ship with 2.41. If you have any input on that, please let me
know.
Thanks!
Chris
^ permalink raw reply
* v2.40.3 plan
From: Karel Zak @ 2024-12-10 11:44 UTC (permalink / raw)
To: util-linux
Hi everyone,
I would like to announce the upcoming release of stable maintenance
v2.40.3 from the stable/v2.40 branch in the next few days.
Please refer to the following link for the current patches in the
branch: https://github.com/util-linux/util-linux/commits/stable/v2.40/
If there is anything missing or if you would like to add something to
the release, please let me know.
The next release, v2.41-rc1, is expected to be released at the end of
December or in January.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Karel Zak @ 2024-12-10 11:16 UTC (permalink / raw)
To: Demi Marie Obenour; +Cc: util-linux
In-Reply-To: <114fa16d-5908-4300-96a0-23203c7470af@gmail.com>
On Tue, Dec 10, 2024 at 12:11:49AM GMT, Demi Marie Obenour wrote:
> On 12/9/24 5:26 AM, Karel Zak wrote:
> >
> > Hi Demi,
> >
> > On Sat, Dec 07, 2024 at 08:45:32PM GMT, Demi Marie Obenour wrote:
> >> Is there a guarantee that if all data before the filesystem superblock is
> >> zero, and that the filesystem never writes to this region, libblkid (and
> >> thus, presumably, mount(8)) will always mount the filesystem with the
> >> correct filesystem type, even if e.g. someone writes a file containing
> >> a superblock of a different filesystem and the filesystem happens to put
> >> it where that superblock is valid?
> >
> > the libblkid library offers multiple modes, with "safe mode" being the
> > default for detecting filesystems. In this mode, the library checks
> > for any additional valid superblocks on the device. There are
> > exceptions for certain filesystems on CD/DVD media (such as udf and
> > iso), but for regular filesystems, sharing the same device is not
> > allowed.
> >
> > There is also an option to specify that a superblock is only valid if
> > no other area is using it (using blkid_probe_set_wiper() and
> > blkid_probe_use_wiper()). However, this is only used for LVM and
> > bcache.
> >
> > The library does not require that there are zeros before the
> > superblock, as not all mkfs-like programs zero out all areas.
> >
> > In recent years, there have been no reports of collisions. In the
> > entire history of the library, the only collisions I can recall are
> > with swap areas and luks, and occasionally with poorly detected FAT
> > filesystems (due to the messy design of FAT).
>
> Was https://github.com/util-linux/util-linux/issues/1305 a
> collision between ZFS and ext4?
Yes, but in this case, ZFS was incorrectly detected. As you can see
from the bug report, blkid ended with an "ambiguous result" error.
> > I believe the situation would be the same even without the
> > Discoverable Partition Specification. The kernel always divides the
> > whole disk into partitions, and libblkid/mount utilizes these
> > partitions. Therefore, the filesystems are automatically separated by
> > the partition table.
>
> /etc/fstab provides an explicit filesystem type. The Discoverable
> Partition Specification doesn't.
You can use the "auto" file system type in fstab. It is also common
for people to not use the "-t <type>" option on the mount(8) command
line.
However, if you are paranoid, then specifying the file system type in
fstab and avoiding Discoverable Partitions is a good choice.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Ensuring that mount(8) will always interpret a filesystem correctly
From: Demi Marie Obenour @ 2024-12-10 5:11 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <zxqdvuyhtmas5apcnop7kleh2b24sboscyaosgkyqqfz4nlsdf@rmgdzivamwdw>
On 12/9/24 5:26 AM, Karel Zak wrote:
>
> Hi Demi,
>
> On Sat, Dec 07, 2024 at 08:45:32PM GMT, Demi Marie Obenour wrote:
>> Is there a guarantee that if all data before the filesystem superblock is
>> zero, and that the filesystem never writes to this region, libblkid (and
>> thus, presumably, mount(8)) will always mount the filesystem with the
>> correct filesystem type, even if e.g. someone writes a file containing
>> a superblock of a different filesystem and the filesystem happens to put
>> it where that superblock is valid?
>
> the libblkid library offers multiple modes, with "safe mode" being the
> default for detecting filesystems. In this mode, the library checks
> for any additional valid superblocks on the device. There are
> exceptions for certain filesystems on CD/DVD media (such as udf and
> iso), but for regular filesystems, sharing the same device is not
> allowed.
>
> There is also an option to specify that a superblock is only valid if
> no other area is using it (using blkid_probe_set_wiper() and
> blkid_probe_use_wiper()). However, this is only used for LVM and
> bcache.
>
> The library does not require that there are zeros before the
> superblock, as not all mkfs-like programs zero out all areas.
>
> In recent years, there have been no reports of collisions. In the
> entire history of the library, the only collisions I can recall are
> with swap areas and luks, and occasionally with poorly detected FAT
> filesystems (due to the messy design of FAT).
Was https://github.com/util-linux/util-linux/issues/1305 a
collision between ZFS and ext4?
>> The motivation for this message is that systemd-gpt-generator generates
>> mountpoints based on Discoverable Partition Specification GUIDs. These
>> indicate the mountpoint of the partition but not the filesystem type.
>
> Filesystem auto-detection is a common feature. The situation is
> similar to having an "auto" fstype in fstab. The systemd-gpt-generator
> simply identifies the partition as "/usr" (or any other mountpoint)
> and the rest is usual scenario.>
>> If a correctly-produced filesystem image will always continue to be
>> recognized as the correct type, this is fine. Otherwise, an unlucky
>> combination of writes to the filesystem and filesystem allocation decisions
>> could cause the filesystem to start being mounted as the wrong type, which
>> would be very bad. According to https://github.com/util-linux/util-linux/issues/1305,
>> libblkid can indeed probe for subsequent superblocks after the first one it
>> finds.
>
> I believe the situation would be the same even without the
> Discoverable Partition Specification. The kernel always divides the
> whole disk into partitions, and libblkid/mount utilizes these
> partitions. Therefore, the filesystems are automatically separated by
> the partition table.
/etc/fstab provides an explicit filesystem type. The Discoverable
Partition Specification doesn't.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: [PATCH v2] hwclock: Support GNU Hurd
From: Karel Zak @ 2024-12-09 11:31 UTC (permalink / raw)
To: Zhaoming Luo; +Cc: util-linux, bug-hurd
In-Reply-To: <20241209111611.370398-1-zhmingluo@163.com>
On Mon, Dec 09, 2024 at 07:16:11PM GMT, Zhaoming Luo wrote:
> configure.ac | 6 +++++-
> sys-utils/Makemodule.am | 5 +++++
> sys-utils/hwclock-rtc.c | 19 ++++++++++++++++++-
> sys-utils/hwclock.c | 2 +-
> sys-utils/hwclock.h | 4 +++-
> 5 files changed, 32 insertions(+), 4 deletions(-)
Great, I have created a pull request for CI tests at
https://github.com/util-linux/util-linux/pull/3319 and will merge it
later. Thank you!
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH v2] hwclock: Support GNU Hurd
From: Zhaoming Luo @ 2024-12-09 11:16 UTC (permalink / raw)
To: util-linux; +Cc: bug-hurd, kzak, Zhaoming Luo
* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd
Signed-off-by: Zhaoming Luo <zhmingluo@163.com>
---
configure.ac | 6 +++++-
sys-utils/Makemodule.am | 5 +++++
sys-utils/hwclock-rtc.c | 19 ++++++++++++++++++-
sys-utils/hwclock.c | 2 +-
sys-utils/hwclock.h | 4 +++-
5 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 698da36c6..8de6af616 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
linux_os=no
bsd_os=no
+gnu_os=no
AS_CASE([${host_os}],
[*linux*],
[linux_os=yes],
[*darwin*],
[darwin_os=yes],
[*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+ [gnu*],
+ [gnu_os=yes])
AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
AS_IF([test "x$darwin_os" = xyes], [
AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656b0..8cc69be60 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
hwclock_LDADD += $(REALTIME_LIBS)
endif
+if HURD
+hwclock_SOURCES += \
+ sys-utils/hwclock-rtc.c \
+ lib/monotonic.c
+endif
if HAVE_AUDIT
hwclock_LDADD += -laudit
endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e8a..7acf09d43 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
*
* rtc.c - Use /dev/rtc for clock access
*/
+#ifdef __GNU__
+#include <sys/ioctl.h>
+#include <hurd/rtc.h>
+#else
#include <asm/ioctl.h>
-#include <errno.h>
#include <linux/rtc.h>
#include <linux/types.h>
+#endif /* __GNU__ */
+#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
@@ -28,6 +33,7 @@
#include "hwclock.h"
+#ifndef __GNU__
#ifndef RTC_PARAM_GET
struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
{
return hwclock_params;
}
+#endif /* __GNU__ */
/*
* /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,20 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
+#ifdef __GNU__
+ rtc_dev_fd = open(rtc_dev_name, O_RDWR);
+#else
rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+#endif
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
+#ifdef __GNU__
+ rtc_dev_fd = open(fls[i], O_RDWR);
+#else
rtc_dev_fd = open(fls[i], O_RDONLY);
+#endif
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +426,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
+#ifndef __GNU__
static int resolve_rtc_param_alias(const char *alias, __u64 *value)
{
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +625,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
return 0;
}
+#endif /* __GNU__ */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfbce..2714775f9 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
#endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
#endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c7d..4cbbff957 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -36,8 +36,10 @@ struct hwclock_control {
#if defined(__linux__) && defined(__alpha__)
char *epoch_option;
#endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
char *rtc_dev_name;
+#endif
+#ifdef __linux__
uint32_t param_idx; /* --param-index <n> */
#endif
char *param_get_option;
--
2.47.1
^ permalink raw reply related
* Re: [PATCH] hwclock: Support GNU Hurd
From: Karel Zak @ 2024-12-09 10:59 UTC (permalink / raw)
To: Zhaoming Luo, util-linux, bug-hurd
In-Reply-To: <Z1bIJjzgosmfF4xL@begin>
On Mon, Dec 09, 2024 at 11:36:22AM GMT, Samuel Thibault wrote:
> Karel Zak, le lun. 09 déc. 2024 11:32:33 +0100, a ecrit:
> > On Mon, Dec 09, 2024 at 10:58:15AM GMT, Zhaoming Luo wrote:
> > > if (ctl->rtc_dev_name) {
> > > rtc_dev_name = ctl->rtc_dev_name;
> > > - rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
> > > + rtc_dev_fd = open(rtc_dev_name, O_RDWR);
> >
> > Why do you need O_RDWR on HURD?
>
> For setting the time, it makes sense to request WR?
>
> > Maybe it would be better to add an
> > #ifdef, as it is unnecessary for Linux.
>
> I have to say I'm surprised that Linux doesn't require it for setting
> the time.
It requires CAP_SYS_TIME. I assume that in this case, the RTC file
descriptor is simply a handler used to communicate with the RTC
driver. There are also more RTC_* set/get ioctls available, such as
alarm and interrupts.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [RFC PATCH] hwclock: Remove ioperm declare as it causes nested extern declare warning
From: Karel Zak @ 2024-12-09 10:43 UTC (permalink / raw)
To: Zhaoming Luo; +Cc: util-linux, samuel.thibault
In-Reply-To: <20241209021154.255340-1-zhmingluo@163.com>
On Mon, Dec 09, 2024 at 10:11:54AM GMT, Zhaoming Luo wrote:
> sys-utils/hwclock-cmos.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox