|
Dan,
That makes sense. I'm experienced with image creation, so now that I have the right mental model I should be able to forge ahead.
Thanks for your help here and on the github repo.
-b
From: Dan Nicholson <dbn endlessos org>
Sent: Thursday, March 3, 2022 1:13 PM To: Barrett Strausser <bstrausser locusrobotics com> Cc: Jonathan Lebon <jlebon redhat com>; ostree-list gnome org <ostree-list gnome org> Subject: Re: [EXTERNAL] - Re: Development Workflow In your case, you most likely want ostree-test to be a VM that you
create from the ostree commit, although https://salsa.debian.org/debian/ostree/-/blob/debian/latest/debian/ostree-boot-examples/README.md has instructions for converting a running system to boot from an ostree commit. I've never personally tried that, though. In other words, rather than making the test VM start from a focal image, you want to create your own image. This would come from the commit you create, which itself could be based on focal. You need to take the /sysroot you created and make it into an actual bootable image. This part is rigorously undocumented, primarily because making a bootable image is very platform and target specific. However, here's something that could maybe work with a single partition and an old school MBR partition table: truncate -s 1G image echo "start=2048, bootable" | sfdisk image img_size=$(stat -c %s image) offset=$((2048 * 512)) fs_size=$(((img_size - offset) / 1024)) fs_uuid=$(uuidgen) mke2fs -F -t ext4 -d /sysroot -U $fs_uuid -E offset=$offset image $fs_size grub-install image qemu-img convert -O qcow2 image image.qcow2 I'm sure that won't quite work, but hopefully it gets you pointed in the right direction. -- Dan Nicholson | +1.206.437.0833 | Endless On Wed, Mar 2, 2022 at 6:43 AM Barrett Strausser <bstrausser locusrobotics com> wrote: > > Thanks for both responses. > > I think I am going to have to sit and invest the time to understand it more. The links and positive feedback about approaches is helpful. > > I do have a question about boot integration / boot integration testing that still isn't completely clear to me. > > > The setup I have now is two virtual machines (ostree-build, ostree test). There are vagrant virtualbox machines, both running ubuntu focal (that's my target in production) > > I am building images, committing to repos and hosting the http server on ostree-build. > I am attempting to deploy on ostree-test. > > On ostree-test, I appear to be do everything correctly but my deployment never "activates" > > vagrant@ostree-test-1:~$ sudo ostree admin deploy upstream:os/ubuntu/x86/focal --sysroot=/sysroot --os=ubuntu-focal > Copying /etc changes: 0 modified, 0 removed, 0 added > Bootloader updated; bootconfig swap: yes; deployment count change: 1 > > vagrant@ostree-test-1:~$ sudo ostree admin status --sysroot /sysroot > ubuntu-focal b079b283b79d0283aecf1391aba6f5900afbd5f39a89dbfc8313717db1e8487d.1 > origin refspec: upstream:os/ubuntu/x86/focal > ubuntu-focal b079b283b79d0283aecf1391aba6f5900afbd5f39a89dbfc8313717db1e8487d.0 > origin refspec: upstream:os/ubuntu/x86/focal > > I have checked in /sysroot/boot/loader/entries and everything looks correct. What might I be missing? > > > My real questions are > > On an existing mainstream distribution what is the result of running "ostree admin init-fs /sysroot". I get that it creates the /sysroot, but are there other side-effects? > How does the /sysroot relate to /boot on the existing system. I think I might have a fundamental misunderstanding of taking an existing system and turning it into an ostree managed one. > > > Thanks for the help > > > ________________________________ > From: Jonathan Lebon <jlebon redhat com> > Sent: Monday, February 28, 2022 9:34 AM > To: Barrett Strausser <bstrausser locusrobotics com> > Cc: ostree-list gnome org <ostree-list gnome org> > Subject: [EXTERNAL] - Re: Development Workflow > > Hi Barrett, > > On Sat, Feb 26, 2022 at 1:05 PM Barrett Strausser > <bstrausser locusrobotics com> wrote: > > > > Hello All, > > > > I am newly using OSTree, I'm able to create repos/make commits etc. However, I'm looking for input or advice on best developer workflows after committing to a repo. Obviously, I can introduce hardware into the loop but I'm looking for something more software oriented that could eventually be used in CI without relying on bare-metal. > > > > I recognize this is not purely an OSTree concern, but I figured the group would have good insights. At the moment I'm trying to use some combination of qemu/libguestfs to create a test bed, but I'm wondering what else folks are using. I am trying to work through the contents of https://github.com/ostreedev/ostree/tree/main/tests to see what I can figure out as well. > > For Fedora CoreOS and RHCOS at least, we indeed make heavy use of > qemu. Might be worth looking at the CI for the ostree repo, > specifically the `continuous-integration/jenkins/pr-merge` test. It > wraps https://github.com/coreos/coreos-assembler, which is a tool that > uses qemu for building and testing ostree-based OS images. > coreos-assembler is very opinionated of course, so might not be usable > as is to you. But if you're using OSTree for the OS, the main idea is > likely still applicable (pkgs/binaries -> OSTree commit -> OS images > -> QEMU tests). > > CAUTION: This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know the content is safe. > > _______________________________________________ > ostree-list mailing list > ostree-list gnome org > https://mail.gnome.org/mailman/listinfo/ostree-list CAUTION: This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know the content is safe. |