Re: [fedora-arm] Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 20:51 -0400, Jeffrey Walton wrote: > On Wed, Oct 25, 2023 at 7:33 PM Adam Williamson > wrote: > > > > On Wed, 2023-10-25 at 22:02 +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > > > all to come up with a genius fix, otherwise we'll likely have to > > > > document this > > > > > > Happy to oblige ;--] > > > > Genius located! Thanks, Zbigniew :) > > Be careful of this solution. Time functions were formerly returning an > error until the RTC was set to an accurate time. The new behavior is > to return a fake/incorrect time without an error. I don't think it's a > good idea to misreport something time system wide without error. > > You might want to consider other ways to get beyond signature checks > that are less intrusive, and not system wide. There isn't any new behaviour. We're just doing a new systemd build for F38 so the already-existing behaviour (set the clock to the time the package was built) will give a later time than previously. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 22:02 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > all to come up with a genius fix, otherwise we'll likely have to > > document this > > Happy to oblige ;--] Genius located! Thanks, Zbigniew :) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > all to come up with a genius fix, otherwise we'll likely have to > document this Happy to oblige ;--] Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023, 16:56 Adam Williamson wrote: > We're still kinda kicking around ideas for "fixing" this, but I think > if push comes to shove, we'll wind up revoting or waiving it as not > practically fixable. How about something of the form of an ExecStartPre expression (or script) that tests the date and if less than then (say) 2023-01-01 sets the date to the expected release date of F39 (via timedatectl)? Not quite right, but it would likely pass the gpg tests It can (hopefully) be replaced by something better in the future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 4:08 PM Chris Adams wrote: > Certainly - I was just looking for a more general solution to non-RTC > systems going forward. Ideally, there could be something triggered by a > lack of an RTC, but it looks like systemd path units cannot work based > on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that > would make it easy. I believe negation works (not tested) as in: ConditionPathExists=!/dev/rtc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
Once upon a time, Gary Buhrmaster said: > Personally, I have been using systemd-timesyncd for > quite some time on the vast majority of my systems > and am quite satisfied with it, but I believe that > changing from chrony to systemd-timesyncd was > considered too big of a last minute change since > we are in the final blocker stage of a release. Certainly - I was just looking for a more general solution to non-RTC systems going forward. Ideally, there could be something triggered by a lack of an RTC, but it looks like systemd path units cannot work based on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that would make it easy. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 8:12 AM Adam Williamson wrote: > > On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > > Once upon a time, Adam Williamson said: > > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > > dates gpg key > > > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > > practically fixable. > > > > > > Not adding to the ticket (because "me too" is not useful there), but... > > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > > systems with no RTC (make a systemd service depend on /dev/rtc not > > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > > a number of the small boards have no RTC. I do typically add an RTC to > > > my Pis, but not always (for various reasons). > > > > We already have systemd-timesyncd. On startup, it syncs the time to > > the mtime of: > > - /var/lib/systemd/timesync/clock file; or > > - /usr/lib/clock-epoch file; or > > - a time derived from the source tree at build time > > > > timesyncd is mentioned in the bug, but I didn't read everything. > > There are several ways we could certainly address the bug going > forward. Say, starting with a Fedora 40 Change. But it seems less clear > how we could safely fix it for upgrades from F37 or F38 to F39, without > pushing a level of change that is inappropriate for a stable release. Could we initialize the time with the timestamp of the initrd and then update the timestamp to the current time after that? That should work around this specific problem, I think? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson said: > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > dates gpg key > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > practically fixable. > > > > Not adding to the ticket (because "me too" is not useful there), but... > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > systems with no RTC (make a systemd service depend on /dev/rtc not > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > a number of the small boards have no RTC. I do typically add an RTC to > > my Pis, but not always (for various reasons). > > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 9:35 AM Tomasz Torcz wrote: > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. Personally, I have been using systemd-timesyncd for quite some time on the vast majority of my systems and am quite satisfied with it, but I believe that changing from chrony to systemd-timesyncd was considered too big of a last minute change since we are in the final blocker stage of a release. I believe that a change proposal (for F40) to change to systemd-timesyncd, or fake-hwclock (or some other agreed upon solution) by default should be created so the non-RTC systems will work properly at future upgrades (converting existing systems from chrony to systemd-timesyncd can be complicated if the systems has modified the default chrony config or is not a (pure) client, so that may only be a longer term fix). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > dates gpg key > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > if push comes to shove, we'll wind up revoting or waiving it as not > > practically fixable. > > Not adding to the ticket (because "me too" is not useful there), but... > I think Fedora should include SOME type of "fake hwclock"-type thing for > systems with no RTC (make a systemd service depend on /dev/rtc not > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > a number of the small boards have no RTC. I do typically add an RTC to > my Pis, but not always (for various reasons). We already have systemd-timesyncd. On startup, it syncs the time to the mtime of: - /var/lib/systemd/timesync/clock file; or - /usr/lib/clock-epoch file; or - a time derived from the source tree at build time timesyncd is mentioned in the bug, but I didn't read everything. -- Tomasz Torcz There exists no separation between gods and men: to...@pipebreaker.pl one blends softly casual into the other. — Frank Herbert ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
Once upon a time, Adam Williamson said: > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > dates gpg key > > We're still kinda kicking around ideas for "fixing" this, but I think > if push comes to shove, we'll wind up revoting or waiving it as not > practically fixable. Not adding to the ticket (because "me too" is not useful there), but... I think Fedora should include SOME type of "fake hwclock"-type thing for systems with no RTC (make a systemd service depend on /dev/rtc not existing?), as other RPi-targeted distros do. This isn't RPi-specific, a number of the small boards have no RTC. I do typically add an RTC to my Pis, but not always (for various reasons). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 39 Final blocker status summary #3
Hi folks! We're still trying to get F39 done, so time for another status update... Action summary == Accepted blockers - 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng to push the fix stable 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team (and adamwill) to keep trying to come up with a fix 3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will be waived 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team (pbrobinson) to fix it 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM team to evaluate and fix if possible, ARM/QA to test on more systems if possible 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at all to come up with a genius fix, otherwise we'll likely have to document this Bug-by-bug detail = Accepted blockers - 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED kdump is enabled by default on desktops This is basically fixed, just waiting to be pushed stable. 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) Well, we kinda had a fix for this, but it turns out to break something even worse (now anaconda isn't visible on the Workstation live image). So we're still stuck trying to find a perfect fix, unfortunately. Desktop team plus me to keep cranking away on it. 3. shim - https://bugzilla.redhat.com/2113005 - NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards Let's just assume this is gonna be waived. 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 Peter says "So we've basically got to the bottom of the problem and worked out the issue, I now just need to come up with a fix.", so that's what we're waiting on. 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD card slot This one's also waiting on ARM team (i.e. Peter), but seems somewhat less clear-cut of a blocker, so we're kinda waiting for his take on that, plus testing from other Raspberry Pi owners would be useful. 6. distribution - https://bugzilla.redhat.com/2242759 - NEW dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
