Myron

I've corrected the topic subject for you.

What does this command report on your system: cat /proc/cpuinfo As far as I know there is no /dev/cpuinfo.

Moved to P2P help.

Please provide diagnostic information using: armbianmonitor -u Post the link given. By providing additional diagnostic information you may have a better chance of someone replying with ideas and possibly answers.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

This discussion thread may be of use to you. The initial user name and password from a fresh install has not changed.

For @Igor and/or @Werner. What's the difference between the current user ./compile.sh built kernel and a pre-compiled current built kernel on hosted on https://imola.armbian.com/beta/pool/main/l/ ?

It's a guess. What the Kernel may be trying to so is to set the power controller to actually power-down the board, but that final function is turning it off is failing. Seems like it is a very old bug and not just affecting the BananaPi Pro. Ref: https://www.spinics.net/lists/linux-i2c/msg42348.html

That's just for the armbian-config utility.

I've noticed this too on my BananaPi Pro board too. From my board the armbianmonitor diagnostics is here: http://ix.io/3VH9 Here is what I get: root@loki:~# poweroff [503985.574336] reboot: Power down [503985.612166] ------------[ cut here ]------------ [503985.668455] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:41 i2c_transfer+0x93/0xbc [503985.764283] No atomic I2C transfer handler for 'i2c-1' [503985.826794] Modules linked in: tun cmac nls_utf8 cifs cifs_arc4 cifs_md4 fscache netfs overlay xt_multiport l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox ppp_generic slhc ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog xt_recent xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables iptable_filter evdev axp20x_adc brcmfmac lima gpu_sched sun4i_gpadc_iio industrialio brcmutil cfg80211 sun4i_ts sunxi_cir rfkill sunxi_cedrus(C) v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common display_connector uio_pdrv_genirq uio cpufreq_dt binfmt_misc sch_fq_codel sunrpc ip_tables x_tables autofs4 pwrseq_simple sun4i_gpadc realtek [503986.634338] CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G C 5.15.32-sunxi #trunk [503986.740544] Hardware name: Allwinner sun7i (A20) Family [503986.804106] [<c010cea9>] (unwind_backtrace) from [<c01095b9>] (show_stack+0x11/0x14) [503986.897846] [<c01095b9>] (show_stack) from [<c09cc035>] (dump_stack_lvl+0x2b/0x34) [503986.989505] [<c09cc035>] (dump_stack_lvl) from [<c011b5a9>] (__warn+0xad/0xc0) [503987.076999] [<c011b5a9>] (__warn) from [<c09c5c23>] (warn_slowpath_fmt+0x5f/0x7c) [503987.167615] [<c09c5c23>] (warn_slowpath_fmt) from [<c0795a5f>] (i2c_transfer+0x93/0xbc) [503987.264472] [<c0795a5f>] (i2c_transfer) from [<c0795ac3>] (i2c_transfer_buffer_flags+0x3b/0x50) [503987.369648] [<c0795ac3>] (i2c_transfer_buffer_flags) from [<c0697577>] (regmap_i2c_write+0x13/0x24) [503987.478985] [<c0697577>] (regmap_i2c_write) from [<c0694023>] (_regmap_raw_write_impl+0x48b/0x560) [503987.587282] [<c0694023>] (_regmap_raw_write_impl) from [<c0694139>] (_regmap_bus_raw_write+0x41/0x5c) [503987.698697] [<c0694139>] (_regmap_bus_raw_write) from [<c06939b1>] (_regmap_write+0x35/0xc8) [503987.800753] [<c06939b1>] (_regmap_write) from [<c06948b5>] (regmap_write+0x29/0x3c) [503987.893443] [<c06948b5>] (regmap_write) from [<c069e723>] (axp20x_power_off+0x23/0x30) [503987.989261] [<c069e723>] (axp20x_power_off) from [<c0137ded>] (__do_sys_reboot+0xf5/0x16c) [503988.089238] [<c0137ded>] (__do_sys_reboot) from [<c0100061>] (ret_fast_syscall+0x1/0x52) [503988.187132] Exception stack(0xc1557fa8 to 0xc1557ff0) [503988.248616] 7fa0: 4321fedc be8b0aa8 fee1dead 28121969 4321fedc 00000000 [503988.347544] 7fc0: 4321fedc be8b0aa8 be8b0aa4 00000058 be8b0aa8 be8b0aa4 fffff000 be8b0aac [503988.446465] 7fe0: 00000058 be8b0a1c b6f381b5 b6eb67e6 [503988.507941] ---[ end trace 7944c4f50e61189e ]--- [503989.583768] i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0 [503990.191744] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 [503990.284440] CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G WC 5.15.32-sunxi #trunk [503990.390645] Hardware name: Allwinner sun7i (A20) Family [503990.454205] [<c010cea9>] (unwind_backtrace) from [<c01095b9>] (show_stack+0x11/0x14) [503990.547955] [<c01095b9>] (show_stack) from [<c09cc035>] (dump_stack_lvl+0x2b/0x34) [503990.639611] [<c09cc035>] (dump_stack_lvl) from [<c09c5a4d>] (panic+0xc1/0x238) [503990.727108] [<c09c5a4d>] (panic) from [<c011fd5d>] (complete_and_exit+0x1/0x18) [503990.815643] [<c011fd5d>] (complete_and_exit) from [<fee1dead>] (0xfee1dead) [503990.900024] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 ]--- @Tone please provide logs for your board Provide logs with armbianmonitor -u

Curious. I just installed both using apt under Armbian 22.05.0-trunk Focal with Linux 5.15.32-sunxi kernel.

From what I can tell from the smartctl output there should be no reason why any data would be lost. Every hard drive has an area reserved where if a write is attempted on a part of the disk and fails, the drive reallocated the wrote to a reserved area for this purpose, so at the moment your hard drive is functioning. the problems start when an extended S.M.A.R.T. self-test fails. Make sure you have a backup in case it does fail.

Simple answer. Don't trust that drive and replace it.

Yeh... This one is also way above my pay grade. I've had a manual kernel upgrade fail on me not that long ago and I resorted to building a brand new server image using the Armbian build framework and rescue my configurations from the bricked SD card into the new one. This would be about a month ago. I've only very recently got this new-built system up to where it was before it became bricked. Was it a simple apt update && apt upgrade that ended up bricking your system? May be worth freezing kernel upgrades or getting a second SD card, cloning a working card into the other card so when an upgrade goes wrong, just take that card out and put in the cloned working card then suffer the headaches of trying to figure out what went wrong. I'll admit that at this present moment in time I do not know how to start diagnosing this sort of problem. Hopefully someone will see this thread have a AHA! moment and provide a solution or workaround.

Another thought. Have you bridged RX and TX together on the USB to RS232 board to make sure that the board is working? Some of these boards have ab LED on the RX and TX lines. When you power-up your SoC board, do any or both of these LEDs blink?

May be a question, but have you tried each of the three baud rates that getty is configured to use? Those being 115200, 38400 and 9600? I've had a few cases where for some reason the default baud rate was not being used and had to get putty to try the latter two baud rates to be able to get output from the board and be able to login and issue commands.

Well... In that case I have a space 32Gb SD card. I shall clone the working SD card, try and upgrade on the copy. If it works, great. If it does not, well.... Boo!!! I shall report back here with my findings.

Was looking through Twitter and saw that a message can appear stating that Jammy LTS may be unsupported userspace? I'm presently (with preset kernel build options used and no customisations) Armbian 22.05.0-trunk Focal with Linux 5.15.32-sunxi Apparently my build is on 20.04 LTS? ~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS" What would be any advantages and/consequences if someone invokes do-release-upgrade on or after the 21st of April on their SoC board? Reference to article: https://web.archive.org/web/20220406214352/https://www.techrepublic.com/article/how-to-upgrade-ubuntu-server-from-20-04-to-22-04/

@teknoid Confirming that the patch had worked on the latest build that the Armbian Framework puts together. This is Armbian 22.05 trunk and Linux Kernel 5.15.32. [ 3.273532] kernel: ahci-sunxi 1c18000.sata: supply ahci not found, using dummy regulator [ 3.281429] kernel: ahci-sunxi 1c18000.sata: supply phy not found, using dummy regulator [ 3.344049] kernel: ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 3.351593] kernel: ahci-sunxi 1c18000.sata: forcing PORTS_IMPL to 0x1 [ 3.357504] kernel: ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [ 3.366500] kernel: ahci-sunxi 1c18000.sata: flags: ncq sntf pm led clo only pio slum part ccc [ 3.376130] kernel: scsi host0: ahci-sunxi [ 3.380046] kernel: ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 45 Thank-you. You're a star. Where can I go to learn to figure out how the user overlay works? I can see it's activated line 40 of gpiochip0 [1c20800.pinctrl] .which has changed from an input to an output. I'm not sure how the dtb below relates to the result of line 40 being activated. // enable SATA AHCI on bananapi pro /dts-v1/; /plugin/; / { compatible = "lemaker,bananapro", "allwinner,sun7i-a20"; fragment@0 { target = <&reg_ahci_5v>; __overlay__ { status = "okay"; }; }; }; I'm trying to search for the information myself, but not having much luck. EDIT 5/April/2002 12:17 UTC+1 - What I find curious is looking through the main device tree I spotted this . . . . ahci-5v { compatible = "regulator-fixed"; regulator-name = "ahci-5v"; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; regulator-boot-on; enable-active-high; gpio = <0x19 0x01 0x08 0x00>; status = "disabled"; phandle = <0x24>; Was the solution always to simply change the status from "disabled" to "okay" and that would have enabled the SATA port? I know that upgrading the kernel and its device tree would undo the change so I'm assuming your solution of supplying a DT overlay makes the setting persist across kernel and DT upgrades? (Did I make any sense with that lot?)

In that case I promise to be a good user and not to tamper with the scripts and/or the build process. 😉 (... as should everyone else promise to do the same!)

@TRS-80 Maybe it's a good thing that I got a 32Gb card in the BananaPi Pro. After a week the systemd task did fire and the result was.... Apr 4 00:00:54 loki fstrim[7422]: /: 20.2 GiB (21645828096 bytes) trimmed on /dev/mmcblk0p1 I may have fstrimmed the card a day or so into the week so this time I have to promise myself to leave it alone and check again in 6 days.

For backups I occasionally create a direct sector-by-sector image using Win32DiskImager. Usually when I've made a fair few user-land alterations, which reminds me that I am due to take another back-up soon.

Ah.. That explains just about everything. Been there myself and suffered the headaches myself too. What are the consequences, if there are any, if the user simply uses the Armbian Framework to generate an image with the pre-programmed settings and without making any of these unknown modifications? ... or, upgrade the kernel also without making any modifications? I'm guessing what I'm asking is, if a mature untampered with user-built image and kernel in the same class as a maintainer's built image and kernel?

For this question the assumption is that a board actually has a maintainer and I think the answer given will be useful for anyone else with the same or similar question. May end up being a candidate for some FAQ list. Question is.... If a board has a maintainer and the user builds the image themselves using the recommended default kernel/compilation option, why is there no support for the built image? Rationale behind the question is if the user decides to change the kernel build options then there would bo no doubt that the user will be on their own with no support, but if the kernel is built with the default hard built options then there has been no tinkering. Therefore the trunk built image/kernel could/should be offered support by the maintainer? Especially if the board within the Armbian framework has not been moved to CSC/EOS/WIP and is still the the Matured list of boards.

My dear @teknoid, I've been trying to decipher the topic of device trees and, honestly, I'm totally lost, so I beg a question. On the device tree listed in the spoiler, what do I need to do to get the SATA port up-and-running?