<@dustymabe:matrix.org>
16:31:49
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:31:51
Meeting started at 2023-12-06 16:31:49 UTC
<@meetbot:fedora.im>
16:31:51
The Meeting name is 'fedora_coreos_meeting'
<@dustymabe:matrix.org>
16:31:59
!topic roll call
<@dustymabe:matrix.org>
16:32:10
!hi dustymabe
<@zodbot:fedora.im>
16:32:12
Dusty Mabe (dustymabe) - he / him / his
<@fifofonix:matrix.org>
16:32:38
!hi fifofonix
<@zodbot:fedora.im>
16:32:40
Fifo Phonics (fifofonix)
<@marmijo:fedora.im>
16:32:55
!hi marmijo
<@zodbot:fedora.im>
16:32:57
Michael Armijo (marmijo)
<@dustymabe:matrix.org>
16:33:26
!chair fifofonix marmijo
<@dustymabe:matrix.org>
16:33:45
i guess maybe `!chair` isn't needed any longer
<@dustymabe:matrix.org>
16:33:54
this is the first time I've run a matrix meeting
<@dustymabe:matrix.org>
16:35:36
I'll give a few more minutes for people to filter in
<@jlebon:fedora.im>
16:36:31
the room id looks like it's `#meeting-1` and not `#fedora-meeting-1`
<@jlebon:fedora.im>
16:37:14
it's super confusing that typing `meeting-1` in the UI to search rooms doesn't show this channel (you have to type "Meeting 1")
<@dustymabe:matrix.org>
16:37:35
yeah, the instructions need to be updated for matrix: https://github.com/coreos/fcos-meeting-action/issues/48
<@jlebon:fedora.im>
16:38:06
i guess with matrix now, we can actually tag the meeting room itself so it's clickable
<@dustymabe:matrix.org>
16:38:10
i honestly wish matrix didn't allow spaces or capitalization in meeting room names
<@dustymabe:matrix.org>
16:39:03
ok let's get started then - attendance is light but I think we can still have conversations
<@dustymabe:matrix.org>
16:39:15
!topic Action items from last meeting
<@dustymabe:matrix.org>
16:39:30
!info there were no action items from last meeting
<@jmarrero:matrix.org>
16:39:38
!hi
<@zodbot:fedora.im>
16:39:40
No Fedora Accounts users have the @jmarrero:matrix.org Matrix Account defined
<@dustymabe:matrix.org>
16:39:50
👋
<@jlebon:fedora.im>
16:40:10
!hi jlebon
<@dustymabe:matrix.org>
16:40:11
looks like maybe you'll have to cross link your matrix account with your FAS account jmarrero
<@zodbot:fedora.im>
16:40:11
None (jlebon)
<@jmarrero:matrix.org>
16:40:39
dustymabe: yeah
<@dustymabe:matrix.org>
16:40:41
!topic fwupdmgr - UEFI ESP partition not detected or configured
<@dustymabe:matrix.org>
16:40:53
!link https://github.com/coreos/fedora-coreos-tracker/issues/1623
<@dustymabe:matrix.org>
16:41:42
This one is interesting to me. When the topic first came up I tried to manually mount the EFI partition and then run fwupd and it still complained it couldn't find an EFI partition
<@dustymabe:matrix.org>
16:42:23
as hughsie states in the issue it may not actually be a problem that the EFI partition is not mounted, but something else
<@dustymabe:matrix.org>
16:44:09
anyone with anything to add on this topic?
<@jlebon:fedora.im>
16:44:17
hmm, yeah that's odd. possibly it's using some slightly different criteria?
<@dustymabe:matrix.org>
16:44:48
`sudo /usr/bin/fwupdmgr refresh` gives me a warning:
<@jlebon:fedora.im>
16:44:54
can i reproduce this in a qemu VM? doing `get-upgrades` gives "No updatable devices" of course
<@dustymabe:matrix.org>
16:45:03
`sudo /usr/bin/fwupdmgr refresh` gives me a warning:
```
WARNING: UEFI capsule updates not available or enabled in firmware setup
```
<@dustymabe:matrix.org>
16:45:51
yeah - there were some other commands to run that I was trying last week
<@dustymabe:matrix.org>
16:46:24
like this:
<@dustymabe:matrix.org>
16:46:31
like this:
```
[core@cosa-devsh ~]$ sudo /usr/bin/fwupdtool esp-list --verbose
16:46:14.524 FuDebug verbose to info (on console 1)
16:46:14.525 FuEngine starting fwupd 1.9.9…
No ESP or BDP found
```
<@dustymabe:matrix.org>
16:46:49
That's with `/boot/efi` mounted
<@dustymabe:matrix.org>
16:47:26
That's with `/boot/efi` mounted (and of course with `--qemu-firmware=uefi`)
<@jlebon:fedora.im>
16:47:43
naively looking at the fwupd code, it seems to key off the type GUID, which is set on ours
<@jlebon:fedora.im>
16:48:39
would be good to have someone dive into this; definitely should make sure that fwupd works in FCOS
<@dustymabe:matrix.org>
16:48:48
Obviously this needs some deeper investigation. Would anyone want to investigate this further?
<@dustymabe:matrix.org>
16:48:57
Jonathan Lebon: right. and for RHCOS in the future
<@dustymabe:matrix.org>
16:50:08
!info this one needs more investigation and we're looking for a volunteer to dig in
<@dustymabe:matrix.org>
16:52:00
!topic iPXE Booting Raspberry Pi CM4s results in incorrect time and inablitiy to access ignition via HTTPS
<@dustymabe:matrix.org>
16:52:08
!link https://github.com/coreos/fedora-coreos-tracker/issues/1624
<@dustymabe:matrix.org>
16:52:54
I think the TL;DR on this one is that you can't fetch Ignition configs over HTTPS if your clock isn't accurate.
<@dustymabe:matrix.org>
16:53:26
I think that's fairly reasonable once you understand the problem
<@dustymabe:matrix.org>
16:54:41
As Jonathan Lebon pointed out there is a karg that can be used to set the time and workaround this problem
<@dustymabe:matrix.org>
16:55:20
I posted up this in the thread:
> It's not really a problem we encounter often because most systems have an RTC. I don't really think the extra time it would add to the boot OR the added complexity of trying to figure out how to allow a user to specify what ntp servers they wanted to use during the initramfs of the first boot of a system would really be worth the effort.
<@dustymabe:matrix.org>
16:55:40
Does anyone disagree with that?
<@dustymabe:matrix.org>
16:56:11
Does anyone disagree with that or have anything additional to add?
<@jlebon:fedora.im>
16:57:22
yeah, agree with that overall. i think we've hit cases like this in the past too, but in an installer workflow, so there you can fix the clock at install time
<@dustymabe:matrix.org>
16:58:13
right. one problem with using the karg workaround (that was suggested) is I guess it will set the time on every boot (i.e. if that karg were persisted)
<@dustymabe:matrix.org>
16:58:46
one idea I had while pondering this issue was that we have a mechanism for something like this inside of the Ignition configs but not for the igntiion config itself
<@dustymabe:matrix.org>
16:59:19
i.e. you can specify an `http` endpoint and then also a sha256 checksum of the file, so you don't need TLS for remote artifacts fetched from within an Ignition config
<@dustymabe:matrix.org>
16:59:56
but we don't have anything like that for the ignition config itself (i.e. we have `ignition.config.url`, but no `ignition.config.checksum` that could be used to validate it)
<@dustymabe:matrix.org>
17:00:34
so your options today are:
<@dustymabe:matrix.org>
17:00:37
1) fix the clock
<@dustymabe:matrix.org>
17:00:48
2) YOLO and just use `htttp`
<@dustymabe:matrix.org>
17:01:07
3. embed the ignition config in the initramfs/ISO
<@dustymabe:matrix.org>
17:01:47
we could improve option `2.` with something like `ignition.config.checksum`, but I don't really know if that would be important/priority
<@dustymabe:matrix.org>
17:02:19
maybe these problems will be less of an issue in the future too (I think the Pi5 has a RTC)
<@jlebon:fedora.im>
17:02:57
in the case of 1624, they were doing a pxe boot to install, so the persistent karg issue isn't an issue there
<@jlebon:fedora.im>
17:03:15
but yeah, if you're doing stateless, indeed that'd be annoying
<@jlebon:fedora.im>
17:03:40
i guess you were globbing that as part of option 1?
<@dustymabe:matrix.org>
17:03:45
I think they are doing stateless, but for stateless it doesn't matter (you run ignition on every boot and you want the karg on every boot)
<@jlebon:fedora.im>
17:04:14
right, but you need to update the karg each time
<@dustymabe:matrix.org>
17:04:23
indeed
<@dustymabe:matrix.org>
17:04:42
yeah any of these changes would probably need to be a part of a "workflow" unfortunately
<@jlebon:fedora.im>
17:04:53
(the first sentence in that issue mentions installing FCOS at least)
<@dustymabe:matrix.org>
17:05:13
with 1) you need to update the karg 2) you need to update `ignition.config.checksum` if it changed 3) you'd need to generate a new initramfs (if it changed)
<@jlebon:fedora.im>
17:05:45
indeed
<@dustymabe:matrix.org>
17:07:14
!proposed We don't this issue is a high priority because there aren't many systems without an RTC. As mentioned there are systems with an RTC that is wrong, but in that case it's easy to remedy by setting the RTC to a correct value. We could improve by giving users an `ignition.config.checksum` option to go along with `ignition.config.url`, but it's still a workaround and probably not worth the effort.
<@dustymabe:matrix.org>
17:07:28
!proposed We don't think this issue is a high priority because there aren't many systems without an RTC. As mentioned there are systems with an RTC that is wrong, but in that case it's easy to remedy by setting the RTC to a correct value. We could improve by giving users an `ignition.config.checksum` option to go along with `ignition.config.url`, but it's still a workaround and probably not worth the effort.
<@jlebon:fedora.im>
17:08:31
ack
<@fifofonix:matrix.org>
17:08:33
+1
<@marmijo:fedora.im>
17:08:45
+1
<@dustymabe:matrix.org>
17:09:24
maybe I should clarify and say `"aren't many systems that we target that don't have an RTC"`
<@dustymabe:matrix.org>
17:09:40
because I'm sure someone could point at a bunch of toy systems that don't have an RTC
<@dustymabe:matrix.org>
17:09:56
I'll make that edit and mark it as agreed
<@dustymabe:matrix.org>
17:10:26
!agreed We don't think this issue is a high priority because there aren't many systems that we target that don't have an RTC. As mentioned there are systems with an RTC that is wrong, but in that case it's easy to remedy by setting the RTC to a correct value. We could improve by giving users an `ignition.config.checksum` option to go along with `ignition.config.url`, but it's still a workaround and probably not worth the effort.
<@dustymabe:matrix.org>
17:10:52
#topic FOSDEM 2024 (Brussels / 3 & 4 February 2024)
<@dustymabe:matrix.org>
17:10:58
!topic FOSDEM 2024 (Brussels / 3 & 4 February 2024)
<@dustymabe:matrix.org>
17:11:11
!topic FOSDEM 2024 (Brussels / 3 & 4 February 2024)
<@dustymabe:matrix.org>
17:11:27
!link https://github.com/coreos/fedora-coreos-tracker/issues/1621
<@dustymabe:matrix.org>
17:11:49
anybody going to brussels next february ?
<@dustymabe:matrix.org>
17:12:40
I think the move of devconf.cz to the summer has severly limited people from the US being able to make the trip to FOSDEM, but maybe people from europe can make it
<@dustymabe:matrix.org>
17:13:36
!topic Open Floor
<@dustymabe:matrix.org>
17:13:51
anyone with anything for Open Floor?
<@dustymabe:matrix.org>
17:14:14
!info Fedora 40 changes are starting to flow in - we'll start reviewing them soon! https://github.com/coreos/fedora-coreos-tracker/issues/1626
<@jlebon:fedora.im>
17:15:36
nothing here for me
<@dustymabe:matrix.org>
17:16:05
I wonder what our numbers are up to these days (/me should go run a script and check the output)
<@dustymabe:matrix.org>
17:16:52
I don't have anything else either for today. Next week we should discuss our meeting schedule for the rest of the year (holiday impact) and also make sure we have coverage for our last set of scheduled releases for the year
<@dustymabe:matrix.org>
17:17:02
I'll close out the meeting here soon
<@fifofonix:matrix.org>
17:17:24
Thanks Dusty
<@dustymabe:matrix.org>
17:17:45
!endmeeting