Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WIP: remove anaconda #311

Closed
wants to merge 6 commits into from
Closed

WIP: remove anaconda #311

wants to merge 6 commits into from

Conversation

ajeddeloh
Copy link
Contributor

Very rough atm

@dustymabe
Copy link
Member

I asked andrew if he could post this. very much a WIP so hold off on deep review

@dustymabe
Copy link
Member

two items identified by andrew as holding up this work:

1 - ostreedev/ostree#1774 - so we don't have to hardcode a grub config (for now). I've asked robert to take a look.
2 - making sure firstboot processes don't run - it seems anaconda does the right thing here, but since we aren't using anaconda we need to make sure we disable whatever mechanism is causing it to start in the ostree itself. We should be able to add something to our postprocess in the manifest.yaml.

@rfairley
Copy link
Contributor

rfairley commented Feb 15, 2019 •
edited
Loading

Built a few ostree RPMs that can be used for dev purposes for now:
f28: https://koji.fedoraproject.org/koji/taskinfo?taskID=32835828
f29: https://koji.fedoraproject.org/koji/taskinfo?taskID=32835841
f30: https://koji.fedoraproject.org/koji/taskinfo?taskID=32835878

These RPMs are built from the tree at https://github.com/rfairley/ostree/commits/rfairley-bls-config-dev-rpm.

I have tested the f29 RPM on Fedora Atomic Host 29. Executing the commands in this comment should now work to avoid the hardcoded grub config part.

The RPMs ostree and ostree-libs should be installed - the other RPMs being optional. On F29AH I did this:

curl --remote-name-all https://kojipkgs.fedoraproject.org//work/tasks/5842/32835842/ostree-2019.1.16.g98b27889-5.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/5842/32835842/ostree-libs-2019.1.16.g98b27889-5.fc29.x86_64.rpm
rpm-ostree override replace ostree-*

Running the same ostree commands as used in this PR, but with the following appended to rootfs/ostree/repo/config, should avoid running into the assertion in ostreedev/ostree#1774 (comment).

# in rootfs/ostree/repo/config:
[sysroot]
bootloader=none

@ajeddeloh
Copy link
Contributor Author

@dustymabe updated to be in sync with latest-ish master. Got a lot of hacks still in there. metal-{bios/uefi} are not implemented yet. doesn't use the new ostree bits yet. but you can build an image and play with anaconda (will need to edit the grub config to not mask the unit via kernel command line).

@dustymabe
Copy link
Member

thanks @ajeddeloh !

cgwalters
cgwalters reviewed Feb 19, 2019
View reviewed changes
src/cmd-build
iso_location="${workdir}/installer/$(basename "${INSTALLER}")"
checksum_location="${workdir}/installer/$(basename "${INSTALLER_CHECKSUM}")"
rm -f "$(pwd)/diskimage.raw"
truncate -s 8G "$(pwd)/diskimage.raw"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get the size from image.yaml.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we parse image.yaml into anything readable by bash anywhere?

src/create_disk.sh
# HACK ALERT - wait for partition rescans
sleep 2
# FIXME ostree needs symlinks
mkfs.ext2 "$(getpart ${disk} 1)" -L boot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ext 2 ?

src/create_disk.sh
# FIXME ostree needs symlinks
mkfs.ext2 "$(getpart ${disk} 1)" -L boot
mkfs.fat "$(getpart ${disk} 2)" -n EFI-SYSTEM
mkfs.xfs "$(getpart ${disk} 4)" -L root
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently we also force on -m reflink=1 but eh...I guess we can just take that default from mkfs in the near future.

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
ostree admin deploy "$ref" --sysroot rootfs --os fedora-coreos
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fedora-coreos values are ${name} in cmd-build.sh.

src/create_disk.sh
checksum=$(cat rootfs/boot/ostree/*/{vm*,init*} | sha256sum | cut -d ' ' -f 1)
vmlinuz=$(basename rootfs/boot/ostree/*/vm*)
initrd=$(basename rootfs/boot/ostree/*/init*)
echo "Checksum is: $checksum initrd is $initrd vmlinuz is $vmlinuz"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This data is more canonically stored in the BLS fragment.

src/grub.cfg
insmod xfs
set root='hd0,gpt1'
set hash="HASHHASH"
linux16 /ostree/fedora-coreos-${hash}/VMLINUZ no_timer_check console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 ip=dhcp rd.neednet=1 rw $ignition_firstboot root=LABEL=root ostree=/ostree/boot.1/fedora-coreos/${hash}/0 coreos.oem.id=qemu systemd.mask=systemd-firstboot.service
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, definitely better to use the data from the BLS here right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still working on getting that working, but yeah that's the idea at least for the time being

@cgwalters
Copy link
Member

Since #380 landed as promised I'm happy to do the rebase of this PR myself - do you have any outstanding changes?

@nhorman
Copy link

nhorman commented Mar 20, 2019

@cgwalters if you can rebase, I can pull this in

@cgwalters cgwalters mentioned this pull request Apr 17, 2019
Open
@nullr0ute
Copy link

Fedora IoT still uses anaconda support in in rpm-ostree and related because of the status of certain required HW support. I'm not sure how this relates to assembler but please be aware of other consumers and ensure coordination.

@ajeddeloh
Copy link
Contributor Author

@nullr0ute this is just for COSA, which is only used for building FCOS/RHCOS. Anaconda support will remain in rpm-ostree.

@cgwalters
Copy link
Member

@nullr0ute this is just for COSA, which is only used for building FCOS/RHCOS.

Right, though personally I'd like to at least have COSA used to build Silverblue and other things.

Anaconda support will remain in rpm-ostree.

Technically it's the inverse, Anaconda supports rpm-ostree via rpmostreepayload.py; I don't personally see us adding many new features but I will certainly personally help maintain the code and fix bugs if any important ones come up.

@ajeddeloh
Copy link
Contributor Author

Closing in favor of a much less stale #556

@ajeddeloh ajeddeloh closed this Jun 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cgwalters cgwalters cgwalters left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@ajeddeloh @dustymabe @rfairley @cgwalters @nhorman @nullr0ute