After writing the disk.raw file to a local SSD and trying to boot on my lower tier test machine (ASUS E410M); it has the same blank screen upon selecting the boot option.
Out of curiousity, I tried to boot the disk.raw image in a VM and it boots just fine.
Currently unsure whether the issue is stemming from one of the following
efibootmgr-18-4.eln131.x86_64
dosfstools-4.2-8.eln131.x86_64
Creating group 'systemd-coredump' with GID 998.
Creating user 'systemd-coredump' (systemd Core Dumper) with UID 998 and GID 998.
Creating group 'systemd-timesync' with GID 997.
Creating user 'systemd-timesync' (systemd Time Synchronization) with UID 997 and GID 997.
deleting the fake machine id
⏱ Duration: 22s
org.osbuild.selinux: 008587f22809ff3de17cdffe7cf859e54bcb6f539efef3dc87d5611b8d9c6800 {
"file_contexts": "etc/selinux/targeted/contexts/files/file_contexts",
"labels": {
"/usr/bin/cp": "system_u:object_r:install_exec_t:s0"
}
}
/usr/lib/tmpfiles.d/journal-nocow.conf:26: Failed to resolve specifier: uninitialized /etc/ detected, skipping.
All rules containing unresolvable specifiers will be skipped.
setfiles: Could not set context for /run/osbuild/tree/usr/lib/systemd/system-generators/systemd-fstab-generator: Invalid argument
setfiles: Could not set context for /run/osbuild/tree/usr/lib/systemd/system-generators/systemd-rc-local-generator: Invalid argument
setfiles: Could not set context for /run/osbuild/tree/usr/lib/systemd/system-generators/systemd-sysv-generator: Invalid argument
Traceback (most recent call last):
File "/run/osbuild/bin/org.osbuild.selinux", line 75, in <module>
r = main(args["tree"], args["options"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/run/osbuild/bin/org.osbuild.selinux", line 62, in main
subprocess.run(["setfiles", "-F", "-r", f"{tree}", f"{file_contexts}", f"{tree}"], check=True)
File "/usr/lib64/python3.12/subprocess.py", line 571, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['setfiles', '-F', '-r', '/run/osbuild/tree', '/run/osbuild/tree/etc/selinux/targeted/contexts/files/file_contexts', '/run/osbuild/tree']' returned non-zero exit status 255.
⏱ Duration: 4s
Failed
running osbuild failed: exit status 1
I’m noticing different behaviours on different machines, even though it’s in a container.
I’m using machine on Equinix Metal, a RHEL8 one and an Ubuntu one; both with Podman.
The build works when running on the RHEL8 machine but not the Ubuntu one.
The Ubuntu machine gets stuck on
org.osbuild.copy: 9be0f0970bcb5f7007290af06ab0f981d6c8aa86a0ba0c786b7e89b442dd3bcd {
"paths": [
{
"from": "input://root-tree/",
"to": "mount://-/"
}
]
}
device/- (org.osbuild.loopback): loop6 acquired (locked: False)
device/boot (org.osbuild.loopback): loop7 acquired (locked: False)
device/boot-efi (org.osbuild.loopback): Exception ignored in: <function Loop.__del__ at 0x7fd85156a3e0>
device/boot-efi (org.osbuild.loopback): Traceback (most recent call last):
device/boot-efi (org.osbuild.loopback): File "/usr/lib/python3.12/site-packages/osbuild/loop.py", line 137, in __del__
device/boot-efi (org.osbuild.loopback): self.close()
device/boot-efi (org.osbuild.loopback): File "/usr/lib/python3.12/site-packages/osbuild/loop.py", line 144, in close
device/boot-efi (org.osbuild.loopback): fd, self.fd = self.fd, -1
device/boot-efi (org.osbuild.loopback): ^^^^^^^
device/boot-efi (org.osbuild.loopback): AttributeError: 'Loop' object has no attribute 'fd'
Traceback (most recent call last):
File "/usr/bin/osbuild", line 33, in <module>
sys.exit(load_entry_point('osbuild==98', 'console_scripts', 'osbuild')())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/osbuild/main_cli.py", line 169, in osbuild_cli
r = manifest.build(
^^^^^^^^^^^^^^^
...
Potentially a host kernel limitation with one OS having SELinux and one not?
Heya! I’m one of the maintainers of osbuild-deploy-container. This project is very young and was basically hacked up in a day by me and Achilleas in a day, so there are indeed some rough edges. However, I’ve spent the last 2 weeks figuring out the overall vision, and I hope that we will be able to ramp up the developer effort on this tool next week.
Some highlights:
The latest version works on SELinux-enforcing systems. Sorry about that, that was an oversight!
The loop issue is fixed in osbuild upstream, we’re working on getting the fix into osbuild-deploy-container asap. Fun fact: If you run the build enough times, it will succeed at some point.
I want to rework the CLI soon-ish. I apologize for any breakages in the near future. I hope we can stabilize it asap.
One item high on our roadmap is support for creating offline ISOs. This is our preferred way to install bare-metal machines.
About supporting raw - I’m not really sure, I would much rather have people using a headless installer instead, because it’s able to cover some corner-cases that raw cannot. However, you can always use qemu-img to convert qcow2 to raw outside the container (or just abuse the fact that the container has qemu-img inside): qemu-img convert -O raw your.qcow2 your.raw
If you have any suggestions/feedback, I’m all ears!
Hey @ondrejbudai!
Thank you kindly for your message!
It’s a nice implementation of osbuild. Thank you for your work and continued maintenance.
Offline ISOs sound like a helpful idea too!
The needs for the project I’m working on is that the OS is a preinstalled desktop, with a user account and ideally Flatpaks too without the need for a firstboot installer; all on a bootable USB device.
I had trouble with booting the raw image produced in my fork on my hardware, I’ll try the qemu-img convert command.
The qemu images, with my wrangling, didn’t work booting in anything not in a VM either; this might make sense though.
I was also wondering, what dependency does osbuild-deploy-container have on the host system?
I was also wondering, what dependency does osbuild-deploy-container have on the host system?
You need to be able to run podman rootful (should work with docker but I’ve never tested). Otherwise, everything is in the container, so the only dependency should be the kernel. There are certainly many corner-cases here. For example, imagine that you want to build your image with btrfs (not supported yet), but the host kernel doesn’t support btrfs (all RHEL distributions and friends). The build will fail, because the tool cannot mount the newly created partition.
However, I strongly believe that these corner-cases will be quite rare. Also, you can “always” run the container in a VM (we might provide some integration for this future, we know there’s interest, but no promises).
When trying to boot from a disk with the raw converted version from the qcow2 image, there’s just a blank screen and it doesn’t yet go to grub.
Which container image are you converting? Which tool are you using? Does the target machine support BIOS/UEFI/both?
In the process of figuring out the practical differences between the product of osbuild-deploy-container and bootc, beginning with bootc, I ran bootc wrapped with strace and found all syscalls+execs+opens then discovered a few commands it calls and files it writes to.
The command I used is
I managed to get a disk to boot which has been flashed with a qcow2 image built by osbuild-deploy-container converted to raw, with steps 11-21 in the above comment run against it, effectively re-installing the bootloader.
and am trying to build bootable USB drives for things like education for classes and shared team development environments.
was SELinux, setting to Permissive has gotten me past that error 
Also, you can “always” run the container in a VM (we might provide some integration for this future, we know there’s interest, but no promises).