15:00:38 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:38 <zodbot> Meeting started Tue Dec  4 15:00:38 2018 UTC.
15:00:38 <zodbot> This meeting is logged and archived in a public location.
15:00:38 <zodbot> The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:38 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:39 <pwhalen> #chair pwhalen pbrobinson
15:00:39 <pwhalen> #topic roll call
15:00:39 <zodbot> Current chairs: pbrobinson pwhalen
15:00:46 <pwhalen> good morning folks, who's here today?
15:01:11 * pbrobinson o/
15:05:33 <pwhalen> looks like the holiday vacation has started. Shall we give it a couple more minutes?
15:06:12 <stellirin> is the ARM meeting still on?
15:06:29 <pwhalen> stellirin, it is
15:07:09 <pbrobinson> yes, we were just waiting for a quorum
15:07:17 <pbrobinson> which is doesn't look like we have
15:07:17 <pwhalen> stellirin, just waiting to see if we have a quorum before we begin. Did you have something you wanted to discuss?
15:07:53 <stellirin> I do have a topic I'd lice to raise
15:07:57 <stellirin> like
15:08:59 <pwhalen> stellirin, the floor is yours :)
15:10:19 <stellirin> Is PXE boot something that should be supported on armhfp, i raised a bug recently that it's painfully slow due to waiting on random entropy
15:10:27 <stellirin> https://bugzilla.redhat.com/show_bug.cgi?id=1645853
15:10:47 <stellirin> i guess my use case is pretty niche, but i'd like to make it work
15:11:26 <stellirin> i have a cluster of 15 orange pi boards that I want to boot without SD Cards
15:11:49 <pwhalen> I saw the bz, I use pxe quite regularly for installations
15:12:12 <pwhalen> so booting the installer isnt an issue
15:12:12 <pbrobinson> stellirin: there's some issues around entropy and there's not much we can currently do about it without reducing security elsewhere
15:12:53 <pbrobinson> overall it's supported, but the HW that the orangepi are based on doesn't have the drivers upstream for the HW RNG stuff as yet
15:13:27 <pbrobinson> the kernel devs are working in general to improve the situation there, but it's not something completely straight forward
15:13:46 <stellirin> I was able to 'fix' it using the haveged daemon, is that something that could be included for all?
15:14:19 <stellirin> but I also don't understand why it would work on a normal bood with SD CArd but not over PXE
15:14:24 <stellirin> boot
15:15:24 <stellirin> pwhalen do you use it to boot rpi3? I see the same issue there too
15:16:31 <pwhalen> stellirin, yes, rpi2/3, bananapi, trimslice, jetson tk1, wandboard. I do pxe installs to all of them
15:17:45 <stellirin> hmm, do you see how booting to install be different to booting over NFS? I guess install means you have a SD card inserted for the install
15:18:22 <pwhalen> stellirin, right. the sd has uboot/firmware for the rpi2/3
15:18:22 <pbrobinson> stellirin: I don't know what gets initiated differently on a PXE/NFS boot that needs entropy than a standard boot
15:19:48 <stellirin> for the rpi3 I have nothing at all connected to it except a network cable, and as I described in the bug it takes forever, 30mins+
15:19:56 <stellirin> and the same for the opi cluster
15:20:36 <pwhalen> stellirin, due to memory constraints I nfs mount the squashfs for pxe to work
15:21:54 <pwhalen> stellirin, no sd, no usb?
15:22:09 <stellirin> OK, well I need to test the latest kernel as suggested in the recent comment on the bug, but I haven't noticed any changes in that area
15:22:26 <stellirin> pwhalen correct, no sd, no usb, sometimes a HDML to monitor progress for debug
15:23:13 <pwhalen> didnt know that was possible :)
15:23:36 <pwhalen> stellirin, do you happen to have a link? that could be useful
15:24:55 <stellirin> sure, 1 sec
15:25:52 <pwhalen> found some info too, cool- didnt know that was added
15:25:52 <pbrobinson> howdy jlanda
15:26:03 <pbrobinson> sorry, jlinton even
15:26:46 <jlinton> Hi, (I keep getting disconnected)
15:26:54 <stellirin> pwhalen https://stellirin.com/cluster
15:27:23 <pwhalen> stellirin, cool thanks, will play around with it as well
15:27:33 <pwhalen> thanks for the link , awesome little cluster
15:31:12 <pwhalen> ok, well lets get started
15:31:19 <pwhalen> #topic 1) ==== Userspace Status  ====
15:31:39 <pwhalen> #info DNF error: Error in POSTTRANS scriptlet in rpm package kernel-core
15:31:39 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1650707
15:31:52 <pwhalen> this should be fixed now
15:32:08 <pwhalen> #info Should be fixed in rawhide.
15:32:47 <pwhalen> #info Armv7 guest fails on AArch64 - "cpu.c:906: arm_cpu_realizefn: Assertion no_aa32"
15:32:47 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1651348
15:33:04 <pwhalen> dont think this has changed, no update on the bz
15:33:58 <pwhalen> and related to the first grubby bug
15:34:03 <pwhalen> #info 32-bit ARM systems upgraded from <F30 to >=F30 will have non-BLS bootloader, but grubby-deprecated will not be installed
15:34:03 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1654841
15:34:21 <pwhalen> #info This should be fixed in extlinux-bootloader-1.2-7.fc30
15:34:51 <pwhalen> I think thats in todays compose, but will test when its available
15:35:09 <pwhalen> any other issues?
15:35:48 * pwhalen sees an issue with jlinton's connectivity :)
15:36:45 <pwhalen> #topic 2) ==== Kernel Status ====
15:36:54 <pbrobinson> I think there was an other issue
15:36:59 <pbrobinson> I'm just trying to remember it
15:37:00 <pwhalen> #undo
15:37:00 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe4fd176810>
15:38:44 <pbrobinson> so I can't remember it, I did a min a got but it went puff
15:38:50 <pbrobinson> lets move on
15:38:59 <pwhalen> #topic 2) ==== Kernel Status ====
15:39:05 * jlinton will look at the aarch64/kvm/v7 problem
15:39:15 <pbrobinson> jlinton++ thanks
15:39:15 <zodbot> pbrobinson: Karma for jlinton changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:39:15 <pwhalen> thanks jlinton
15:39:22 <pwhalen> jlinton++
15:39:22 <zodbot> pwhalen: Karma for jlinton changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:40:06 <pwhalen> #info F29: kernel-4.19.6-300.fc29
15:40:06 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1168375
15:41:02 <pwhalen> #info Some reports of ext4 file system corruption on 4.19
15:41:08 <pwhalen> #link https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/JQYO43XQQEFBMLSQBSS46V3J3LVJ66FM/
15:41:52 <pwhalen> anyone seeing the reported ext4 corruption?
15:43:16 <pbrobinson> I've not seen issues of ext4 corruption I'm aware
15:43:17 <pbrobinson> of
15:43:29 <jlinton> No, I've not been running 4.19, only 4.18 and 4.20rc
15:43:35 <pwhalen> I've not either
15:43:43 <pbrobinson> also I suspect it's some what device specific
15:43:45 <pwhalen> #info F30: kernel-4.20.0-0.rc5.git0.1.fc30
15:43:45 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1168560
15:43:55 <pwhalen> any issues with 4.20?
15:44:02 <pbrobinson> but I will take a reason when I get a moment
15:44:33 <jlinton> there were some memblock issues, but they appear to be cleared up
15:45:49 <pwhalen> ok
15:45:56 <pwhalen> #info Please test and report any issues to the list or #fedora-arm.
15:46:11 <pwhalen> any other kernel news?
15:46:12 <pbrobinson> so other than that there's a very weird and random RPi wifi issue
15:46:52 <pbrobinson> I think it's a race between mmc/pwrseq/gpio to ensure the power is up before the sdio slot is probed for HW, but I'm not 100% sure and it's quite random
15:49:09 <pwhalen> and this happened around 4.18.17 iirc? for the most part
15:50:56 <pbrobinson> well there was two bugs, one aarch64 specific, that regressed in 4.18.4 and was fixed in around 4.19.3
15:51:00 <pbrobinson> that was the easy one
15:51:34 <pbrobinson> the other one seemed to happen more frequently sin 4.18.17 but I've recreated it as early as 4.18.13
15:52:14 <pbrobinson> so I suspect it happened in the 4.18 merge window but it wasn't as common until later for some reason, all of which currently alludes me
15:52:39 <pwhalen> #info Very weird and random RPi wifi issue that began around 4.18.17. Wifi shows up on some boots, or not. Some hardware seems unaffected.
15:53:22 <pbrobinson> I've got one device where it never works, one where it almost always but not quite works and another where from boot to boot it seems to differ
15:53:38 <pwhalen> oh thats just tons of fun
15:53:46 <pwhalen> :/
15:54:14 <jlinton> My Hikey is a bit behind, let me see if its having the problem too
15:54:31 <jlinton> (although, the wifi on that machine isn't what I would call 100% stable anyway)
15:55:12 <pwhalen> #topic 3) ==== Bootloader Status ====
15:55:22 <pbrobinson> jlinton: I think the hikey is TI wifi? This seems to be broadcom, and I'm fairly certain it's rpi specific
15:55:37 <pwhalen> #info uboot-tools-2018.11-1.fc30 available now for testing!
15:55:43 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1168781
15:56:09 <pbrobinson> this u-boot was built with arm-trusted-firmware 2.0 so would be useful to get some testing
15:56:36 <pwhalen> #info Built with arm-trusted-firmware 2.0.
15:56:44 <pbrobinson> post that build I pushed a ATF 2.x snapshot from today, which U-Boot 2019.0-rc1 is currently building against
15:57:05 <pbrobinson> that will add support for things like the pinebook and lighting up it's display
15:57:23 <pbrobinson> and also the Raspberry Pi A+
15:57:24 <pwhalen> #info uboot-tools-2019.01-0.1.rc1.fc30 building now
15:57:29 <pbrobinson> 3A+ even
15:57:38 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1168822
15:58:31 <pwhalen> #info Adds support for Pinebook and Raspberry Pi A+.
15:58:41 <pwhalen> #topic 4) == F30 ==
15:58:41 <pwhalen> #info Latest nominated nightly - https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
15:58:48 <pwhalen> zipping through the rest
15:59:20 <pwhalen> no new issues testing, might be something with vnc but not reproduced
15:59:31 <pwhalen> #topic 5)  == Open Floor ==
15:59:38 <pwhalen> one minute for open floor..
15:59:43 <pwhalen> or 20 seconds
15:59:54 <pwhalen> anything else?
16:00:06 <pwhalen> #endmeeting