Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Hello, Thorsten Glaser, le mer. 06 déc. 2023 12:16:27 +0100, a ecrit: > On Wed, 6 Dec 2023, Chris Hofstaedtler wrote: > >I have zero knowledge about hurd, but it looks like[1] hwclock is built > >with CMOS support on hurd. So maybe it could work? > > Maybe it just needs a different config? > > >Given this I'd imagine nobody has ever used the hwclock initscripts > >on hurd before, and maybe they shouldn't exist there? I'd hope hurd > >wouldn't rely on userspace to do direct hardware access to set the > >time. > > AIUI Hurd is a microkernel so everything is done in userspace? Yes, we'd rather set a translator on /dev/rtc, that does the ISA access for everybody, instead of hwclock doing it (and possibly stepping on top of another hwclock call). Contribution welcome ;) Samuel
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
And on a Devuan/Ceres box: dpkg -S /usr/lib/udev/rules.d/hwclock.rules initscripts: /usr/lib/udev/rules.d/hwclock.rules dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules dpkg-query: no path found matching pattern /usr/lib/udev/rules.d/85- hwclock.rules On Wed, 2023-12-06 at 18:08 +0100, Svante Signell wrote: > On Wed, 2023-12-06 at 16:52 +, Mark Hindley wrote: > > Martin, > > > > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > > > Please note that the start target refers to a non-existing > > > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > > > reference to rtc0 that probably needs fixing for Hurd as well. > > > > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. > > On a Hurd box: > ls /usr/lib/udev/rules.d/85-hwclock.rules > ls: cannot access '/usr/lib/udev/rules.d/85-hwclock.rules': No such file or > directory > ls /usr/lib/udev/rules.d/hwclock.rules > /usr/lib/udev/rules.d/hwclock.rules > > dpkg -S /usr/lib/udev/rules.d/hwclock.rules > initscripts: /usr/lib/udev/rules.d/hwclock.rules > > On a Devuan/Daedalus box: > ls /usr/lib/udev/rules.d/85-hwclock.rules > /usr/lib/udev/rules.d/85-hwclock.rules > ls /usr/lib/udev/rules.d/hwclock.rules > ls: cannot access '/usr/lib/udev/rules.d/hwclock.rules': No such file or > directory > > dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules > util-linux-extra: /usr/lib/udev/rules.d/85-hwclock.rules >
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Chris, Thanks On Wed, Dec 06, 2023 at 05:57:55PM +0100, Chris Hofstaedtler wrote: > * Mark Hindley : > > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > > > Please note that the start target refers to a non-existing > > > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > > > reference to rtc0 that probably needs fixing for Hurd as well. > > > > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. > > That would be my understanding as well. > > However on linux, the file should be named 85-hwclock.rules again. > Maybe this could be fixed too? Of course, queued and pending. > For hurd (and maybe linux), the big question remains, _if_ updating > the hwclock should be done by hwclock.sh by default. > I don't know the answer to this design question for hurd, or for > linux-with-sysvinit systems. I don't have a definitive answer either, but either way the script should not fail on Hurd and by downgrading the Depends to Recommends it is easy to change the behaviour if it is not to your liking. Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, 2023-12-06 at 16:52 +, Mark Hindley wrote: > Martin, > > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > > Please note that the start target refers to a non-existing > > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > > reference to rtc0 that probably needs fixing for Hurd as well. > > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. On a Hurd box: ls /usr/lib/udev/rules.d/85-hwclock.rules ls: cannot access '/usr/lib/udev/rules.d/85-hwclock.rules': No such file or directory ls /usr/lib/udev/rules.d/hwclock.rules /usr/lib/udev/rules.d/hwclock.rules dpkg -S /usr/lib/udev/rules.d/hwclock.rules initscripts: /usr/lib/udev/rules.d/hwclock.rules On a Devuan/Daedalus box: ls /usr/lib/udev/rules.d/85-hwclock.rules /usr/lib/udev/rules.d/85-hwclock.rules ls /usr/lib/udev/rules.d/hwclock.rules ls: cannot access '/usr/lib/udev/rules.d/hwclock.rules': No such file or directory dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules util-linux-extra: /usr/lib/udev/rules.d/85-hwclock.rules
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
* Mark Hindley : > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > > Please note that the start target refers to a non-existing > > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > > reference to rtc0 that probably needs fixing for Hurd as well. > > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. That would be my understanding as well. However on linux, the file should be named 85-hwclock.rules again. Maybe this could be fixed too? For hurd (and maybe linux), the big question remains, _if_ updating the hwclock should be done by hwclock.sh by default. I don't know the answer to this design question for hurd, or for linux-with-sysvinit systems. Chris
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Martin, On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > Please note that the start target refers to a non-existing > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > reference to rtc0 that probably needs fixing for Hurd as well. Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. > Anyhow, what I get with the patched init script: > > [2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh start > [2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh restart > Saving the system clock to CMOS. > Hardware Clock updated to Wed Dec 6 18:05:05 EET 2023. > [2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh stop > Saving the system clock to CMOS. > Hardware Clock updated to Wed Dec 6 18:05:12 EET 2023. > [2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh show > 2023-12-06 18:05:18.129566+02:00 Thanks. Looks OK to me. Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, Dec 6, 2023 at 4:57 PM Mark Hindley wrote: > I also propose downgrading the initscripts Depends: util-linux-extra to > Recommends. Even on non-systemd systems, hwclock.sh is far from essential as > many now use NTP and hwclock.sh already handles a missing /sbin/hwclock > gracefully. The dependency currently is a mere Suggests. What causes extra to get installed is that it currently has priority Standard. That makes debian-installer pull it on default installs, since it pulls everything Standard or higher, unless explicitly told not to do so. Martin-Éric
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, Dec 6, 2023 at 4:57 PM Mark Hindley wrote:
>
> Control: tags -1 = patch
>
> Svante,
>
> On Wed, Dec 06, 2023 at 02:20:09PM +0100, Svante Signell wrote:
> > On a qemu Hurd image:
> >
> > /sbin/hwclock --help | grep rtc
> > --directisa use the ISA bus instead of /dev/rtc0 access
> >
> > /sbin/hwclock --directisa --show
> > 2023-12-06 14:17:54.949951+01:00
>
> Many thanks, that is a great help.
>
> Could you and Martin test this patch, please?
>
> I also propose downgrading the initscripts Depends: util-linux-extra to
> Recommends. Even on non-systemd systems, hwclock.sh is far from essential as
> many now use NTP and hwclock.sh already handles a missing /sbin/hwclock
> gracefully.
>
> Mark
>
> commit acdbb98f05db8f24ddc9e72adb2b6a0982e69748
> Author: Mark Hindley
> Date: Wed Dec 6 10:20:41 2023 +
>
> hwclock.sh: support HURD direct ISA I/O.
>
> Closes: #1057634
>
> diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh
> b/debian/src/initscripts/etc/init.d/hwclock.sh
> index a9872b64..055508e7 100644
> --- a/debian/src/initscripts/etc/init.d/hwclock.sh
> +++ b/debian/src/initscripts/etc/init.d/hwclock.sh
> @@ -38,13 +38,24 @@ hwclocksh()
> # Updates the Hardware Clock with the System Clock time.
> # This will *override* any changes made to the Hardware Clock,
> # for example by the Linux kernel when NTP is in use.
> -log_action_msg "Saving the system clock to /dev/$HCTOSYS_DEVICE"
> -if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc; then
> -verbose_log_action_msg "Hardware Clock updated to `date`"
> -fi
> + if [ "$(uname -s)" = GNU ]; then
> + log_action_msg "Saving the system clock to CMOS"
> + /sbin/hwclock --directisa --systohc
> + else
> + log_action_msg "Saving the system clock to
> /dev/$HCTOSYS_DEVICE"
> + /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc
> + fi
> +if [ $? -eq 0 ]; then
> + verbose_log_action_msg "Hardware Clock updated to `date`"
> + fi
> +
> ;;
> show)
> -/sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show
> + if [ "$(uname -s)" = GNU ]; then
> + /sbin/hwclock --directisa --show
> + else
> + /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show
> + fi
> ;;
> *)
> log_success_msg "Usage: hwclock.sh
> {stop|reload|force-reload|show}"
Please note that the start target refers to a non-existing
/usr/lib/udev/rules.d/85-hwclock.rules. The correct file is
/usr/lib/udev/rules.d/hwclock.rules instead. That file contains a
reference to rtc0 that probably needs fixing for Hurd as well.
Anyhow, what I get with the patched init script:
[2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo
/etc/init.d/hwclock.sh start
[2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo
/etc/init.d/hwclock.sh restart
Saving the system clock to CMOS.
Hardware Clock updated to Wed Dec 6 18:05:05 EET 2023.
[2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo
/etc/init.d/hwclock.sh stop
Saving the system clock to CMOS.
Hardware Clock updated to Wed Dec 6 18:05:12 EET 2023.
[2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo
/etc/init.d/hwclock.sh show
2023-12-06 18:05:18.129566+02:00
Martin-Éric
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Control: tags -1 = patch
Svante,
On Wed, Dec 06, 2023 at 02:20:09PM +0100, Svante Signell wrote:
> On a qemu Hurd image:
>
> /sbin/hwclock --help | grep rtc
> --directisa use the ISA bus instead of /dev/rtc0 access
>
> /sbin/hwclock --directisa --show
> 2023-12-06 14:17:54.949951+01:00
Many thanks, that is a great help.
Could you and Martin test this patch, please?
I also propose downgrading the initscripts Depends: util-linux-extra to
Recommends. Even on non-systemd systems, hwclock.sh is far from essential as
many now use NTP and hwclock.sh already handles a missing /sbin/hwclock
gracefully.
Mark
commit acdbb98f05db8f24ddc9e72adb2b6a0982e69748
Author: Mark Hindley
Date: Wed Dec 6 10:20:41 2023 +
hwclock.sh: support HURD direct ISA I/O.
Closes: #1057634
diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh
b/debian/src/initscripts/etc/init.d/hwclock.sh
index a9872b64..055508e7 100644
--- a/debian/src/initscripts/etc/init.d/hwclock.sh
+++ b/debian/src/initscripts/etc/init.d/hwclock.sh
@@ -38,13 +38,24 @@ hwclocksh()
# Updates the Hardware Clock with the System Clock time.
# This will *override* any changes made to the Hardware Clock,
# for example by the Linux kernel when NTP is in use.
-log_action_msg "Saving the system clock to /dev/$HCTOSYS_DEVICE"
-if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc; then
-verbose_log_action_msg "Hardware Clock updated to `date`"
-fi
+ if [ "$(uname -s)" = GNU ]; then
+ log_action_msg "Saving the system clock to CMOS"
+ /sbin/hwclock --directisa --systohc
+ else
+ log_action_msg "Saving the system clock to /dev/$HCTOSYS_DEVICE"
+ /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc
+ fi
+if [ $? -eq 0 ]; then
+ verbose_log_action_msg "Hardware Clock updated to `date`"
+ fi
+
;;
show)
-/sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show
+ if [ "$(uname -s)" = GNU ]; then
+ /sbin/hwclock --directisa --show
+ else
+ /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show
+ fi
;;
*)
log_success_msg "Usage: hwclock.sh {stop|reload|force-reload|show}"
Bug#1057634: Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, Dec 6, 2023 at 3:46 PM Svante Signell wrote: > -- Forwarded message -- > From: Svante Signell > To: debian-init-divers...@chiark.greenend.org.uk > Cc: > Bcc: > Date: Wed, 06 Dec 2023 14:20:09 +0100 > Subject: Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0' > On Wed, 2023-12-06 at 12:07 +, Mark Hindley wrote: > > Chris, > > > > Thanks for your input. > > > > On Wed, Dec 06, 2023 at 11:56:56AM +0100, Chris Hofstaedtler wrote: > > > * Mark Hindley [231206 11:42]: > > > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > > > > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE > > > > used > > > > in the > > > > initscripts just wrong on Hurd? > > > > > > I have zero knowledge about hurd, but it looks like[1] hwclock is built > > > with CMOS support on hurd. So maybe it could work? > > > > > > It certainly is built without the RTC support, so --rtc=... doesn't > > > work. > > > > A superficial attempt on exodar.debian.net isn't particularly encouraging: > > > > leepen@exodar:~$ /sbin/hwclock --test > > hwclock from util-linux 2.39.2 > > System Time: 1701863851.810595 > > No usable clock interface found. > > hwclock: Cannot access the Hardware Clock via any known method. > > > > I suggest we wait for a response from the Hurd experts. But maybe > > util-linux-extra should be arch:linux-any? > > > > On a qemu Hurd image: > > /sbin/hwclock --help | grep rtc > --directisa use the ISA bus instead of /dev/rtc0 access > > /sbin/hwclock --directisa --show > 2023-12-06 14:17:54.949951+01:00 That works on my Hurd-i386 host, and it shows the correct time. Init scripts therefore need to use "--rtc=/dev/rtc0" on Linux hosts and "--directisa" on Hurd hosts. Martin-Éric
Bug#1057634: Fwd: Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
--- Begin Message --- On Wed, 2023-12-06 at 12:07 +, Mark Hindley wrote: > Chris, > > Thanks for your input. > > On Wed, Dec 06, 2023 at 11:56:56AM +0100, Chris Hofstaedtler wrote: > > * Mark Hindley [231206 11:42]: > > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > > > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used > > > in the > > > initscripts just wrong on Hurd? > > > > I have zero knowledge about hurd, but it looks like[1] hwclock is built > > with CMOS support on hurd. So maybe it could work? > > > > It certainly is built without the RTC support, so --rtc=... doesn't > > work. > > A superficial attempt on exodar.debian.net isn't particularly encouraging: > > leepen@exodar:~$ /sbin/hwclock --test > hwclock from util-linux 2.39.2 > System Time: 1701863851.810595 > No usable clock interface found. > hwclock: Cannot access the Hardware Clock via any known method. > > I suggest we wait for a response from the Hurd experts. But maybe > util-linux-extra should be arch:linux-any? > On a qemu Hurd image: /sbin/hwclock --help | grep rtc --directisa use the ISA bus instead of /dev/rtc0 access /sbin/hwclock --directisa --show 2023-12-06 14:17:54.949951+01:00 --- End Message ---
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Chris, Thanks for your input. On Wed, Dec 06, 2023 at 11:56:56AM +0100, Chris Hofstaedtler wrote: > * Mark Hindley [231206 11:42]: > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used > > in the > > initscripts just wrong on Hurd? > > I have zero knowledge about hurd, but it looks like[1] hwclock is built > with CMOS support on hurd. So maybe it could work? > > It certainly is built without the RTC support, so --rtc=... doesn't > work. A superficial attempt on exodar.debian.net isn't particularly encouraging: leepen@exodar:~$ /sbin/hwclock --test hwclock from util-linux 2.39.2 System Time: 1701863851.810595 No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method. I suggest we wait for a response from the Hurd experts. But maybe util-linux-extra should be arch:linux-any? Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, 6 Dec 2023, Chris Hofstaedtler wrote: >I have zero knowledge about hurd, but it looks like[1] hwclock is built >with CMOS support on hurd. So maybe it could work? Maybe it just needs a different config? >Given this I'd imagine nobody has ever used the hwclock initscripts >on hurd before, and maybe they shouldn't exist there? I'd hope hurd >wouldn't rely on userspace to do direct hardware access to set the >time. AIUI Hurd is a microkernel so everything is done in userspace? bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
On Wed, Dec 6, 2023 at 12:42 PM Mark Hindley wrote: > On Wed, Dec 06, 2023 at 11:16:57AM +0200, Martin-Éric Racine wrote: > > Package: initscripts > > Version: 3.08-3 > > Severity: important > > > > $ LC_ALL=C sudo invoke-rc.d hwclock.sh restart > > Saving the system clock to /dev/rtc0. > > /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0' > > > > APT prefers unreleased > > APT policy: (500, 'unreleased'), (500, 'unstable') > > Architecture: hurd-i386 (i686-AT386) > > > > Kernel: GNU-Mach 1.8+git20230830-486/Hurd-0.9 > > So you are running Hurd. I have very little experience of that arch, so would > appreciate some more information from you. I just barely got around installing Hurd on a spare host, but I'll try answering them anyway. > > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), > > LANGUAGE=fi:en > > Shell: /bin/sh linked to /usr/bin/dash > > Init: sysvinit (via /sbin/init) > > > > Versions of packages initscripts depends on: > > ii sysv-rc 3.08-3 > > ii sysvinit-utils3.08-3 > > ii util-linux-extra 2.39.3-2 > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used in > the > initscripts just wrong on Hurd? Hurd mailing list in CC might be able to answer that one. > Does your Hurd system usually have util-linux-extra installed or was it only > pulled in by the initscript dependency? $ dpkg -l | grep linux ii util-linux 2.39.3-2 hurd-i386miscellaneous system utilities ii util-linux-extra2.39.3-2 hurd-i386interactive login tools It was probably pulled-in due to having priority Standard. Martin-Éric
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
* Mark Hindley [231206 11:42]: > > Kernel: GNU-Mach 1.8+git20230830-486/Hurd-0.9 [..] > So you are running Hurd. I have very little experience of that arch, so would > appreciate some more information from you. [..] > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used in > the > initscripts just wrong on Hurd? I have zero knowledge about hurd, but it looks like[1] hwclock is built with CMOS support on hurd. So maybe it could work? It certainly is built without the RTC support, so --rtc=... doesn't work. Given this I'd imagine nobody has ever used the hwclock initscripts on hurd before, and maybe they shouldn't exist there? I'd hope hurd wouldn't rely on userspace to do direct hardware access to set the time. Chris [1] https://buildd.debian.org/status/fetch.php?pkg=util-linux=hurd-i386=2.39.3-2=1701803506=0
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Control: tags -1 moreinfo Martin, Thanks for this On Wed, Dec 06, 2023 at 11:16:57AM +0200, Martin-Éric Racine wrote: > Package: initscripts > Version: 3.08-3 > Severity: important > > $ LC_ALL=C sudo invoke-rc.d hwclock.sh restart > Saving the system clock to /dev/rtc0. > /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0' > > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: hurd-i386 (i686-AT386) > > Kernel: GNU-Mach 1.8+git20230830-486/Hurd-0.9 So you are running Hurd. I have very little experience of that arch, so would appreciate some more information from you. > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages initscripts depends on: > ii sysv-rc 3.08-3 > ii sysvinit-utils3.08-3 > ii util-linux-extra 2.39.3-2 Is hwclock actually useful on Hurd? I (naively) expected it to be linux only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used in the initscripts just wrong on Hurd? Does your Hurd system usually have util-linux-extra installed or was it only pulled in by the initscript dependency? Mark [1] https://salsa.debian.org/debian/util-linux/-/blob/master/debian/util-linux-extra.install
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Package: initscripts Version: 3.08-3 Severity: important $ LC_ALL=C sudo invoke-rc.d hwclock.sh restart Saving the system clock to /dev/rtc0. /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0' APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.8+git20230830-486/Hurd-0.9 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages initscripts depends on: ii sysv-rc 3.08-3 ii sysvinit-utils3.08-3 ii util-linux-extra 2.39.3-2 Versions of packages initscripts recommends: ii e2fsprogs 1.46.6-1 ii psmisc 23.5-1 initscripts suggests no packages. -- no debconf information
