Banana Pro image does not boot, mounting problem?

[haseHH]

Hello, I ran into a problem when installing Kali to my Banana Pro. I tried the official Kali Linux ARM images as well as building my own with the scripts from this repository, both produced the same outcome.

When powering up the board with only a keyboard, a mouse and an HDMI cable attached to it, it takes a few seconds for the Monitor to receive a signal. After a second of black, the two Tux icons from the beginning of the boot sequence show up, but then it freezes, no text is displayed.

I connected to the onboard serial console and got the output from U-Boot. The full output can be seen here: serial-output.txt

At the end, these error messages appear:

<27>systemd[1]: Failed to determine whether /sys is a mount point: Bad file descriptor
[    5.420697] systemd[1]: Failed to determine whether /sys is a mount point: Bad file descriptor
<27>systemd[1]: Failed to determine whether /proc is a mount point: Bad file descriptor
[    5.437259] systemd[1]: Failed to determine whether /proc is a mount point: Bad file descriptor
<27>systemd[1]: Failed to determine whether /dev is a mount point: Bad file descriptor
[    5.453690] systemd[1]: Failed to determine whether /dev is a mount point: Bad file descriptor
[!!!!!!] Failed to mount early API filesystems, freezing.
<24>systemd[1]: Freezing execution.
[    5.477414] systemd[1]: Freezing execution.

The timing of the freeze messages on the last three lines matches with the appearance of the Tux icons on the monitor.

Did anybody encounter something like that before? Any suggestions on what to try next?

PS: I hope I'm at the right place to ask stuff like this.

PPS: I am sure that all the hardware I use is okay. I'm using a 5V/2A power supply which should be enough and when I flash Bananian, Raspbian for Banana Pro and other distributions to the same card, everything works just fine... Just Kali is giving me a hard time, so I'd appreciate every and all help.

[omgkillme]

Same thing is happening to me. Looks like the script uses the old patched legacy kernel. 👎

[haseHH]

You're right, it's loading the 3.4 kernel from the LeMaker repo... Currently the most up to date version would be 4.17. What needs to be done to use another kernel?

[omgkillme]

Need to update the script. I was trying to build the kernel and u-boot manually last night and crashed 🤦‍♂️ Maybe try borrowing some of the Armbian build script and cobble together a new one :/

[EvilDonkey420]

well ur obviously suffering from Aspergers

…

________________________________ From: omgkillme <notifications@github.com> Sent: Thursday, June 7, 2018 6:39 AM To: offensive-security/kali-arm-build-scripts Cc: Subscribed Subject: Re: [offensive-security/kali-arm-build-scripts] Banana Pro image does not boot, mounting problem? (#128) Same thing is happening to me. Looks like the script uses the old patched legacy kernel. 👎 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#128 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZJX7K3PrEpKKzbQeJru-clMV2-967Wdks5t6Mq_gaJpZM4USFS4>.

[steev]

Updating to a newer kernel/u-boot is on the roadmap, it just hasn't been done yet.

[haseHH]

That's great, thank you for the info! Is there already a planned timetable for the roadmap?

[steev]

No timetable, unfortunately. If you know of a working kernel already, that would be great, otherwise I need to continue looking around myself. Last I knew mainline kernels were still missing support for various bits and pieces. The LeMaker GitHub doesn't seem to have a 4.x kernel posted, but they do have a newer u-boot which is at least a step in the right direction.

[haseHH]

I'd love to help, but sadly the kernel and it's usage are above my capabilities. I never found the time to get into that knowledge... So I'm very thankful for anyone who can find the time and is willing to invest it in projects like these builscripts.

[steev]

There's no time like the present to learn! But seriously, you don't necessarily need to know kernel development in order to build a kernel and test it. The build scripts are set up to allow you to replace the current kernel checkout with a new one fairly easily.

I plan to look at armbian's kernel work on the sunxi boards, because they're a great group of people working on it, and I know they focus mostly on sunxi type boards. Even just pulling the kernel the way they do, and then applying the patches and testing that it even builds would be a good start

[m2mmbp]

Still doesn't boot on banana pro :-(

[raplin]

Please (if anyone is in charge of them) edit the Kali BananaPi downloads web page to indicate the builds are broken. People are wasting time trying it (like me). Thanks! ;-)

[steev]

Can you link me where you got your BPi? The images work on mine, but I've had them for so long I don't recall where I got mine. I'll grab a new one so I can be sure I have the same version that @raplin and @m2mmbp have and see if I can reproduce the issue here.

[raplin]

The actual BPi hardware? I have a stack of 'em and nothing has changed; Allwinner A20 etc. I tried several boards, SD cards etc with 100% consistent result, fails to mount the root fs, like this:

  4.732201]  mmcblk0: p1 p2
<6>EXT4-fs (mmcblk0p2): recovery complete
[    4.908576] EXT4-fs (mmcblk0p2): recovery complete
<6>EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    4.921494] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. O                                                                pts: (null)
<6>VFS: Mounted root (ext4 filesystem) on device 179:2.
[    4.934662] VFS: Mounted root (ext4 filesystem) on device 179:2.
<6>devtmpfs: mounted
[    4.945065] devtmpfs: mounted
<6>Freeing init memory: 228K
[    4.950928] Freeing init memory: 228K
<27>systemd[1]: Failed to determine whether /sys is a mount point: Bad file desc                                                                riptor
[    5.409387] systemd[1]: Failed to determine whether /sys is a mount point: Ba                                                                d file descriptor
<27>systemd[1]: Failed to determine whether /proc is a mount point: Bad file des                                                                criptor
[    5.425884] systemd[1]: Failed to determine whether /proc is a mount point: B                                                                ad file descriptor
<27>systemd[1]: Failed to determine whether /dev is a mount point: Bad file desc                                                                riptor
[    5.442301] systemd[1]: Failed to determine whether /dev is a mount point: Ba                                                                d file descriptor
[!!!!!!<] Failed to mount early API filesystems, freezing.
24>systemd[1]: Freezing execution.
[    5.468755] systemd[1]: Freezing execution.

everything else earlier in the boot looks reasonable (it sees USB devices etc), note it correctly reads the two partitions on the card. I can mount partition 2 fine on another device with an external sd reader)

Full log at https://pastebin.com/884AyrmD this is with https://images.offensive-security.com/arm-images/kali-linux-2018.4-bananapi.img.xz on Banana Pi M1

[steev]

It's mounting the partition, but then for some reason, it's failing the checks on /sys,/proc, and /dev - I'm not sure what is going on there - if you have another linux system, can you mount the second partition of the sdcard and look at the device nodes in /dev - if /dev /sys and /proc exist?

Bad descriptor typically means its corrupt in some way - what size sdcard are you using?

[raplin]

32GB sd card. Mounts cleanly on a USB reader. SD card is good quality, I tried another one too, same thing.
device nodes appear to be there when mounted on a host device; not sure if they're correct
https://pastebin.com/AkCDbnDe
the /sys /proc and /home are all empty, btw

[steev]

That's definitely odd; can you try re-creating the /dev/null and /dev/console devices on the sdcard?

If you're not familiar, it would look something like...

mkdir /mnt/sdcard
mount /dev/mmcblk0p2 /mnt/sdcard
cd /mnt/sdcard/dev
rm console
rm null
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3
sync
cd /
umount /mnt/sdcard

Then attempt to boot again? I'm wondering if the character devices in /dev are broken somehow.

[raplin]

Before: (original image mounted on usb reader)

root@orangepione:/tmp/kali/dev# ls -lar
total 16
crw-rw-rw-  1 root root 1, 5 Oct 17 13:41 zero
crw-rw-rw-  1 root root 1, 9 Oct 17 13:41 urandom
crw-rw-rw-  1 root root 5, 0 Oct 17 13:41 tty
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stdout -> /proc/self/fd/1
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stdin -> /proc/self/fd/0
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stderr -> /proc/self/fd/2
drwxr-xr-x  2 root root 4096 Oct 17 13:41 shm
crw-rw-rw-  1 root root 1, 8 Oct 17 13:41 random
drwxr-xr-x  2 root root 4096 Oct 17 13:41 pts
crw-rw-rw-  1 root root 5, 2 Oct 17 13:41 ptmx
crw-rw-rw-  1 root root 1, 3 Oct 17 13:41 null
crw-rw-rw-  1 root root 1, 7 Oct 17 13:41 full
lrwxrwxrwx  1 root root   13 Oct 17 13:41 fd -> /proc/self/fd
crw-rw-rw-  1 root root 5, 1 Oct 17 13:41 console
drwxr-xr-x 18 root root 4096 Oct 17 14:06 ..
drwxr-xr-x  4 root root 4096 Oct 17 13:41 .

root@orangepione:/tmp/kali/dev# stat console null
  File: ‘console’
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 802h/2050d      Inode: 195458      Links: 1     Device type: 5,1
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-10-17 14:14:53.371421521 -0700
Modify: 2018-10-17 13:41:53.181785076 -0700
Change: 2018-10-17 14:14:53.371421521 -0700
 Birth: -
  File: ‘null’
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 802h/2050d      Inode: 195461      Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-10-17 14:14:53.371421521 -0700
Modify: 2018-10-17 13:41:53.177785105 -0700
Change: 2018-10-17 14:14:53.371421521 -0700
 Birth: -

I remade the nodes anyway, wrote to card, rebooted, same systemd error:

<27>systemd[1]: Failed to determine whether /sys is a mount point: Bad file descriptor
[    5.371610] systemd[1]: Failed to determine whether /sys is a mount point: Bad file descriptor
<27>systemd[1]: Failed to determine whether /proc is a mount point: Bad file descriptor
[    5.388096] systemd[1]: Failed to determine whether /proc is a mount point: Bad file descriptor
<27>systemd[1]: Failed to determine whether /dev is a mount point: Bad file descriptor
[    5.404515] systemd[1]: Failed to determine whether /dev is a mount point: Bad file descriptor
[!!!!!!<] Failed to mount early API filesystems, freezing.
24>systemd[1]: Freezing execution.
[    5.431033] systemd[1]: Freezing execution.

When mounted on another sbc (orange pi, 3.4 kernel) fsck reports the partition is fine
sys, proc and dev look like this:

root@orangepione:/tmp/kali# ls -lar
total 80
drwxr-xr-x  12 root root  4096 Oct 17 13:54 var
drwxr-xr-x  10 root root  4096 Oct 17 13:42 usr
drwxrwxrwt   2 root root  4096 Sep 11 23:36 tmp
drwxr-xr-x   2 root root  4096 Sep 11 23:36 sys
drwxr-xr-x   2 root root  4096 Oct 17 13:42 srv
lrwxrwxrwx   1 root root     8 Oct 17 13:41 sbin -> usr/sbin
drwxr-xr-x   2 root root  4096 Sep 11 23:36 run
drwx------   2 root root  4096 Oct 17 13:42 root
drwxr-xr-x   2 root root  4096 Sep 11 23:36 proc
drwxr-xr-x   2 root root  4096 Oct 17 13:42 opt
drwxr-xr-x   2 root root  4096 Oct 17 13:42 mnt
drwxr-xr-x   2 root root  4096 Oct 17 13:42 media
drwx------   2 root root 16384 Oct 17 14:14 lost+found
lrwxrwxrwx   1 root root     7 Oct 17 13:41 lib -> usr/lib
drwxr-xr-x   2 root root  4096 Sep 11 23:36 home
drwxr-xr-x 100 root root  4096 Oct 17 14:06 etc
drwxr-xr-x   4 root root  4096 Nov 10 14:51 dev
drwxr-xr-x   2 root root  4096 Oct 17 14:14 boot
lrwxrwxrwx   1 root root     7 Oct 17 13:41 bin -> usr/bin
drwxrwxrwt   8 root root   180 Nov 10 14:55 ..
drwxr-xr-x  18 root root  4096 Oct 17 14:06 .
root@orangepione:/tmp/kali# ls -lar sys proc dev
sys:
total 8
drwxr-xr-x 18 root root 4096 Oct 17 14:06 ..
drwxr-xr-x  2 root root 4096 Sep 11 23:36 .

proc:
total 8
drwxr-xr-x 18 root root 4096 Oct 17 14:06 ..
drwxr-xr-x  2 root root 4096 Sep 11 23:36 .

dev:
total 16
crw-rw-rw-  1 root root 1, 5 Oct 17 13:41 zero
crw-rw-rw-  1 root root 1, 9 Oct 17 13:41 urandom
crw-rw-rw-  1 root root 5, 0 Oct 17 13:41 tty
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stdout -> /proc/self/fd/1
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stdin -> /proc/self/fd/0
lrwxrwxrwx  1 root root   15 Oct 17 13:41 stderr -> /proc/self/fd/2
drwxr-xr-x  2 root root 4096 Oct 17 13:41 shm
crw-rw-rw-  1 root root 1, 8 Oct 17 13:41 random
drwxr-xr-x  2 root root 4096 Oct 17 13:41 pts
crw-rw-rw-  1 root root 5, 2 Oct 17 13:41 ptmx
crw-rw----  1 root root 1, 3 Nov 10 14:51 null
crw-rw-rw-  1 root root 1, 7 Oct 17 13:41 full
lrwxrwxrwx  1 root root   13 Oct 17 13:41 fd -> /proc/self/fd
crw-rw----  1 root root 5, 1 Nov 10 14:51 console
drwxr-xr-x 18 root root 4096 Oct 17 14:06 ..
drwxr-xr-x  4 root root 4096 Nov 10 14:51 .

I use armbian a lot and on their forum someone refers to same boot-time error as "probably a systemd bug"
https://forum.armbian.com/topic/4710-systemd-failed-to-boot-bad-file-descriptor/

[hartzell]

This message on the Arch Linux site suggestions that it's not so much a "systemd bug" as it is a bad interaction between a newer systemd and an older kernel.

I'm not in a position to build ARM stuff.

Are there older Kali Linux releases archived anywhere?

Would it be possible to mark this image "non-functional"

[hartzell]

ps. I'm seeing the failure on a third gen Banana Pi Pro.

[steev]

Indeed, I need to look into moving the bananap* devices to a newer kernel. Conceivably, they should work, I just haven’t had a chance to test or look into it

On Sat, Jan 19, 2019 at 6:43 PM George Hartzell ***@***.***> wrote: ps. I'm seeing the failure on a third gen Banana Pi Pro. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcysSHk2pUrYs7Wbh8ESuO8j0WS22qks5vE62ugaJpZM4USFS4> .

-- Sent from my iPhone.

[steev]

To cycle back to this as well - we do need a newer kernel being used on the devices - systemd's readme ( https://github.com/systemd/systemd/blob/master/README#L34 ) says that it requires 3.13 as the minimum kernel, so I need to move the kernels for most of the boards to newer kernels when they have lower than that.