starred/pikvm-pikvm
1
0
Fork 0
mirror of https://github.com/pikvm/pikvm.git synced 2026-03-02 18:16:56 -05:00
Code Issues 133 Projects Packages Wiki Activity

Building a PiZeroW image with make os gets stuck at 16/16 step. #84

New issue
Closed
opened 2026-02-20 13:19:55 -05:00 by deekerman · 8 comments
deekerman commented 2026-02-20 13:19:55 -05:00
Owner
Copy link

Originally created by @hradec on GitHub (Oct 16, 2020).

Originally assigned to: @mdevaev on GitHub.

Describe the bug
I'm using this config.mk file:

# rpi3 for Raspberry Pi 3; rpi2 for the version 2, zerow for ZeroW
BOARD = zerow

# Hardware configuration
PLATFORM = v2-hdmi

# Target hostname
HOSTNAME = pikvm

# ru_RU, etc. UTF-8 only
LOCALE = en_US

# See /usr/share/zoneinfo
TIMEZONE = Vancouver/Canada

# For SSH root user
ROOT_PASSWD = root

# Web UI credentials: user=admin, password=<this>
WEBUI_ADMIN_PASSWD = admin

# IPMI credentials: user=admin, password=<this>
IPMI_ADMIN_PASSWD = admin

# SD card device
CARD = /dev/mmcblk0

WIFI_ESSID = "<my wifi name without spaces>"
WIFI_PASSWD = "<my wifi password without spaces>"

and when I run make os, it always stops at:

==> Building image from preset: /etc/mkinitcpio.d/linux-raspberrypi.preset: 'default'
  -> -k 5.4.70-1-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.4.70-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
(14/16) Reloading system bus configuration...
  Skipped: Current root is not booted.
(15/16) Warn about old perl modules
(16/16) Updating the info directory file...

When I say stops, I mean just staying there, doing nothing! I left it there for more than 24 hours, and it will stay stuck there... no error messages, nothing!

To Reproduce
Steps to reproduce the behavior, like:

  1. maybe try to use my config.mk and run make os? I'm not sure...

Expected behavior
I would expect it to finish without errors, since the source code is vanilla from the github depot, with the only change being the config.mk file.

Desktop (please complete the following information):

  • OS: Arch Linux

Pi-KVM info:

  • Raspberry Pi Zero W board
  • v2-hdmi
  • CSI bridge
  • KVMD version: not applicable, since I'm having trouble to build the image which uses docker, not actually running it!
  • uStreamer version: not applicable, since I'm having trouble to build the image which uses docker, not actually running it!
  • Linux kernel: Linux version 5.4.2-zen1-1-zen (linux-zen@archlinux) (gcc version 9.2.0 (GCC)) #1 ZEN SMP PREEMPT Thu, 05 Dec 2019 12:30:04 +0000

Additional context
I'm building the image in a AMD FX8100 PC running Arch Linux, not in a Raspbery Pi.
I went into the docker container using docker exec to see what was running in it, and it seemed to be stuck on a pacman command. Maybe Pacman is asking something and it's waiting for input?
Is there a way to run the make os showing everything so I can check if that's the problem? I tried running make os VERBOSE=1, no luck... I also tried running docker logs for the container make os spawns, but I got this message: Error response from daemon: configured logging driver does not support reading

btw, I use docker log with other containers without problem. It's not a config problem of my docker.

Originally created by @hradec on GitHub (Oct 16, 2020). Originally assigned to: @mdevaev on GitHub. **Describe the bug** I'm using this config.mk file: ``` # rpi3 for Raspberry Pi 3; rpi2 for the version 2, zerow for ZeroW BOARD = zerow # Hardware configuration PLATFORM = v2-hdmi # Target hostname HOSTNAME = pikvm # ru_RU, etc. UTF-8 only LOCALE = en_US # See /usr/share/zoneinfo TIMEZONE = Vancouver/Canada # For SSH root user ROOT_PASSWD = root # Web UI credentials: user=admin, password=<this> WEBUI_ADMIN_PASSWD = admin # IPMI credentials: user=admin, password=<this> IPMI_ADMIN_PASSWD = admin # SD card device CARD = /dev/mmcblk0 WIFI_ESSID = "<my wifi name without spaces>" WIFI_PASSWD = "<my wifi password without spaces>" ``` and when I run `make os`, it always stops at: ``` ==> Building image from preset: /etc/mkinitcpio.d/linux-raspberrypi.preset: 'default' -> -k 5.4.70-1-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> Starting build: 5.4.70-1-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [block] -> Running build hook: [filesystems] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img ==> Image generation successful (14/16) Reloading system bus configuration... Skipped: Current root is not booted. (15/16) Warn about old perl modules (16/16) Updating the info directory file... ``` When I say stops, I mean just staying there, doing nothing! I left it there for more than 24 hours, and it will stay stuck there... no error messages, nothing! **To Reproduce** Steps to reproduce the behavior, like: 1. maybe try to use my config.mk and run `make os`? I'm not sure... **Expected behavior** I would expect it to finish without errors, since the source code is vanilla from the github depot, with the only change being the config.mk file. **Desktop (please complete the following information):** - OS: Arch Linux **Pi-KVM info:** - Raspberry Pi Zero W board - v2-hdmi - CSI bridge - KVMD version: not applicable, since I'm having trouble to build the image which uses docker, not actually running it! - uStreamer version: not applicable, since I'm having trouble to build the image which uses docker, not actually running it! - Linux kernel: Linux version 5.4.2-zen1-1-zen (linux-zen@archlinux) (gcc version 9.2.0 (GCC)) #1 ZEN SMP PREEMPT Thu, 05 Dec 2019 12:30:04 +0000 **Additional context** I'm building the image in a AMD FX8100 PC running Arch Linux, not in a Raspbery Pi. I went into the docker container using `docker exec` to see what was running in it, and it seemed to be stuck on a pacman command. Maybe Pacman is asking something and it's waiting for input? Is there a way to run the `make os` showing everything so I can check if that's the problem? I tried running `make os VERBOSE=1`, no luck... I also tried running `docker logs` for the container `make os` spawns, but I got this message: `Error response from daemon: configured logging driver does not support reading` btw, I use `docker log` with other containers without problem. It's not a config problem of my docker.
deekerman commented 2026-02-20 13:19:56 -05:00
Author
Owner
Copy link

@mdevaev commented on GitHub (Oct 16, 2020):

Hi. I'll try to reproduce it, but it's night now, so it won't be until tomorrow. So far, I have a couple of ideas. Try to install a regular Arch kernel on your machine, I have 5.8.14. And have you tried retrying it? Does it get stuck every time?

@mdevaev commented on GitHub (Oct 16, 2020): Hi. I'll try to reproduce it, but it's night now, so it won't be until tomorrow. So far, I have a couple of ideas. Try to install a regular Arch kernel on your machine, I have 5.8.14. And have you tried retrying it? Does it get stuck every time?
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@mdevaev commented on GitHub (Oct 16, 2020):

Okay, I tried it before I went to bed. I have not reproduced this problem. Moreover, a system update has been released in the last few hours. Something may have been fixed.

Try building without a cache: make os NC=1. But before that, please try just repeating make os and using a different kernel. The fact is that the build works via QEMU and this may be an emulation problem.

@mdevaev commented on GitHub (Oct 16, 2020): Okay, I tried it before I went to bed. I have not reproduced this problem. Moreover, a system update has been released in the last few hours. Something may have been fixed. Try building without a cache: `make os NC=1`. But before that, please try just repeating `make os` and using a different kernel. The fact is that the build works via QEMU and this may be an emulation problem.
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@hradec commented on GitHub (Oct 17, 2020):

Hi. I'll try to reproduce it, but it's night now, so it won't be until tomorrow. So far, I have a couple of ideas. Try to install a regular Arch kernel on your machine, I have 5.8.14. And have you tried retrying it? Does it get stuck every time?

Yes... it gets stuck every time!!

Try building without a cache: make os NC=1. But before that, please try just repeating make os and using a different kernel. The fact is that the build works via QEMU and this may be an emulation problem.

repeating make os does the same... stuck! Running make os NC=1 also does the same.

I tried now running in another machine (Xeon E5645 now), which runs Proxmox 6.2, based on Debian 9. Kernel Linux version 5.4.55-1-pve (root@nora) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.55-1 (Mon, 10 Aug 2020 10:26:27 +0200), which is the default kernel for this version of Proxmox (Proxmox is a hypervisor for KVM and Containers)

I get the same result, but actually much earlier than on my arch linux machine, on step 16/78 it just stops!

DeepinScreenshot_select-area_20201016225412

16/78 is actually during the build of the docker image, so no qemu involved in this stage... I tried running it on a hard drive and also on a nvme drive, same result.

What linux distro are you using? I'll try to run a VM on proxmox with the same distro/kernel as you, and see if I can get it to build!

For now, I'll install the latest Manjaro available, so I can get a recent kernel... I'll let you known how it goes!

@hradec commented on GitHub (Oct 17, 2020): > Hi. I'll try to reproduce it, but it's night now, so it won't be until tomorrow. So far, I have a couple of ideas. Try to install a regular Arch kernel on your machine, I have 5.8.14. And have you tried retrying it? Does it get stuck every time? Yes... it gets stuck every time!! > Try building without a cache: `make os NC=1`. But before that, please try just repeating `make os` and using a different kernel. The fact is that the build works via QEMU and this may be an emulation problem. repeating `make os` does the same... stuck! Running `make os NC=1` also does the same. I tried now running in another machine (Xeon E5645 now), which runs Proxmox 6.2, based on Debian 9. Kernel `Linux version 5.4.55-1-pve (root@nora) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.55-1 (Mon, 10 Aug 2020 10:26:27 +0200)`, which is the default kernel for this version of Proxmox (Proxmox is a hypervisor for KVM and Containers) I get the same result, but actually much earlier than on my arch linux machine, on step 16/78 it just stops! ![DeepinScreenshot_select-area_20201016225412](https://user-images.githubusercontent.com/806743/96329916-26b24e80-1006-11eb-91ce-13d4fa91ddb0.png) 16/78 is actually during the build of the docker image, so no qemu involved in this stage... I tried running it on a hard drive and also on a nvme drive, same result. What linux distro are you using? I'll try to run a VM on proxmox with the same distro/kernel as you, and see if I can get it to build! For now, I'll install the latest Manjaro available, so I can get a recent kernel... I'll let you known how it goes!
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@mdevaev commented on GitHub (Oct 17, 2020):

no qemu involved in this stage..

QEMU is used at all stages of the build, including here. Docker images have an ARM architecture.

What linux distro are you using?

Arch

I'll let you known how it goes!

I'll wait. If the problem persists, please contact me via discord (link in README). I would like to debug the problem remotely on your machine via tmate. Because right now I don't understand what's going on, and it doesn't reproduce locally.

@mdevaev commented on GitHub (Oct 17, 2020): > no qemu involved in this stage.. QEMU is used at [all stages of the build](https://github.com/pikvm/pi-builder), including here. Docker images have an ARM architecture. > What linux distro are you using? Arch > I'll let you known how it goes! I'll wait. If the problem persists, please contact me via discord (link in README). I would like to debug the problem remotely on your machine via [tmate](https://tmate.io/). Because right now I don't understand what's going on, and it doesn't reproduce locally.
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@hradec commented on GitHub (Oct 17, 2020):

QEMU is used at all stages of the build, including here. Docker images have an ARM architecture.

Hoooo... I didn't realized pi-builder was a different project!! And examining the initial dockerfile, I see it imports the arm rootfs and qemu-arm... gotcha!

I'm installing docker on the manjaro distro I just installed in a Proxmox VM, and I'll let you known.

Majaro is up2date, and the default kernel is 5.8.11-1. It doesn't have the 5.8.14 in the list to be installed, but it does have a experimental 5.9:
DeepinScreenshot_select-area_20201017132259

I'll give it a try with 5.8.11-1 and see how it goes...

@hradec commented on GitHub (Oct 17, 2020): > > QEMU is used at [all stages of the build](https://github.com/pikvm/pi-builder), including here. Docker images have an ARM architecture. > Hoooo... I didn't realized pi-builder was a different project!! And examining the initial dockerfile, I see it imports the arm rootfs and qemu-arm... gotcha! I'm installing docker on the manjaro distro I just installed in a Proxmox VM, and I'll let you known. Majaro is up2date, and the default kernel is 5.8.11-1. It doesn't have the 5.8.14 in the list to be installed, but it does have a experimental 5.9: ![DeepinScreenshot_select-area_20201017132259](https://user-images.githubusercontent.com/806743/96352885-e55c8600-107b-11eb-8456-de2fd9dfae00.png) I'll give it a try with 5.8.11-1 and see how it goes...
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@mdevaev commented on GitHub (Oct 25, 2020):

How it is?

@mdevaev commented on GitHub (Oct 25, 2020): How it is?
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@mdevaev commented on GitHub (Nov 12, 2020):

I close it because there is no response. I'll reopen it if you want to, I'll be happy to continue debugging and rediscover it if the problem still exists.

@mdevaev commented on GitHub (Nov 12, 2020): I close it because there is no response. I'll reopen it if you want to, I'll be happy to continue debugging and rediscover it if the problem still exists.
deekerman commented 2026-02-20 13:19:57 -05:00
Author
Owner
Copy link

@hradec commented on GitHub (Nov 24, 2020):

sorry the long delay...
I tried running a debian VM on proxmox, but the kernel was less than 5.8.14.
So, I decided to find a moment to update my main arch linux distro to the latest available kernel, but finding that moment took me a while.

But I got there... now I'm running 5.9.9-zen kernel, and I was able to run make os successfully from beginning to end, without cache!

So you're right, it was the kernel version indeed! I think it's a good idea to put a warning in the Readme so people known to use a later than 5.8.14 kernel!

I'm now having a different issue, where pikvm can't find my HDMI-CSI board... but I'll create a new issue for that!

thanks for the help!

@hradec commented on GitHub (Nov 24, 2020): sorry the long delay... I tried running a debian VM on proxmox, but the kernel was less than 5.8.14. So, I decided to find a moment to update my main arch linux distro to the latest available kernel, but finding that moment took me a while. But I got there... now I'm running 5.9.9-zen kernel, and I was able to run `make os` successfully from beginning to end, without cache! So you're right, it was the kernel version indeed! I think it's a good idea to put a warning in the `Readme` so people known to use a later than 5.8.14 kernel! I'm now having a different issue, where pikvm can't find my HDMI-CSI board... but I'll create a new issue for that! thanks for the help!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
gh-pages
No results found.
Labels
Clear labels   
component:documentation

   
help wanted

   
resolution:delayed

   
resolution:duplicate

   
resolution:fixed

   
resolution:invalid

   
resolution:rejected

   
resolution:wontfix

   
success story

   
type:bug

   
type:bug

   
type:feature

   
type:question

   
type:question
No labels
component:documentation
help wanted
resolution:delayed
resolution:duplicate
resolution:fixed
resolution:invalid
resolution:rejected
resolution:wontfix
success story
type:bug
type:bug
type:feature
type:question
type:question
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/pikvm-pikvm#84
No description provided.