January 2018 - Atomic Working Group (ARCHIVED)

[atomic-wg] Issue #388: Add Fedora AMIs to govcloud region.
by David Duncan 08 Feb '18

08 Feb '18

davdunc reported a new issue against the project: `atomic-wg` that you are following: `` There are currently no Fedora images in the AWS govcloud region. To publish images in the govcloud, we must follow the ITAR guidelines. The AWS GovCloud (United States) region supports United States International Traffic in Arms Regulations (ITAR) compliance. International Traffic in Arms Regulations (ITAR) controls the export of defense-related articles and states that no non-US person can have physical or logical access to the articles stored in the ITAR environment. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/388

2 2

[atomic-wg] Issue #394: Write up on using other docker versions on Atomic Host
by Steve Milner 07 Feb '18

07 Feb '18

smilner reported a new issue against the project: `atomic-wg` that you are following: `` We need to have documentation showing how to use other docker versions on Atomic Host in the event the admin wishes to use an alternate docker runtime. References: - https://jebpages.com/2017/11/08/install-docker-ce-on-fedora-atomic-host-if-… `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/394

4 12

[atomic-wg] Issue #407: cri-o in Atomic Host
by Steve Milner 07 Feb '18

07 Feb '18

smilner reported a new issue against the project: `atomic-wg` that you are following: `` In [this ticket](https://pagure.io/atomic-wg/issue/360) is was decided to continue to keep ``docker`` in the base. However, we want to make sure that people have the option to use ``cri-o`` as their container runtime if they would like to do so (and possibly other runtimes in the future). For consistency it would seem ``cri-o`` should be added to base as well but this would increase the size. However, we already have system containers for both ``cri-o`` and ``docker``. How can we provide a good ``cri-o`` experience for our Atomic Host user base keeping in mind that ``docker`` will be part of the base already? /cc @dwalsh @mpatel `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/407

3 7

[atomic-wg] Issue #406: Create buildah container for Atomic Host usage
by Steve Milner 07 Feb '18

07 Feb '18

smilner reported a new issue against the project: `atomic-wg` that you are following: `` We need a ``buildah`` image which can be used on Atomic Host. **Related**: - https://pagure.io/atomic-wg/issue/402 - https://github.com/projectatomic/buildah/issues/158 `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/406

3 6

[atomic-wg] Issue #351: atomic working group talks/sessions for devconf.cz
by Dusty Mabe 01 Feb '18

01 Feb '18

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` Let's strategize on what sessions we want to submit for devconf this year. Please update the description with a bulleted list of sessions we'd like to submit as well as the status for each session. For example: - Atomic Host 101 Hands On Lab - Not Yet Submitted - Dusty Mabe Please add a comment anytime you update the description with a changelog of what you changed in the description. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/351

6 11

[atomic-wg] Issue #382: growpart seems to fail on aarch64 atomic host cloud image
by Dusty Mabe 01 Feb '18

01 Feb '18

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` I'm not sure why but would like others to confirm/deny that it happens for them with [the image from the first f27 release](https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-…. ``` [root@cloudhost ~]# rpm-ostree status State: idle Deployments: ● fedora-atomic:fedora/27/aarch64/atomic-host Version: 27.1 (2017-11-10 12:02:44) Commit: da1bd08012699a0aacaa11481d3ed617477858aab0f2ea7300168ce106202255 GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4 [root@cloudhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 40G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 4.8G 0 part └─atomicos-root 253:0 0 4.8G 0 lvm /sysroot sdb 8:16 0 368K 0 disk sdc 8:32 0 10G 0 disk [root@cloudhost ~]# growpart /dev/sda 3 GPT PMBR size mismatch (12582911 != 83886079) will be corrected by w(rite). attempt to resize /dev/sda failed. sfdisk output below: | GPT PMBR size mismatch (12582911 != 83886079) will be corrected by w(rite). | Backup files: | PMBR (offset 0, size 512): /tmp/growpart.gpxB0y/backup-sda-0x00000000.bak | GPT Header (offset 512, size 512): /tmp/growpart.gpxB0y/backup-sda-0x00000200.bak | GPT Entries (offset 1024, size 16384): /tmp/growpart.gpxB0y/backup-sda-0x00000400.bak | | Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors | Units: sectors of 1 * 512 = 512 bytes | Sector size (logical/physical): 512 bytes / 512 bytes | I/O size (minimum/optimal): 512 bytes / 512 bytes | Disklabel type: gpt | Disk identifier: 5B1DEB7C-8134-464C-8767-0883E53D8B64 | | Old situation: | | Device Start End Sectors Size Type | /dev/sda1 2048 411647 409600 200M EFI System | /dev/sda2 411648 2508799 2097152 1G Linux filesystem | /dev/sda3 2508800 12580863 10072064 4.8G Linux LVM | | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Created a new GPT disklabel (GUID: 5B1DEB7C-8134-464C-8767-0883E53D8B64). | /dev/sda1: Created a new partition 1 of type 'EFI System' and of size 200 MiB. | Partition #1 contains a vfat signature. | /dev/sda2: Created a new partition 2 of type 'Linux filesystem' and of size 1 GiB. | Partition #2 contains a ext4 signature. | /dev/sda3: The last usable GPT sector is 12582878, but 83886079 is requested. | Failed to add #3 partition: Invalid argument | Leaving. | FAILED: failed to resize ***** WARNING: Resize failed, attempting to revert ****** 512+0 records in 512+0 records out 512 bytes copied, 0.0930597 s, 5.5 kB/s ***** Appears to have gone OK **** ``` `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/382

2 8

[atomic-wg] Issue #412: aarch64 qcow won't boot when installed from testing tree
by Dusty Mabe 01 Feb '18

01 Feb '18

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` The updates tree works fine. The testing tree yields a non-bootable machine with the following message after passing the grub menu: ``` error: failed to create kernel parameters. Failed to boot both default and fallback entries. Press any key to continue... ``` After trying again I see: ``` error: failed to install/update FDT. Press any key to continue... ``` The current difference between the updates and testing aarch64 trees is: ``` ostree diff commit old: 2f78eaf5c843a3a8c03b21ba9db41073864e8a6b941679a126ac27b910fe66dc ostree diff commit new: 40a4fdfb17242b97bffb1da84c127f60131ca49c1705a407e327ffe32357c39d Upgraded: NetworkManager 1:1.8.4-7.fc27 -> 1:1.8.6-1.fc27 NetworkManager-libnm 1:1.8.4-7.fc27 -> 1:1.8.6-1.fc27 NetworkManager-team 1:1.8.4-7.fc27 -> 1:1.8.6-1.fc27 cloud-utils-growpart 0.27-18.fc27 -> 0.30-1.fc27 criu 3.6-1.fc27 -> 3.7-3.fc27 glib2 2.54.2-1.fc27 -> 2.54.3-2.fc27 glibc 2.26-21.fc27 -> 2.26-24.fc27 glibc-all-langpacks 2.26-21.fc27 -> 2.26-24.fc27 glibc-common 2.26-21.fc27 -> 2.26-24.fc27 gnutls 3.5.16-4.fc27 -> 3.5.17-1.fc27 grub2-common 1:2.02-19.fc27 -> 1:2.02-21.fc27 grub2-efi-aa64 1:2.02-19.fc27 -> 1:2.02-21.fc27 grub2-tools 1:2.02-19.fc27 -> 1:2.02-21.fc27 grub2-tools-extra 1:2.02-19.fc27 -> 1:2.02-21.fc27 grub2-tools-minimal 1:2.02-19.fc27 -> 1:2.02-21.fc27 libassuan 2.4.3-6.fc27 -> 2.5.1-1.fc27 libcrypt-nss 2.26-21.fc27 -> 2.26-24.fc27 libgcrypt 1.8.1-3.fc27 -> 1.8.2-1.fc27 libtasn1 4.12-3.fc27 -> 4.13-1.fc27 oci-register-machine 0-5.12.git3c01f0b.fc27 -> 0-5.13.git66691c3.fc27 ostree 2017.15-1.fc27 -> 2018.1-1.fc27 ostree-grub2 2017.15-1.fc27 -> 2018.1-1.fc27 ostree-libs 2017.15-1.fc27 -> 2018.1-1.fc27 python3 3.6.3-2.fc27 -> 3.6.4-3.fc27 python3-libs 3.6.3-2.fc27 -> 3.6.4-3.fc27 rpm-ostree 2017.11-1.fc27 -> 2018.1-1.fc27 rpm-ostree-libs 2017.11-1.fc27 -> 2018.1-1.fc27 sed 4.4-3.fc27 -> 4.4-4.fc27 timedatex 0.4-5.fc27 -> 0.5-2.fc27 vim-minimal 2:8.0.1427-1.fc27 -> 2:8.0.1428-3.fc27 Removed: python-rhsm-certificates-1.20.1-3.fc27.aarch64 Added: gdbm-devel-1:1.13-6.fc27.aarch64 subscription-manager-rhsm-certificates-1.21.1-1.fc27.aarch64 ``` I suspect grub is the problem but it will need more testing. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/412

2 6

[atomic-wg] Issue #349: evaluate atomic-ci repo
by Dennis Gilmore 01 Feb '18

01 Feb '18

ausil reported a new issue against the project: `atomic-wg` that you are following: `` @releng had setup a atomic-ci tree based on the rawhide buildroot to enable a place for quick availability to test rawhide builds. per https://pagure.io/releng/pull-request/7094 it had been broken for the last 3 months. I would like for it to be evaluated and either be something cared about and used, setting up automated testing, or something we nuke from orbit due to no longer needing to be used. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/349

4 6

[atomic-wg] Issue #372: proposal to include firewalld in atomic host
by Dusty Mabe 01 Feb '18

01 Feb '18

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` I started [a thread](https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-April/msg00022.html) some time ago on including firewalld in atomic host. I don't believe we received any major objections there so I'm going to propose we move forward with including it in the host. Some highlights from the mail thread: - good for new users since docker adds iptables rules dynamically it's really hard to properly get an iptables config that accurately reflects the rules you want to add without including the dynamic rules docker adds. Also if you do get a config that works and apply it while the system is running then you lost the dynamic rules docker added. - good for openshift origin / kubernetes From @jdetiber : *The iptables-based management that is done in openshift-ansible has always been a hack that was only meant to be a stopgap until firewalld was fully supported up and down the entire stack. There are way too many edge cases that could cause issues with the create/save/restore process. We tried to limit those by using a dedicated chain for openshift-ansible rules, but having another process modify rules without using '-w' or other modifications to the firewall could inadvertently be persisted with the iptables-save.* - make sure we avoid the default zones/policies from firewalld from ben breard on list: if we include it we would want to *clean up the absurd default zones & policies and have something relevant for AH out of the box* `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/372

12 29

[atomic-wg] Issue #345: 20171003 ISO does not boot on minnowboard
by Josh Berkus 01 Feb '18

01 Feb '18

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` 1. wrote Fedora-Atomic-ostree-x86_64-26-20171003.0.iso to usb key (used in prior tests) 2. ran kickstart install of Atomic using my standard f26 kickstart 3. install ran 4. On rebook, system goes through bootup messages and dmesg for around 20 seconds, then without warning reboots. This cycle continues as long as I let it (I counted 5 cycles, then turned it off). 5. Tested with a new USB key and a different minnowboard. Same result. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/345

4 16

2024

2023

2022

2021

2020

2019

2018

2017

Atomic Working Group (ARCHIVED) January 2018