FloatingSunfish

  • Posts

    13
  • Joined

  • Last visited

FloatingSunfish's Achievements

  1. @Werner Indeed, we're also looking at emulating Ubuntu Core on a Raspberry Pi (probably with QEMU as well, unless we find a better Raspberry Pi emulator) due to how difficult it is to find information on this topic. 😅 Many thanks for the info, I'm sure it will be useful! 😉 Cheers!
  2. Hi! We want to emulate because our devices with our development boards are not yet available. It would be very handy if we can get QEMU to run Armbian images while waiting for these devices. However, I will admit that there does not seem to be much information about this topic (old posts like the one linked in the OP no longer seem to work), so I understand if it takes a while to resolve this issue, if it's even resolvable at all.
  3. I'm trying to run any standard Armbian image on QEMU on my Ubuntu machine, and I found this post on this forum. I installed QEMU with: sudo apt-get install -y qemu I downloaded "Armbian_20.08.1_Orangepione_buster_current_5.8.5.img" and copied the following files from the image file with PowerISO to a directory, "/myfolder": 1. boot/vmlinuz-5.8.5-sunxi 2. boot/initrd.img-5.8.5-sunxi 3. boot/dtb-5.8.5-sunxi/sun4i-a10-cubieboard.dtb I then ran QEMU with the below command: qemu-system-arm \ -M cubieboard \ -m 1024 \ -cpu cortex-a8 \ -dtb /myfolder/sun4i-a10-cubieboard.dtb \ -kernel /myfolder/vmlinuz-5.8.5-sunxi \ -initrd /myfolder/initrd.img-5.8.5-sunxi \ -append 'earlyprintk loglevel=8 earlycon=uart8250,mmio32,0x1c28000,115200n8 console=ttyS0 root=/dev/sda1' \ -nographic \ -serial stdio \ -monitor none \ -drive file=/myfolder/Armbian_20.08.1_Orangepione_buster_current_5.8.5.img,format=raw,if=none,id=d1 \ -device ide-hd,drive=d1 \ -nic user,model=allwinner-emac,hostfwd=tcp::50022-:22 However, I am getting the following error: [ 12.122530] Kernel panic - not syncing: Attempted to kill the idle task! [ 13.448529] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Resizing the image does not seem to be required, but I also tried running qemu-img.exe resize -f raw Armbian_20.08.1_Orangepione_buster_current_5.8.5.img 2G and it did not help. I figured I could try using the exact Armbian image that was used in the post linked above, but when I downloaded "Armbian_5.90_Orangepione_Ubuntu_bionic_next_4.19.57.img" from the archives, the "/boot" directory of the .img file was empty. Am I doing something wrong? And is there a place where I can download "/boot" files for "Armbian_5.90_Orangepione_Ubuntu_bionic_next_4.19.57.img?"
  4. UPDATE: It seems that changing `mkdir -m 777 /scripts` to `mkdir -m 777 $SDCARD/scripts` has resolved both issues: 1. `customize-image.sh` is now running as expected. 2. We can now see our custom files inside `/build/userpatches/overlay`. These were "copied" to where we told `customize-image.sh` to place them.
  5. I wouldn't call it "wasting one hour," as not being able to create a directory with `mkdir -m 777 /scripts` feels like a legitimate issue. `/` being the root directory on any Linux system, I can imagine other developers being confused if the above command does not work for them. To be honest, `mkdir -m 777 $SDCARD/scripts` was a blind guess to see if something will work as we did not see it in the official documentation (or if it was, our apologies in advance if we somehow missed it). If prefixing `$SDCARD` to directories is always needed (which it might be, given how Armbian runs on development boards on devices that will most likely use SD cards), then it might need to be added to the documentation if it's not there already. Again, our apologies if we upset you.
  6. UPDATE: We managed to create a new directory by changing `mkdir -m 777 /scripts` to `mkdir -m 777 $SDCARD/scripts`. Although we are not sure if this will work for other developers, at least it resolved the "directories not being created" issue.
  7. Our `customize-image.sh` contains the following custom code for `buster`: buster) # Update Repositories apt-get -y update apt-get -y upgrade apt-get -y dist-upgrade # ------------------------------------------ # Copy our files to the proper directories. # ------------------------------------------ # ---------------- # Logrotate Files # ---------------- cp -TR /tmp/overlay/log-configurations/ /etc/logrotate.d/ # -------- # Scripts # -------- mkdir -m 777 /scripts cp -TR /tmp/overlay/scripts/ /scripts/ # Enable Network-checking. systemctl start systemd-networkd systemctl enable systemd-networkd # Make our scripts executable by services (do for each script file). chmod a+x /scripts/myscript.sh # --------- # Services # --------- cp -TR /tmp/overlay/services/ /etc/systemd/system/ # Give our services the proper permissions. chmod 644 /etc/systemd/system/myservice.service systemctl daemon-reload # Start and run our services on startup (do for each service file). # Note that each line has TWO commands! systemctl start myservice && systemctl enable myservice ;; We're creating a new directory with `mkdir -m 777 /scripts`, but it is not being created. Also, is there any code in the above section that is incorrect or should not be there?
  8. I see, noted. We will check the `output/debug` directory and get back with any weird details we find.
  9. We believe this is what we are already doing. We are including custom files inside `/build/userpatches/overlay`, and we are using `/userpatches/customize-image.sh` to access said custom files from the `/tmp/overlay` directory. We actually have 2 issues: 1. It seems `customize-image.sh` is not being run (we're creating a directory `/mydirectory` and it's not being created after installing the image). 2. Our custom files inside `/build/userpatches/overlay` are not being reflected inside the built Image. We decided to ask the easier question first, which is #2. Going back, is our assumption correct that our custom files should be visible somewhere inside the built Image? Also, are we using `/build/userpatches/overlay` and `/userpatches/customize-image.sh` correctly? We're going by what we understand from the link you provided.
  10. We have added some custom files inside `/build/userpatches/overlay`, which is as follows: /build/userpatches/overlay /log-configurations log-config /scripts myscript.sh /services myservice.service We are building our image with the following command: sudo ./compile.sh CLEAN_LEVEL="" BOARD=zeropi BRANCH=dev RELEASE=buster BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img The build completes successfully, but when we open the Image file in PowerISO, we cannot locate our custom files inside the Image. We have the assumption that custom files should be located somewhere in the built Image. Is this assumption correct? If so, where should we expect to see our custom files?
  11. That's good to hear. Not yet, as the build process reportedly takes a few hours and I don't want to make such costly moves without first knowing as much as I can about them. Do you mean something like this? sudo ./compile.sh CLEAN_LEVEL="debs" Based on what I understand from the docs, the default value of `CLEAN_LEVEL` is "make,debs", and it's the "make" value that triggers kernel rebuilds. Will the above disable kernel rebuilding? Also, can I get some Likes or something to remove this "Validating" status so I can reply to this thread faster? Waiting 24 hours before being able to reply is quite limiting and waiting 7 days for the Validating status to go away feels too long. Lastly, I can't seem to edit my Avatar/Profile Pic. Has it been disabled or something?
  12. I'm trying to create a custom Armbian image based on the User Configurations documentation. I can see that I can install additional packages by editing `userpatches/lib.config` and adding entries to the `PACKAGE_LIST_ADDITIONAL` variable, and I can work with custom files like scripts by placing them inside `userpatches/overlay` and accessing them in `/tmp/overlay` via `customize-image.sh`. My question is, does `customize-image.sh` support the below commands given that it executes in a chroot environment: NOTE: Some commands below require `sudo`, but because we're already in a chroot environment, I assume we can run them without `sudo`. 1. Creating directories inside `/`: mkdir -m 777 /myscripts 2. Copying files from `/tmp/overlay` to other directories: cp -rf /tmp/overlay/myscript.sh /mysrcipts/ 3. Making script files executable by services: chmod a+x /myscripts/samplescript.sh 4. Starting and enabling system services: systemctl start systemd-networkd systemctl enable systemd-networkd 5. Updating repositories: apt-get -y update apt-get -y upgrade apt-get -y dist-upgrade 6. Copying custom service files to `/etc/systemd/system` and giving them proper permissions: cp -rf /tmp/overlay/myservice.service /etc/systemd/system/ chmod 644 /etc/systemd/system/myservice.service 7. Installing and starting custom services: systemctl daemon-reload systemctl start myservice systemctl enable myservice