Partially SOLVED: Installing Kali 2019.2a using NOOBS/PINN

Hi Kali maintainers.

I am the author/maintainer of PINN for the Raspberry PI (a fork of the NOOBS installer developed by the RPF) to easily install various OSes on the Raspberry Pi and allowing multi-OS booting.
I have converted several previous versions of Kali to the NOOBS format and made them available for installation by PINN.

I am currently updating the version of Kali I offer to 2019.2, but I ran into a problem with 2019.2a for the RPI3/4.
It seems not to like being moved to a different partition and assumes it is running on /dev/mmcblk0p1 and /dev/mmcblk0p2. On first installation, it therefore seems to repartiton the SD card, recreating /dev/mmcblk0p2 and wiping out all subsequent partitions.
I read somewhere that on first boot it does a lot of jiggery-pokery to update itself and may require several reboots.
Can someone please point me to the scripts where this is done so I can adapt them?
Since PINN allocates all partitions prior to installing the OS files, any partition resizing scripts are redundant and I will also need to remove any of those.

Thanks,
Procount.

No matter. I partially solved this by discovering and disabling the rpiwiggle.service.

However, on first boot (using a HDMIPI screen) I only got a blank screen. I could ssh into it and it looked like it must have been displaying a console(?) But after a reboot it booted into the desktop login screen. It would be nice if I could avoid the need for this reboot.

The first boot has to do a few things mostly due to an issue with Qemu, glibc and ext4 file systems (the host that builds the image) - these are done in https://gitlab.com/kalilinux/build-s...pi3-64.sh#L114 the smi-hack service - it reinstalls 1-3 packages depending on image on first boot, and takes a bit depending on which rpi is used.

I've never needed it to reboot to get to the desktop locally, so I'm not entirely sure what is happening there. Perhaps the smi-hack service didn't run correctly (can you do another install and test that?)

Sorry I didn't notice this, most posts about ARM happen in the ARM section of the forums.

Hi Steev,

Thanks for the info.
It sounds like you are responding to my reply to my first post, which for I still can't see (maybe I'm still being modererated ;) )
It seems a bit random on the Pi4. I have had it boot straight to the desktop and a couple of times to a blank console screen which booted fine the 2nd time.
I shall keep testing, but now I've deleted rpiwiggle.service, it mostly works. I'll try with a proper HDMI screen and on other RPI models. I had no problem with the rpi2 version.

Quote:

---

Originally Posted by procountsf

Hi Steev,

Thanks for the info.
It sounds like you are responding to my reply to my first post, which for I still can't see (maybe I'm still being modererated ;) )
It seems a bit random on the Pi4. I have had it boot straight to the desktop and a couple of times to a blank console screen which booted fine the 2nd time.
I shall keep testing, but now I've deleted rpiwiggle.service, it mostly works. I'll try with a proper HDMI screen and on other RPI models. I had no problem with the rpi2 version.

---

I was more pointing out what is happening on the first boot; I'm not sure why the rpi4 would react like that - which edition do you have?

I haven't seen that happen with my rpi4(4GB) here, so I'm not sure why yours isn't - is there any chance you could check the journalctl -xe output and see if there's a failing systemd unit?

I have a late alpha (possibly production) Pi4B-4GB.

OK, I'll check the journalctl next time I have a chance. It could be smi-hack is failing because I noticed the following thread about vnc failing:
https://forums.kali.org/showthread.php?44565-Problem-with-vncserver-running-Kali-2019-2-arm32-bit&p=86493#post86493

And the solution to that (dpkg-reconfigure xfonts-base) seems to be included in smi-hack already, so maybe it wasn't being applied? (EDIT: I think that commit was subsequent to my 2019.2a version, hence it is not included in my vesion).
Or maybe there's something else that doesn't like kali being moved to partitions 6&7 :shrug:
Anyway, we'll see what journalctl says.

I've done another re-install using PINN, with rpiwiggle removed.
On HDMI, I got:
o the scrolling boot text.
o Then black screen with occasional flashing white mouse pointer in the centre of the screen.
o Finally a black screen with 2 text messages:
IPV6 ADDRCONF(NETDEV_UP): wlan0: link is not ready
brcmfmac: power management disabled


I logged in via ssh and captured some status files. Please see https://github.com/procount/kali/tree/master/1


Using the keyboard, I swapped to console 1 and logged in. Startx brought the desktop up.
Subsequent reboots go straight to the desktop.

EDIT: I repeated the install and captured the logs in https://github.com/procount/kali/tree/master/2
Would it help if I posted a copy of PINN with the Kali install files so you can try it for yourself?