Remove anaconda #556

ajeddeloh · 2019-06-14T21:39:15Z

Only for qemu right now. Trying to make sense of the buildextend-metal, it looks like it's running anaconda again?
Only tested with fcos
We ought to not use yaml for image.yaml, it's a pain to parse
Doesn't actually remove anaconda, just switches to not using it

cgwalters

Looks pretty easy; shouldn't be too hard to extend to metal-uefi I'd think. Will play with this too.

src/create_disk.sh

cgwalters · 2019-06-17T23:37:30Z

src/create_disk.sh

+# init the ostree
+ostree admin init-fs rootfs
+ostree pull-local "$ostree" --repo rootfs/ostree/repo
+ostree admin os-init fedora-coreos --sysroot rootfs


Let's continue templating this from the manifest.

cgwalters · 2019-06-17T23:39:42Z

We ought to not use yaml for image.yaml, it's a pain to parse

From shell script yes but Python is good for that right?

ajeddeloh · 2019-06-17T23:41:29Z

From shell script yes but Python is good for that right?

Misc idea: re-render to a file in tmp it as json using python. Then bash utils can use jq and python can use the native python implementation.

ajeddeloh · 2019-06-18T00:05:38Z

Updated so we build bios+uefi images now.

lucab · 2019-06-18T08:20:36Z

src/create_disk.sh

+ostree admin init-fs rootfs
+ostree pull-local "$ostree" --repo rootfs/ostree/repo
+ostree admin os-init fedora-coreos --sysroot rootfs
+kargs='root=/dev/disk/by-label/root console=ttyS0,115200n8 console=ttyS0 rootflags=defaults,prjquota rw $ignition_firstboot'


Can we move the middle part of this to two variables ($consoleflags and $rootflags) that can be overridden via environment?

Also we need to use VM_TERMINAL instead of ttyS0.

@lucab what environment precisely? This is run in supermin, so the environment is pretty sparse.

The kargs currently live in a kickstart. Seems like they ought to live in image.yaml?

Summarizing some discussion on #fedora-coreos: We're going to keep the kargs that relate to this script in this script but move the other kargs to cmd-build since we can do thing like templating (for things like $VM_TERMINAL there since it's not in supermin. We may move them later, but that's for another PR.

cgwalters · 2019-06-18T12:34:22Z

Misc idea: re-render to a file in tmp it as json using python. Then bash utils can use jq and python can use the native python implementation.

Sure, fine by me.

ajeddeloh · 2019-06-18T18:50:55Z

I'll deal with doing the yaml->json re-rendering later in another PR. Doesn't need to happen in this one.

src/vmdeps.txt

cgwalters · 2019-06-18T20:42:59Z

src/cmd-build

+build_image() {
+	local size
+	size="$(python3 -c 'import sys, yaml; print(yaml.load(sys.stdin)["size"])' < "$configdir/image.yaml")G"
+	qemu-img create -f qcow2 "$workdir/diskimage.qcow2" "$size"


Instead of $workdir this should be in the build tmpdir $(pwd) (which would require passing it as an argument to runvm for cleanliness)

In that case might as well pass the base image path directly to runvm, right?

ajeddeloh · 2019-06-18T23:12:51Z

Addressed things besides the mutli-arch bit, waiting to learn a bit more about ppc64le on that.

Do we need to support arm64 on non-uefi platforms?

r4f4 · 2019-06-19T06:36:45Z

No, aarch64 is EFI-only.

src/cmd-build

src/create_disk.sh

ashcrow · 2019-06-19T15:02:46Z

cc @darkmuggle @miabbott @imcleod

ajeddeloh · 2019-06-19T19:54:55Z

Added a check so we fall back to anaconda on non-x86_64 arches. Addressed @jlebon's comments.

Also worth calling out we need coreos/fedora-coreos-config#105 to not get failed units.

Do we want to handle buildextend-metal here or in another PR?
How important is it to use the size estimation for that?
Does it make sense to use the size estimation for qemu as well?

If we do want to continue creating the small images for metal but do not for qemu then the buildextend-metal will need to recreate the image entirely since we can't shrink xfs filesystems.

cgwalters · 2019-06-19T20:43:26Z

Added a check so we fall back to anaconda on non-x86_64 arches.

As a short term that's probably OK, will make it easier to test without disrupting the multi-arch porting in progress.

How important is it to use the size estimation for that?

If we don't we're back in the guessing game of how big the disk should be...

Does it make sense to use the size estimation for qemu as well?

No, that's where size from image.yaml comes in.

jlebon · 2019-06-19T20:45:39Z

Do we want to handle buildextend-metal here or in another PR?

I'm assuming buildextend-metal still works fine after this, right? If so, then yeah, I don't see the harm in doing it as a follow-up!

ajeddeloh · 2019-06-19T20:49:11Z

Right now cmd-buildextend-metal recreates entirely new images (it has to, the partition and FS are smaller). so right now the BM images are still created using anaconda.

So it sounds like this should not wait for the buildextend-metal (be and qemu only for the moment) and I'll follow up with the corresponding cmd-buildextend-metal changes.

Is cmd-buildextend-metal expected to work with non-x86 images? It hardcodes BIOS and UEFI options.

cgwalters · 2019-06-19T21:09:35Z

So it sounds like this should not wait for the buildextend-metal (be and qemu only for the moment) and I'll follow up with the corresponding cmd-buildextend-metal changes.

I'm also OK with that.

ajeddeloh · 2019-06-19T22:07:56Z

Ok, this should be ready for more review then. Also gated the changes to gf-platformid to only take effect on x86_64 as well.

src/gf-platformid

jlebon · 2019-06-20T17:39:20Z

This looks good to me! (Though we can probably squash 7ef9087 into ef0450c, right? Edit: and 4e490eb into 7640c90)
Let's get coreos/fedora-coreos-config#105 in first.

ajeddeloh · 2019-06-20T19:25:21Z

I think I want to leave the latter set of commits separate. Makes it clear what changes for UEFI vs removing anaconda in general.

jlebon · 2019-06-20T20:34:42Z

Testing this locally (privileged), I get:

+ mount /dev/sdb1 /srv/fcos/cache
mount: /srv/fcos/cache: special device /dev/sdb1 does not exist.
+ chown -h -R jlebon:jlebon /srv/fcos
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/config': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/.lock': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/tmp/cache': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/tmp': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/extensions': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/state': Operation not permitted
chown: changing ownership of '/srv/fcos/cache/pkgcache-repo/refs/heads/rpmostree/pkg/openssl-libs/1_3A1.1.1-3.fc29.x86__64': Operation not permitted
...

So there are two issues here. The first is #560 (comment). The second is that:

# ensure the user of files created do not have root ownership
trap 'chown -h -R ${USER}:${USER} ${workdir}' EXIT

which is now running in the privileged path for the first time. This will fail though, because the cache has a bunch of stuff owned by root and we're trying to chown it to something else as real UID != 0. I'm actually not entirely sure why we need this, since we're running supermin as the current user, so everything created through the 9p mount should already be owned by that user.

Dropped that, and got farther (it created the partitions at least), but now hitting:

error: Importing 90864833fa30b1aeb2ac6a5b9426bc2fdbbda227c090e70251d128d2f0835254.dirtree: fstatat(90/864833fa30b1aeb2ac6a5b9426bc2fdbbd...

Haven't debugged that yet. But probably comes down to the expanding ways in which one can now run cosa.

Tried unprivileged mode quickly. I got further but hit:

+ mkdir -p tmp/anaconda
+ img_base=tmp/fedora-coreos-30.1-base.qcow2
++ find /usr/lib/coreos-assembler-anaconda/ -name '*CHECKSUM'
++ head -1
+ checksum_location=/usr/lib/coreos-assembler-anaconda/Fedora-Everything-29-1.2-x86_64-CHECKSUM
+ '[' -n 1 ']'
+ img_qemu=fedora-coreos-30.1-qemu.qcow2
+ '[' x86_64 == x86_64 ']'
+ build_image
+ local size kargs
++ python3 -c 'import sys, yaml; print(yaml.load(sys.stdin)["size"])'
-c:1: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.py.
+ size=8G
++ python3 -c 'import sys, yaml; args = yaml.load(sys.stdin)["extra-kargs"]; print(" ".join(args))'
-c:1: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.py.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyError: 'extra-kargs'
+ kargs=

Just needs a .get("extra-args", []) to make this work I think. Also, could use safe_load to squash those warnings.

jlebon · 2019-06-20T20:36:58Z

OK, right also needs:

diff --git a/src/create_disk.sh b/src/create_disk.sh
index a0281a2..e1029e7 100755
--- a/src/create_disk.sh
+++ b/src/create_disk.sh
@@ -42,7 +42,7 @@ mount "${disk}2" rootfs/boot/efi

 # init the ostree
 ostree admin init-fs rootfs
-ostree pull-local "$ostree" --repo rootfs/ostree/repo
+ostree pull-local "$ostree" "$ref" --repo rootfs/ostree/repo
 ostree admin os-init "$os_name" --sysroot rootfs
 allkargs='root=/dev/disk/by-label/root rootflags=defaults,prjquota rw $ignition_firstboot'
 allkargs="$allkargs $extrakargs"

jlebon · 2019-06-20T21:03:58Z

With the workarounds for the above, I got this working in both the privileged and unprivileged paths! 🎉

Also switch to BLS. Continue to use anaconda on other arches.

Install both uefi and bios grub, but have them read the same config.

ajeddeloh · 2019-06-20T21:05:52Z

Ok, just pushed the $ref and python loader warning/.get() fixes. Lets fix the other unrelated issues in their own PRs

jlebon · 2019-06-20T21:08:12Z

Awesome, let's do this!

jlebon · 2019-06-21T14:05:05Z

So there are two issues here

Both fixed in #564.

ajeddeloh mentioned this pull request Jun 14, 2019

WIP: remove anaconda #311

Closed

cgwalters reviewed Jun 17, 2019

View reviewed changes

ajeddeloh force-pushed the rm-anaconda branch from 88faf4d to 1f91383 Compare June 18, 2019 00:05

lucab reviewed Jun 18, 2019

View reviewed changes

cgwalters reviewed Jun 18, 2019

View reviewed changes

src/vmdeps.txt Show resolved Hide resolved

cgwalters reviewed Jun 18, 2019

View reviewed changes

ajeddeloh force-pushed the rm-anaconda branch from 1f91383 to 64a329b Compare June 18, 2019 23:12

jlebon reviewed Jun 19, 2019

View reviewed changes

src/cmd-build Outdated Show resolved Hide resolved

src/create_disk.sh Show resolved Hide resolved

Andrew Jeddeloh added 2 commits June 19, 2019 12:06

bottlecap: use kvm device instead of --privileged

7e2625b

vmdeps: add things needed for removing anaconda

128671b

cgwalters mentioned this pull request Jun 19, 2019

Add an ostree-admin-esp-upgrade subcommand to update the EFI System Partition ostreedev/ostree#1873

Closed

ajeddeloh force-pushed the rm-anaconda branch from 64a329b to 19ac561 Compare June 19, 2019 19:53

ajeddeloh force-pushed the rm-anaconda branch from 19ac561 to 11995ac Compare June 19, 2019 22:06

jlebon mentioned this pull request Jun 20, 2019

overlay/systemd: add boot.mount unit coreos/fedora-coreos-config#105

Merged

jlebon reviewed Jun 20, 2019

View reviewed changes

src/gf-platformid Outdated Show resolved Hide resolved

ajeddeloh force-pushed the rm-anaconda branch from 11995ac to 7ef9087 Compare June 20, 2019 16:06

ajeddeloh force-pushed the rm-anaconda branch from 7ef9087 to 35deb74 Compare June 20, 2019 19:24

Andrew Jeddeloh added 3 commits June 20, 2019 14:04

src: add disk create script, grub config

95be85a

cmd-build: don't use anaconda for x86_64

c7df795

Also switch to BLS. Continue to use anaconda on other arches.

create_disk: build uefi+bios images

5360e92

Install both uefi and bios grub, but have them read the same config.

ajeddeloh force-pushed the rm-anaconda branch from 35deb74 to 5360e92 Compare June 20, 2019 21:05

jlebon merged commit eb0e8cb into coreos:master Jun 20, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove anaconda #556

Remove anaconda #556

ajeddeloh commented Jun 14, 2019

cgwalters left a comment

cgwalters Jun 17, 2019

cgwalters commented Jun 17, 2019

ajeddeloh commented Jun 17, 2019

ajeddeloh commented Jun 18, 2019

lucab Jun 18, 2019

cgwalters Jun 18, 2019

ajeddeloh Jun 18, 2019

cgwalters Jun 18, 2019

ajeddeloh Jun 18, 2019

cgwalters commented Jun 18, 2019

ajeddeloh commented Jun 18, 2019

cgwalters Jun 18, 2019

ajeddeloh Jun 18, 2019

ajeddeloh commented Jun 18, 2019

r4f4 commented Jun 19, 2019

ashcrow commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019 •

edited

Loading

cgwalters commented Jun 19, 2019

jlebon commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019

cgwalters commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019

jlebon commented Jun 20, 2019 •

edited

Loading

ajeddeloh commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 20, 2019

ajeddeloh commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 21, 2019

Remove anaconda #556

Remove anaconda #556

Conversation

ajeddeloh commented Jun 14, 2019

cgwalters left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters commented Jun 17, 2019

ajeddeloh commented Jun 17, 2019

ajeddeloh commented Jun 18, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters commented Jun 18, 2019

ajeddeloh commented Jun 18, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajeddeloh commented Jun 18, 2019

r4f4 commented Jun 19, 2019

ashcrow commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019 • edited Loading

cgwalters commented Jun 19, 2019

jlebon commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019

cgwalters commented Jun 19, 2019

ajeddeloh commented Jun 19, 2019

jlebon commented Jun 20, 2019 • edited Loading

ajeddeloh commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 20, 2019

ajeddeloh commented Jun 20, 2019

jlebon commented Jun 20, 2019

jlebon commented Jun 21, 2019

ajeddeloh commented Jun 19, 2019 •

edited

Loading

jlebon commented Jun 20, 2019 •

edited

Loading