So I think we're almost there. I believe all the no device specific issues are now fixed, or at least worked around in a statifactory and sustainable means:
1) initial-setup hangs during boot after IoT installation https://bugzilla.redhat.com/show_bug.cgi?id=1646568
2) ttyAMA ttyAMA0: tty_open: tty->count(2) != (#fd's(1) + #kopen's(0)) https://bugzilla.redhat.com/show_bug.cgi?id=1644884
3) The 35network-legacy is still used even if network-scripts isn't installed in Fedora 29 https://github.com/dracutdevs/dracut/issues/488
These two only appear on the RPi and not in a manner than I've been able to consistently reproduce. The issue with not being able to consistently reproduce is that it's almost impossible to currently fix them. They appear to be at least partially affected by environment, types of storage and pwoer supply could play a factor here, and the way ostree applies updates also appears to interact with the HW differnently to a standard Fedora ARM install. We could literally block the release on them for the rest of time, given the plan is to do a release every 4-6 weeks I don't believe we should, or even can, block on these:
4) rpm-ostree will not reliably install packages in fedora-iot https://bugzilla.redhat.com/show_bug.cgi?id=1648112
5) WARNING at drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! https://bugzilla.redhat.com/show_bug.cgi?id=1644873
The other thing to note is I've adjusted the references, they are now stable instead of 29. If you're using rpm-ostree to upgrade you'll need to rebase to get onto the new branch:
First update the key to RPM-GPG-KEY-fedora-iot-2019 in /etc/ostree/remotes.d/fedora-iot.conf
Then run "rpm-ostree rebase -b fedora/stable/ARCH/iot"
New installs use the right one by default.
The RC is at: https://dl.fedoraproject.org/pub/alt/iot/29/IoT/
There's been a few other fixes incorporated too, please review and provide feedback.
Peter
Found a few issues during testing:
1) tpm2-tools and clevis no longer in the initramfs. This seems to be an unintended result of fixing one of our blockers[1]
2) Installations from iso still use the old GPG key in /etc/ostree/remotes.d/fedora-iot.conf fixed by: sed -i 's|RPM-GPG-KEY-fedora-29-primary|RPM-GPG-KEY-fedora-iot-2019|g' /etc/ostree/remotes.d/fedora-iot.conf
3) console=tty0 included on the kargs on aarch64 disk images. This causes serial console issues on Rpi3 and needs to be removed. We do not specify the console in the kickstart and it seems to be added during image creation.
Anyone seeing anything else not mentioned?
Paul
[1] - https://github.com/dracutdevs/dracut/issues/488
----- Original Message -----
So I think we're almost there. I believe all the no device specific issues are now fixed, or at least worked around in a statifactory and sustainable means:
initial-setup hangs during boot after IoT installation https://bugzilla.redhat.com/show_bug.cgi?id=1646568
ttyAMA ttyAMA0: tty_open: tty->count(2) != (#fd's(1) + #kopen's(0)) https://bugzilla.redhat.com/show_bug.cgi?id=1644884
The 35network-legacy is still used even if network-scripts isn't
installed in Fedora 29 https://github.com/dracutdevs/dracut/issues/488
These two only appear on the RPi and not in a manner than I've been able to consistently reproduce. The issue with not being able to consistently reproduce is that it's almost impossible to currently fix them. They appear to be at least partially affected by environment, types of storage and pwoer supply could play a factor here, and the way ostree applies updates also appears to interact with the HW differnently to a standard Fedora ARM install. We could literally block the release on them for the rest of time, given the plan is to do a release every 4-6 weeks I don't believe we should, or even can, block on these:
- rpm-ostree will not reliably install packages in fedora-iot
https://bugzilla.redhat.com/show_bug.cgi?id=1648112
- WARNING at drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! https://bugzilla.redhat.com/show_bug.cgi?id=1644873
The other thing to note is I've adjusted the references, they are now stable instead of 29. If you're using rpm-ostree to upgrade you'll need to rebase to get onto the new branch:
First update the key to RPM-GPG-KEY-fedora-iot-2019 in /etc/ostree/remotes.d/fedora-iot.conf
Then run "rpm-ostree rebase -b fedora/stable/ARCH/iot"
New installs use the right one by default.
The RC is at: https://dl.fedoraproject.org/pub/alt/iot/29/IoT/
There's been a few other fixes incorporated too, please review and provide feedback.
Peter _______________________________________________ IoT mailing list -- iot@lists.fedoraproject.org To unsubscribe send an email to iot-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/iot@lists.fedoraproject.org
-
Paul Whalen -
Peter Robinson