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.

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

New test #6

Merged
merged 1 commit into from
Apr 3, 2023
Merged

New test #6

merged 1 commit into from
Apr 3, 2023

Conversation

marta-lewandowska
Copy link
Collaborator

No description provided.

@marta-lewandowska
Copy link
Collaborator Author

test.sh is a naive script that:

  • creates an SB-enabled VM with /boot partition
    • custom SB key already enrolled
    • /etc/pki/pesign db with said key
  • installs fedora38-- change that by editing virt-install command
  • installs packages needed for signing, etc.
  • installs a new kernel according to repo in install_fedora.ks (currently
    Robbie's kernel-6.3.0-0.rc2.89f5349e0673.24.test.fc38)
  • implements naive boot logging scheme with using systemd target
  • signs new kernel and reboots into it
  • get correct config files from etc/ and 99grub2-emu/
  • builds nmbl using dracut command
  • allows user to boot using nmbl

This has been tested on a RHEL hypervisor in beaker (N=1), but could work on
your laptop. The timeout for installation is short, so if something is
failing, increase the sleep time. It does make changes to the host to enable
ssh without strict host checking, and maybe other stuff too. ;)

There is no error checking. Yet.

@hughsie
Copy link
Collaborator

hughsie commented Mar 24, 2023

All this automation is awesome! We were talking today about splitting this into three -- i..e. have three CI "targets" -- one for the super-quick switchroot IoT target, one for the cloud image and one for the "full fat" desktop image. Could that be on your target? I think from a docs point of view, "pick one of three" is better than "choose your own adventure".

@marta-lewandowska
Copy link
Collaborator Author

Ok, this should actually work now...
Added nvram, which I forgot before, fixed a few bad paths.
VM installation it also a bit friendlier and more robust now.

@marta-lewandowska
Copy link
Collaborator Author

All this automation is awesome! We were talking today about splitting this into three -- i..e. have three CI "targets" -- one for the super-quick switchroot IoT target, one for the cloud image and one for the "full fat" desktop image. Could that be on your target? I think from a docs point of view, "pick one of three" is better than "choose your own adventure".

I'm so glad you like it. It is (obviously) just a first go, and I am happy to make any and all changes to make this as useful as possible. Please just give me some more information, and I will incorporate whatever you (all) need.

@marta-lewandowska
Copy link
Collaborator Author

ok, that was the last little thing: permissions on private key changed to 600.
It's best to just copy the whole 01_vm_and_boot_counting directory to some machine (preferably not your own; I recommend a hypervisor in beaker) and then just run test.sh.
I know it's stupid to have a couple of dirs duplicated here from the main dir. I can take them out, but then you will also have to copy etc/ and 99grub-emu/ onto the remote machine as well.

@frozencemetery
Copy link
Member

I know it's stupid to have a couple of dirs duplicated here from the main dir. I can take them out, but then you will also have to copy etc/ and 99grub-emu/ onto the remote machine as well.

Would it be possible to symlink them in the repo so we don't forget to make changes in two places? Or would that break other things?

@marta-lewandowska
Copy link
Collaborator Author

I know it's stupid to have a couple of dirs duplicated here from the main dir. I can take them out, but then you will also have to copy etc/ and 99grub-emu/ onto the remote machine as well.

Would it be possible to symlink them in the repo so we don't forget to make changes in two places? Or would that break other things?

The test just scp's them onto the VM and then rsyncs, the way you have it.
If I knew how people would be using this, it would be easier to answer your question. Sym links are probably fine.

@marta-lewandowska
Copy link
Collaborator Author

Would it be possible to symlink them in the repo so we don't forget to make changes in two places? Or would that break other things?

I put in symlinks, as suggested. scp -r seems to copy everything.
Also, fixed one script, which was stupidly written.

Creates SB VM with nvram, tpm
installs and signs new kernel
creates nmbl entry using dracut

Signed-off-by: Marta Lewandowska <[email protected]>
@marta-lewandowska
Copy link
Collaborator Author

I put in symlinks, as suggested. scp -r seems to copy everything. Also, fixed one script, which was stupidly written.

Alright... scp -r doesn't work in this case, so one needs to tar xhf (h is key here to dump the symlinks as directories in the archive) and then scp the tar file.
Made a few more little changes and tested again. :)
Also updated README

@frozencemetery frozencemetery merged commit e659f51 into rhboot:main Apr 3, 2023
@marta-lewandowska marta-lewandowska deleted the new_test branch April 17, 2023 14:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants