systemd-zram generator
by Chris Murphy
Hi,
This is a systemd generator for setting up swap on zram. If a configuration file, /etc/systemd/zram-generator.conf, does not exist, nothing happens. If it does exist, a zram device is created, swap-create(a)zram0.service is created and started, which does mkswap and swapon using the same systemd logic found with either GPT swap autodiscovery (using partition type GUID) and /dev/urandom based swap.
https://github.com/systemd/zram-generator
This has been packaged in Fedora as 'zram-generator'. While zram package works fine and I see no problems with it, I'm liking the idea of converging on zram-generator, to use existing logic, maintenance and bug fixing. It's also an example of a generator made in Rust.
I've found a few issues, reported upstream, but I don't think any of them negatively impact IoT.
https://github.com/systemd/zram-generator/issues
There's maybe a 50/50 chance we'll get this going in Workstation for Fedora 32 in lieu of a conventional swap partition (pretty much what IoT has been doing from the start, correct?). But I expect to propose it as a system-wide change for Fedora 33. The idea is to make the generator available system wide; and then we can discuss whether to:
1. enable it by default, by including a one size fits all configuration; which any edition/spin can opt-out by either deleting the configuration file or substituting it with their own
2. not enable it by default, by not including a configuration file; which any edition/spin can opt-in by including their own configuration file
3. what might possibly make sense as the most universal on size fits all configuration
Based on the anaconda zram setup; the zram package setup; brief discussion upstream, and my own testing, I've arrived at:
Create a zram device the same size as RAM (i.e. 1:1 ratio), with a cap of 2G or 4G.
The rationale is, upstream says a zram device twice that of RAM is sane because expected compression ratio is 2:1. But going above that really makes no sense. Therefore a 1:1 ratio is conservative enough, but it's also reasonable to go with 1:2 (1/2 that of RAM, for the zram device size), depending on what IoT folks experience has been thus far. The ratio will affect small RAM devices more then workstations and servers, which I expect will pretty much always be subject to the cap.
But if this isn't what upstream zram folks want to do, then it's not a big deal to just have a use case specific configuration files.
4 years
Infineon Optiga SLB9670 on RPi3B+
by David Sastre
Hello,
I posted this info on IRC, but re-posting here so I don't miss responses.
On an RPi3B+ I have plugged in an Infineon Optiga SLB9670 TPM and a DS3231
RTC.
I have activated the relevant overlays:
# tail -3 /boot/efi/config.txt
dtoverlay=i2c-rtc,ds3231
dtparam=spi=on
dtoverlay=tpm-slb9670
Upon reboot, I can see the RTC comes up and works fine:
# dmesg | grep -i rtc0
[ 7.168331] hctosys: unable to open rtc device (rtc0)
[ 15.831043] rtc-ds1307 1-0068: registered as rtc0
# hwclock --show
2020-05-21 12:41:53.438656+02:00
# timedatectl
Local time: Thu 2020-05-21 12:41:56 CEST
Universal time: Thu 2020-05-21 10:41:56 UTC
RTC time: Thu 2020-05-21 10:41:56
Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
However, the TPM is not detected:
# dmesg | grep -i tpm
[ 7.117891] ima: No TPM chip found, activating TPM-bypass!
I have also tried manually applying the overlay to check if there was a
problem with that:
# fdtoverlay -v -i bcm2710-rpi-3-b-plus.dtb -o /var/opt/test.dtb
overlays/tpm-slb9670.dtbo
It's probably relevant, but exceeds my understanding of the problem:
[ 33.793093] ------------[ cut here ]------------
[ 33.798151] /soc/spi@7e204000/spidev@0: buggy DT: spidev listed directly
in DT
[ 33.803446] WARNING: CPU: 1 PID: 680 at drivers/spi/spidev.c:733
spidev_probe+0x228/0x270 [spidev]
[ 33.813566] Modules linked in: soundcore spidev(+) raspberrypi_hwmon
raspberrypi_cpufreq bcm2835_thermal vchiq(C) spi_bcm2835 bcm2835_wdt
bcm2835_rng leds_gpio lz4 zram br_netfilter bridge stp llc drm ip_tables
uas usb_storage smsc95xx
usbnet mii rfkill rtc_ds1307 mmc_block dwc2 gpio_raspberrypi_exp
sdhci_iproc udc_core sdhci_pltfm sdhci i2c_bcm2835 bcm2835 bcm2835_dma
crct10dif_ce phy_generic pkcs8_key_parser fuse aes_neon_bs
[ 33.844943] CPU: 1 PID: 680 Comm: systemd-udevd Tainted: G C
5.6.13-300.fc32.aarch64 #1
[ 33.855299] Hardware name: raspberrypi rpi/rpi, BIOS 2019.10 10/09/2019
[ 33.860557] pstate: 40400005 (nZcv daif +PAN -UAO)
[ 33.865805] pc : spidev_probe+0x228/0x270 [spidev]
[ 33.871001] lr : spidev_probe+0x228/0x270 [spidev]
[ 33.876012] sp : ffff800010303a20
[ 33.876021] x29: ffff800010303a20 x28: ffff00003400c080
[ 33.876029] x27: ffffdd00ed0e1ff8 x26: ffffdd00ed0e1fc0
[ 33.890393] x25: 0000000000000020 x24: ffffdd00b29ea380
[ 33.890405] x23: ffffdd00b29ea058 x22: 0000000000000000
[ 33.890412] x21: ffffdd00b29ea038 x20: ffff00002a96d800
[ 33.890419] x19: 0000000000000000 x18: 0000000000000000
[ 33.890425] x17: 0000000000000000 x16: ffffdd00ec4faae4
[ 33.890432] x15: 0000000000000001 x14: 0000000000000a40
[ 33.890439] x13: ffffdd00ed1b0798 x12: 0000000000000001
[ 33.890446] x11: ffff80001110a820 x10: 0000000000000008
[ 33.890452] x9 : ffffdd00ec65a270 x8 : 0000000000000001
[ 33.890459] x7 : 0000000000aaaaaa x6 : 0000000000000001
[ 33.890465] x5 : 0000000000000000 x4 : ffff00003dd2aa10
[ 33.890472] x3 : ffff00003dd38bc8 x2 : ffff00003dd2aa10
[ 33.890478] x1 : ffff22ff504a0000 x0 : 0000000000000042
[ 33.890488] Call trace:
[ 33.890520] spidev_probe+0x228/0x270 [spidev]
[ 33.890537] spi_drv_probe+0x84/0xe0
[ 33.890551] really_probe+0xe4/0x490
[ 33.890559] driver_probe_device+0xe8/0x130
[ 33.890568] device_driver_attach+0xbc/0xc4
[ 33.890576] __driver_attach+0xa4/0x16c
[ 33.890585] bus_for_each_dev+0x64/0xa0
[ 33.890593] driver_attach+0x28/0x30
[ 33.890600] bus_add_driver+0x148/0x240
[ 33.890609] driver_register+0x7c/0x124
[ 33.890617] __spi_register_driver+0x60/0x70
[ 33.890631] spidev_init+0xa8/0x1000 [spidev]
[ 33.890640] do_one_initcall+0x38/0x1f0
[ 33.890652] do_init_module+0x5c/0x290
[ 33.890661] load_module+0x5f4/0x79c
[ 33.890669] __do_sys_init_module+0xd4/0x140
[ 33.890678] __arm64_sys_init_module+0x20/0x30
[ 33.890687] el0_svc_common.constprop.0+0x78/0x180
[ 33.890692] do_el0_svc+0x28/0x90
[ 33.890702] el0_sync_handler+0x15c/0x200
[ 33.890708] el0_sync+0x164/0x180
[ 33.890714] ---[ end trace 660631be62f36086 ]---
Any help or pointers appreciated. Thanks!
4 years
Issue setting static IP address on Fedora IoT (32.20200429.0)
by Leah Anderson
Hi,
I'm not 100 percent confident this is the correct place for this but feel free to point me to a more appropriate place if there is one.. I'm seeing two separate issues with the latest version of IoT that I was hoping for some assistance with.
1. During boot if DHCP is unavailable it takes a significant amount of time to boot waiting for a timeout to occur. This seems to be related to dracut-network and ignition. The closest thing I could find was a bug report for CoreOS [1] that seemed to be a way to over ride that behavior but I personally couldn't get it to work. Is there a way to override this behavior? I have a system where an IPMI interface reports as having a link but can't get a DHCP address and thus is forced to wait for a timeout.
2. I can't set a static IP address within the OS even though per the docs [2] this should be possible (as it was on 31 IoT). Basically once you set a static address and boot there's a new network connection that's activated and utilizing DHCP while the static one is there unused. I've tried deleting the connection ,recreating it, etc and it just doesn't seem to stick.
[1] https://github.com/coreos/ignition-dracut/issues/94
[2] https://docs.fedoraproject.org/en-US/iot/admin-tasks/
4 years, 1 month
Re: IoT release validation event creation beginning
by Paul Whalen
That is awesome, thank you for doing all of this, Adam! Hoping we get our first
validation event today, will let you know if I see any issues.
Paul
----- Original Message -----
> Hey folks!
>
> I just wanted to post a heads-up that I have finally finished tweaking
> python-wikitcms and the wiki templates themselves to enable the
> creation of release validation events for Fedora-IoT composes. I
> deployed this to production today.
>
> What this should mean is that the next time a "Fedora 33" IoT compose
> completes, we'll get a validation event created for it and an
> announcement mail will be sent to test-announce@ , just like for
> regular Fedora composes.
>
> IoT validation events will have only one matrix page, called "General".
> I based the template on the one pwhalen has been using to manually
> create events. This is Paul's page:
>
> https://fedoraproject.org/wiki/User:Pwhalen/QA/IoT_Test_Template
>
> and this is the 'official' Wikitcms matrix template page:
>
> https://fedoraproject.org/wiki/Template:General_IoT_test_matrix
>
> There will still be a Summary page, even though it doesn't make much
> sense with only one matrix page, just because it'd be a chunk of work
> to disable the use of Summary pages in this situation. I might do that
> later.
>
> IoT composes are slightly "odd" in that they're always built with the
> 'production' type which is meant for release candidate composes, even
> though they're functionally nightlies they don't use the 'nightly'
> type. Because of this, I've had to special-case the handling of IoT
> composes throughout the code, and for wikitcms purposes we will
> essentially treat all IoT composes as if they were nightlies. The
> 'milestone' for IoT validation events will always be "RC" (at least as
> long as the composes are still done this way), and the announcement
> emails will always be the "nightly"-style emails, not the "candidate"-
> style emails.
>
> Page names, category names etc. follow the same general pattern as
> those for 'normal' validation events, but with "Fedora-IoT" or "IoT" in
> them, so the actual matrix page for an event will be something like
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200513.0_G...
> .
> There will also be a 'current' redirect page:
> https://fedoraproject.org/wiki/Test_Results:Current_IoT_General_Test
> categories will exist with similar name modifications, so there'll be a
> https://fedoraproject.org/wiki/Category:Fedora-IoT_33_Nightly_Test_Results
> and so on.
>
> I'll also set up testcase_stats for this stream once we have a
> validation page, and I'll hook up openQA result reporting so openQA
> tests that run on IoT composes will report results to the wiki.
>
> The event creation logic works exactly as for the 'main' release
> stream: relvalconsumer will kick in for every compose that's for the
> 'next' Fedora release (so 33 ATM) and decide whether to create an event
> depending on how long it's been since the previous event and whether
> any 'significant' packages have changed. (I may actually tweak that
> 'significant' package list for IoT, now I think about it.) So just as
> for the 'main' release stream, we'll get new events every few days, on
> average once a week or so. Events can also be manually created if we
> particularly want one for a given compose.
>
> This is a fairly major change to things so there will likely be some
> rough edges: please report anything you notice, whether it's straight
> up bugs or just things like boilerplate text that doesn't actually
> entirely make sense for an alternate release stream, stuff like that.
>
> It still hasn't been decided (AFAIK) if IoT will be a release-blocking
> deliverable/primary Edition for Fedora 33, but this change should set
> us up well if it is, and if it isn't, we can just treat this whole
> stream as 'optional extra' testing, it still won't hurt to have the
> events.
>
> Thanks folks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
4 years, 1 month
