Open puccaso opened 2 years ago
i worked out that the resin-init-service error has something to do with resin-init-board not completing successfully
lsblk: /dev/sda3[/var/lib/docker/volumes/balenaos-in-container_boot/_data]: not a block device
when i goto the volume dir in var/lib, i can see the config.json in the boots _data dir i know thats working.
i've tried configs for both generic x86 and intel nuc. i can't seem to progress beyond this point.
This is the snippet of code that is failing:
# make sure the bootstrap code (boot.img) is removed in case we are using EFI boot
if [ -d /sys/firmware/efi ] ; then
device="/dev/"$(findmnt --noheadings --canonicalize --output SOURCE /mnt/boot/ | xargs lsblk -no pkname)
dd if=/dev/zero of=$device bs=446 count=1
fi
Still investigating the proper workaround for running in a container.
[klutchell] This issue has attached support thread https://jel.ly.fish/5c6f6bf4-0bc4-4f2f-b97e-eb66ee51573e
@puccaso Hi. Did you manage to run balenaos-in-container on Linux server with docker somehow?
I'm struggling with these errors still. Perhaps this has something to do with the way aufs or overlay is configured on Host server, or the cgroups configuration
balenaos-in-container-os-1 | Failed to attach 21 to compat systemd cgroup /docker/74a6d832a885e725ac07fdda777a5eac78e6da246d501ed50225503acd3b6a24/system.slice/dev-hugepages.mount: No such file or directory
balenaos-in-container-os-1 | Mounting Huge Pages File System...
balenaos-in-container-os-1 | Failed to attach 21 to compat systemd cgroup /docker/74a6d832a885e725ac07fdda777a5eac78e6da246d501ed50225503acd3b6a24/system.slice/dev-hugepages.mount: No such file or directory
balenaos-in-container-os-1 | Failed to attach 22 to compat systemd cgroup /docker/74a6d832a885e725ac07fdda777a5eac78e6da246d501ed50225503acd3b6a24/system.slice/sys-kernel-debug.mount: No such file or directory
balenaos-in-container-os-1 | Mounting Kernel Debug File System...
balenaos-in-container-os-1 | Failed to attach 22 to compat systemd cgroup /docker/74a6d832a885e725ac07fdda777a5eac78e6da246d501ed50225503acd3b6a24/system.slice/sys-kernel-debug.mount: No such file or directory
balenaos-in-container-os-1 | Failed to attach 23 to compat systemd cgroup /docker/74a6d832a885e725ac07fdda777a5eac78e6da246d501ed50225503acd3b6a24/system.slice/kmod-static-nodes.service: No such file or directory
balenaos-in-container-os-1 | Starting Resin NTP server configure service...
balenaos-in-container-os-1 | Starting DNS forwarder and DHCP server...
balenaos-in-container-os-1 | [ OK ] Started DNS forwarder and DHCP server.
balenaos-in-container-os-1 | [ OK ] Started Resin NTP server configure service.
[ TIME ] Timed out waiting for device /dev/zram0.
balenaos-in-container-os-1 | [DEPEND] Dependency failed for Enab…sed swap in memory using zram.
@klutchell maybe you have some advice
@zumby have you checked to make sure you are using cgroups v1 and not v2 as per the readme? https://unix.stackexchange.com/questions/619681/how-can-i-find-out-what-version-of-cgroups-i-have
Does the behaviour change if you use a different OS release? https://github.com/balena-os/balenaos-in-container/blob/master/docker-compose.yml#L9
@klutchell thanks for response
FYI - this is a simple EC2 on AWS with Amazon Linux on board (x86_64)
cgroups seems to be fine, but im not that expert:
As for the images, i've tried the default (from docker-compose.yml) which is 2.95.12_rev1-genericx86-64-ext Also tried these:
And today I've tried the very fresh one 2.99.27_rev2-genericx86-64-ext and 2.99.27_rev2-intel-nuc
FYI I've built them like that:
docker-compose build --build-arg OS_VERSION=2.99.27_rev2
The result for all of them is the same: WARNINGS + ERROR + STUCK in the end.
In the BalenaCloud, it does add the device but it always has check_localdisk issues:
Generally, I want to achieve a device "simulation" or a "virtual" device that I can add to Balena. So the plan was to start this on EC2 in AWS and once it's in Balena - do other stuff with it, like deploy actual app. There is a slight chance it has something to do with the virtualisation at AWS EC2.
@zumby it looks to me like your device is booted, and you can ignore those warnings. They are expected when running balenaos-in-container due to the way systemd handles pids.
I would not expect your root partition to fully expand since it's a virtual docker volume, so our partition utilities cannot determine the maximum partition size. This is also expected.
Is there anything blocking you from using this device as a simulation? You could also flash the genericx86-64-ext image directly to an AWS instance if you want to skip the extra layer of virtualization. Maybe this forum post can help get you started: https://forums.balena.io/t/host-balena-os-on-aws-as-a-virtual-device/304444
@klutchell interesting. i actually never moved forward yet (hehe) - but i will surely try to do other things and see if it blocks me. As for putting image directly into AWS - that seems harder to me and yet not too clear. But we'll see.
Thanks for the help and i'll comment more if i notice some troubles
Hello.
I am running the container inside ubuntu, and the image although the image seems up, the system gets stuck at a loop between the supervisor starting up and starting libcontainer.
then I get other errors before the process seems to complete.
I can get to the console of the container, but i cant seem to see the system on the cloud dashboard.
any ideas?
puc