Trying to build RPI3-Nexmon and the build fails in trying to access raspberrypi-kernel

[open-analysis]

I’ve been trying build a rpi3-nexmon script to build, but it fails in the third_stage. The error is: “dpkg: error: can not access archive ‘root/raspberrypi-kernel_20181124-191322_armhf.deb’ : No such file or directory” However, the problem is that the file does exist but it can’t seeem to do anything. What needs to be done fix this and finishing building the dependency?

[steev]

That seems odd, the script downloads that file and puts it where it needs to be - are you maybe running out of space on the drive your running the script from? That’s the only thing I could think may be doing it.

[open-analysis]

That seems odd, the script downloads that file and puts it where it needs to be - are you maybe running out of space on the drive your running the script from? That’s the only thing I could think may be doing it.

The computer this script is running on has a 10GB of unused disk space so there should be plenty of room spare. Is there anything else that might be interfering the script completing?

[steev]

Perhaps a flakey internet connection?

If you could run the build again, and redirect the output to a file and paste it, I could see - I cannot reproduce the issue at all here, either running it manually nor through my automated builds (in fact, the automated build just completed a run 1 minute ago.)

Simply doing something like ./rpi3-nexmon.sh test 2>&1 | tee failing-build.log and then paste the outputs into a comment here so I can see what your system is doing? If you've modified the file at all, it would be nice to see the changes as well.

[open-analysis]

The changes I made are from the Kali official walk-through: https://kali.training/topic/exercise-4-4-custom-kali-linux-arm-install/ The changes I made are: `#desktop="fonts-croscore fonts-crosextra-caladea fonts-crosextra-carlito gnome-theme-kali gtk3-engines-xfce kali-desktop-xfce kali-root-login lightdm network-manager network-manager-gnome xfce4 xserver-xorg-video-fbdev xserver-xorg-input-evdev xserver-xorg-input-synaptics"

tools="aircrack-ng ethtool hydra john libnfc-bin mfoc nmap passing-the-hash sqlmap usbutils winexe wireshark net-tools"

tools="aircrack-ng nmap hostapd"

services="apache2 openssh-server"

services="openssh-server"

extras="iceweasel xfce4-terminal wpasupplicant python-smbus i2c-tools python-requests python-configobj python-pip"

packages="${arm} ${base} ${desktop} ${tools} ${services} ${extras}"

packages="${arm} ${base} ${tools} ${services}"`

Then under the WiFi section: auto eth0 iface eth0 inet static address 192.168.1.12 netmask 255.255.255.0 gateway 192.168.1.1 EOF

The Log: failing-build.log

[threeway]

Based on that log file, there was an isssue downloading nmap, not the kernel, or anything kernel related.

Either the mirror was in the middle of updating, or the mirror you got has a few out of date files - can you try hardcoding a different mirror? The “mirror=http.kali.org” line is the one to change.

Also please be sure you didn’t accidentally remove the beginning slash for the dpkg line for the kernel - you can quickly see your changes by doing “git diff” in the kali-arm-build-scripts checkout

[open-analysis]

I switched the mirror and it still wasn't working, so I decided to remove nmap from the installation. Also the dpkg line wasn't changed since I didn't see anything related to a line like that when I typed "git diff".

The newer installation without nmap seemed to work better, however still ran into a problem with inability to access a file. Will update further on Monday. Thank you all for the help thus far.

[open-analysis]

failing-build.log I've changed the mirror and removed the installation of tools just in case. Now however, it cannot find the firmware folder to get the stats off of. I've scanned through the rest of the log file and there weren't any other errors as far as I could see.

[threeway]

Can you try the mirror “kali.mirror.globo.tech” ? I just checked and that’s the mirror that the build system gets as the round robin from http.kali.org

As to the second failed build - that’s because you disabled it installing raspi3-firmware - that package installs the rpi3 firmware and puts it in /boot/firmware and since we use a different layout (we have the first partition as /boot to mirror raspbian to be closer to what their scripts and all the instructions out there use) it’s failing to copy them.

Interestingly enough, your failure of nmap, is a 403 forbidden, not a 404 not found.

I should move the raspi3-firmware to a different line to be sure it’s installed since it is important and required, without it, an image won’t boot unless someone modified the script to clone the upstream firmware repo and move the files into /boot.

[threeway]

Also to address the mention of sshd_config in your previous comment - because there’s an issue installing nmap, the packages fail to install and because openssh-server didn’t install (due to the nmap package failing), the /etc/ssh/sshd_config file doesn’t exist.

I have the script failing due to that because previously, I didn’t have it fail, and since the packages aren’t installed, the build was succeeding but (obviously) not working properly

[open-analysis]

failing-build.log I tried the mirror that you mentioned and was able to install nmap with it, and I made sure the rpi3 firmware was installed as well this time. I believe that the script ran properly this time as I ended up with an .img file, however, based on the Kali Revealed, there should be a zipped .img file. Which is correct? The .img.xz or just a plain .img, or is something else up?

[steev]

It’s img.xz - the image (img file) is compressed with xz because it compresses a bit better than a zip, but it doesn’t roll off the tongue as well as “zipped” which is often used synonymously as a compressed file. Although I don’t see anything on the page about a zipped file.

The only time you won’t have an img.xz file, is if you do it on 32bit, as 32bit will run out of memory compressing. The big change from when that was written until now is that it writes the image into the directory you run the script from so you don’t have to look in the folder to see it.

[open-analysis]

(^ the output of the script, clicking it will turn it right side up) My apologies, to clarify: After the script stopped running, the files that were in the rpi3-nexmon-1.0 folder were the file system (kali-armhf), the image, nexmon folder, and the root folder. Nothing in the log file jumped out at me as saying something went wrong for it to just stop before compressing the image.

Edit: My OS is 64 bit.

[digitallyelite]

i'm not sure what would cause that, aside from it not fully running correctly - do you have the output of the build? I run automated builds of all the rpi scripts and get a notification if something fails pretty quick, so the only thing i can think is another issue with downloading somewhere. You can run the script with something like ./rpi3-nexmon.sh 1.0 2>&1| tee rpibuild.log and it would produce a file with the output that I could look through.

[open-analysis]

build.log Here's the output from the build. I've only changed the mirror to what was suggested above and removed the desktop in the included packages and changed how the network interface will be setup, which I wouldn't think would change anything.

[steev]

Can you try to add a sleep 10 after the sync and before the umount -l ${bootp} (line 459). I wonder if your cache isn't actually finished writing - it's not unmounting the boot partition yet even though it's unmounting the second partition.

[open-analysis]

build.log Adding sleep 10 did slightly change the end result, it changed which loop was still running and wouldn't unmount. I increased the sleep time by 10 but it had the same result.

[steev]

Okay, I'm not entirely certain but this may be my fault in not noticing that the size of the install was increasing - Can you set the size (line 21) to 5000 instead of 4500 and see if that works? I started running into a similar issue last night/today with the automated builds but it was throwing an error that it was running out of space not that it couldn't unmount.

I need to go through that walkthrough and see about getting modifications in to match the latest scripts, it's possible that we're still installing things even though you're not adding them (due to dependencies).

[steev]

No, I'm wrong - your build script log output even shows you're only using 1.6GB of space.

What kind of hardware is being used here? The script should be lazily unmounting, so the loop device shouldn't be in use still.

[open-analysis]

I'm using a virtual machine that's running Kali which I made sure to give more than enough RAM and hard drive space. Otherwise, I have a i5 processor and 6GB of RAM.

[steev]

What type of hard drive? It seems like somehow its slow? I'll admit, I haven't tested the scripts extensively in a VM, but they ran successfully last time I did them. Is it virtualbox or vmware?

[open-analysis]

I'm using virtualbox and my hard drive has 7,000 RPM and 6Gb/s.

[steev]

I can't seem to replicate this here, are you still having issues with it?

[open-analysis]

Yes I am unfortunately. I've tried increasing the sleep time to no avail and trying to run the scrip on another Linux machine I had lying around but that died part way through, so I've been out of luck.