Myron

Moved to P2P help.

Please provide the contents of the overlay you've added and also diagnostic information obtained using . . . armbianmonitor -u

Please provide the diagnostic logs using: armbianmonitor -u You'll have a better chance someone helping you if you provide this information.

I've had this issue. I believe I resolved it by ensuring that unix password sync = no is set and then I use the utility smbpasswd to set the desired password for the SMB share. After that my Windows 10 machine could access the share.

What's the version of the Kernel on the image you installed from sd-card-images.johang.se?

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!)