Hi there, 

 

I have a Banana Pi M1+ and connected to it Silicon Power SSD 60 Gb.

I've faced with the following error: Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00(see screenshots).

 

• Startup: https://drive.google.com/open?id=1s_1mkJWXTC02TnSyVlX8oZZQDaJpgXYu 
• Kernel panic message: https://drive.google.com/open?id=1oDgmnrOspkYy5DY5bobFLTJSE3RJOVE6

 

I downloaded and wrote Armiban to the SD card from this link: https://dl.armbian.com/bananapi/Debian_stretch_next.7z,

It started well.

 

Then I performed apt update && apt upgrade -y and reboot the system.

After that I've used 'nand-sata-install' to move system to SATA SSD and got that error.

 

Previouslly I did the same steps with usual Banana Pi M1 (not plus version) and it works well, but with the M1 plus version I got that error.

 

Thanks, Roman.

Can you do the following test please? Reimage SD card with Debian_stretch_next.7z, boot, apply all updates, shutdown, connect the SSD, then turn the board back on again. Then please provide output from

armbianmonitor -u

No further steps needed at this moment.

Hello @tkaiser,

 

Please see below the results of specified command:

 

armbianmonitor -u
System diagnosis information will now be uploaded to 
http://ix.io/13H5
Please post the URL in the forum where you've been asked for.

 

10 minutes ago, Roman B said:

Please see below the results of specified command

 

Thank you. I was looking for underpowering but that's totally fine (5.19V with connected SSD):

### Boot system health:

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU   PMIC   DC-IN  C.St.
09:54:20:  960MHz  1.05  76%  40%  32%   0%   3%   0% 37.0°C 29.4°C   5.19V  0/6
09:54:21:  960MHz  1.20  73%  31%  36%   2%   3%   0% 37.1°C 29.2°C   5.26V  0/6
09:54:22:  960MHz  1.20  35%  28%   3%   2%   1%   0% 36.3°C 28.7°C   5.23V  0/6
09:54:23:  960MHz  1.20  24%  16%   0%   2%   5%   0% 35.6°C 28.3°C   5.25V  0/6
09:54:25:  960MHz  1.20  15%   9%   0%   1%   4%   0% 35.5°C 28.5°C   5.22V  0/6

 

Please note that you're now running with 4.14.14 (as expected) while you were on 4.13 before which is a bit weird given that you installed all updates.

@tkaiser, could you please clarify your note about kernel versions, I didn't quite catch it.

 

 

On your screenshot the kernel panic happens with a 4.13 kernel while now after you applied all updates you're on 4.14. So my assumption is that something went wrong before (you said 'I performed apt update && apt upgrade -y and reboot the system' -- but then you should've also been running with 4.14)

@tkaiser, thank you for clarification.

 

It is because I provided screen captures for different attempts.

 

I tried to use older version of armbian, but every time I got the same version.

 

Now I've plugged 3A power supply and upgrade OS to the 4.14.18 version of kernel.

 

Take a look at mon logs: http://ix.io/13Ih.

 

 

 

Changing power supply didn't help.

 

Any ideas how to figure out the root cause of that issue or how to resolve it?

Can you try to capture the lines prior to the kernel panic. Without serial console it can become hard to diagnose this since without looking through a detailed log this becomes a job for mind readers

I've posted photo for it in my first comment on this issue.

Let me duplicate it in attachment to this comment:

Spoiler

 

And there are no other lines, just kernel panic after this screen.

 

Thanks, Roman.

 

Please see how to increase boot verbosity: https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toogle-verbose-boot

 

Do you have a serial console? That would be really helpful since it allows to record the boot process with increased boot verbosity.

 

Then if the issue only occurs after you executed nand-sata-install can you take the SD card, access the rootfs and pastebin /var/log/armhwinfo.log and /var/log/nand-sata-install.log?

Hello @tkaiser, thank you for provided tips.

I'm still collecting this data, which you have requested and I will add it later.

 

Also it looks like I managed to find out one of the reason of the issue: It is new version of Silicon Power SSD drive (SP60).

 

The same issue I've got if try to use Banana Pi M1 with that SSDs, so issue appears not only with M1 + and also with usual M1(I have several such SSDs, so it is not a problem of a particular one).

If I transfer system to the old version of SSD, everything works.

 

Thanks, Roman.

Hi @tkaiser, I wrote the latest version on the new SD card, then performed apt-update && apt upgrade.

 

Then I ran nand-sata-intall.

 

Set logs verbosity to 7 and collect logs from SSD and SD card.

Please take a look at attached logs..

 

 

 

logs fom SSD.7z

kern.log

nand-sata-install.log

armhwinfo.log

I see the following lines in the kern.log:

 

Mar 29 18:01:22 localhost kernel: [  152.729764] EXT4-fs (sda1): Unrecognized mount option "compress-force=zlib" or missing value
Mar 29 18:01:22 localhost kernel: [  152.810043] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

Looks like it tried to use 'compress-force=zlib' for EXT4 fs, is it ok?

3 hours ago, Roman B said:

Looks like it tried to use 'compress-force=zlib' for EXT4 fs, is it ok?

This is harmless. But I found a serious issue in nand-sata-install.log:

Checking again for open files:
apt.syste 1377       root   11w   REG  179,1        0 35214 /var/lib/apt/daily_lock
unattende 1411       root    4uW  REG  179,1        0 35242 /var/lib/dpkg/lock
http      2483       _apt    4u   REG  179,1  4370166 37513 /var/cache/apt/archives/partial/g++-6_6.3.0-18+deb9u1_armhf.deb

That means unattended-upgrades was running while the installation has been cloned with rsync which will result in a corrupted installation for sure. This is something that needs a fix in nand-sata-install anyway. Cloning a running system is always a problem but with a running install orgy in the background it must fail.

I've tried it again with disabled unattended-update and got the same results.

 

Spoiler

Fri Mar 30 14:24:34 UTC 2018: Start nand-sata-install.


Old UUID:  UUID=62fc7248-9a57-4024-90d9-b4767bd2c697
SD UUID:   UUID=62fc7248-9a57-4024-90d9-b4767bd2c697
SATA UUID: UUID=efedf86c-3710-4406-86e1-5c48a9e12aef
eMMC UUID:  
Boot: $1  
Root: $2 /dev/sda1 ext4
Usage: 1123
Dest: 53155

/etc/fstab:
UUID=62fc7248-9a57-4024-90d9-b4767bd2c697 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0
/var/swap none swap sw 0 0

/etc/mtab:
/dev/mmcblk0p1 / ext4 rw,noatime,nodiratime,errors=remount-ro,commit=600 0 0
/dev/mmcblk0p1 /var/log.hdd ext4 rw,noatime,nodiratime,errors=remount-ro,commit=600 0 0
/dev/sda1 /mnt/nand-sata-install.iK7mhx/rootfs ext4 rw,relatime,data=ordered 0 0

Files currently open for writing:
dhclient   726       root    4w   REG  179,1     1026  37490 /var/lib/dhcp/dhclient.eth0.leases

Trying to stop running services to minimize open files:
Stopping cron.service 

Checking again for open files:

Copying 37336 files to /dev/sda1. Finishing transfer to USB/SATA, boot from SD/eMMC

Checking again for open files:

Fri Mar 30 14:33:07 UTC 2018: Finished

 

 

So it is definitely not related to the updates.

Only one thing which make it works well is to change SSD drive, so my suggestion is only one: some errors appears because of unsupported SSD drive.

 

But hot to solve it?