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

fedora 33 upgrade to build from fedora 33 #81

Open
ad-m opened this issue Jul 21, 2021 · 0 comments
Open

fedora 33 upgrade to build from fedora 33 #81

ad-m opened this issue Jul 21, 2021 · 0 comments

Comments

@ad-m
Copy link
Collaborator

ad-m commented Jul 21, 2021

When building Linux image we create virtual machine with two disk. One disk contains data from the currently published image on the platform. On the second drive, the operating system is installed in a chroot-like environment. The second disk is then used to create a new image on the platform.

When building Linux images with SELinux, we should use an earlier build of the same distribution version to build the image for disk one) Thanks to this we have SELinux attributes will be properly set and will be minimized risk of boot failure due SELinux attributes mismatch.

Currently Fedora 33 uses Fedora 32 for build, which could cause problems with SELinux in the future (currently SELinux labels are sufficiently compatible and are reset correctly for end user on boot).

At the same time, Fedora 32 is EOL. We would like to publish it from Platform. However, this is not possible due to Fedora 33 dependency on it. We have to update source image for Fedora 33 to Fedora 33. However, on a simple change, the build fails (see #64). Changes need to be tracked down & build fixed.

It appears that in image for Fedora 33, the network connection or SSH keys are not properly configured under certain conditions. Both are provided by cloud-init.

In that case, note that the h1 vm serialport log provides some cloud-init logs. Additional cloud-init logs are available after re-mounting the disk to another virtual machine. We have our own cloud-init datasource that is published upstream. However, the entire virtual machine boot process must be tracked and verified.

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

No branches or pull requests

1 participant