09:10 <DC-IRC> [Discord] <Github> ✅ **Merged** into [armbian/documentation](<https://github.com/armbian/documentation>) by [igorpecovnik](<https://github.com/igorpecovnik>) - [Link](<https://github.com/armbian/documentation/commit/340f76e4d399c832b942fe257e491ca4449c5f5c>): *Bump devindford/Append_PR_Comment from 1.1.2 to 1.1.3*

09:14 <DC-IRC> [Discord] <Github> ✅ **Merged** into [armbian/documentation](<https://github.com/armbian/documentation>) by [igorpecovnik](<https://github.com/igorpecovnik>) - [Link](<https://github.com/armbian/documentation/commit/754578c96c255e98320134a1093af7ee1ec25674>): *Build framework documentation: rework getting started part*

09:14 <DC-IRC> [Discord] <Github> ✅ **Merged** into [armbian/documentation](<https://github.com/armbian/documentation>) by [igorpecovnik](<https://github.com/igorpecovnik>) - [Link](<https://github.com/armbian/documentation/commit/971eab11b7408c5dc9c936a75e76d3361e7620f5>): *Documentation: Improve contribute section*

09:58 <Hammdist> hello. I try to run the IOT image on orange pi 5. I actually get display output (hurrah). but the bootup hangs at "Found device dev-ttyS2.device - /dev/ttyS2". any idea how to debug? I suspect it is switching the console to ttyS2 which I don't want but don't know how to prevent

09:59 <DC-IRC> [Discord] <Werner> Debug.armbian.de

10:05 <Hammdist> becaues it is minimal image my thinking at this point is it might not have the login program even installed (intended for automation only). any idea what it is called so I can install it?

10:06 <DC-IRC> [Discord] <menu> minimal images definitely should, i'll grab one and double check

10:08 <Hammdist> well before I set anyone on a wild goose chase I feel I should mention that I am not running the stock image but one with a few extra programs installed

10:08 <Hammdist> maybe I broke something. let me try the stock image first

10:18 <Hammdist> stock also does not make it to a login or shell. it seems to stop at a different step though or maybe it is a race whether you see the last line or not before it switches to ttyS2

10:23 <Hammdist> ah wait

10:23 <Hammdist> when I tried a 2nd time I got to "Welcome to Armbian!"

10:32 <Hammdist> so it boils down to stock working most of the time, my image consistently does not work. so I broke something for sure

10:34 <DC-IRC> [Discord] <menu> i'm already suspecting the SDcard tbh

10:37 <Hammdist> I think I installed a script with non-zero exit status to /etc/rc.local. fixed script let's see if it works - but will take >30mins to recompile and test it

10:54 <DC-IRC> [Discord] <menu> Hammdist: i've verified a minimal image does indeed include `/usr/bin/bash`, though zsh isn't installed on minimal, SSH should be enabled by default

10:59 <Hammdist> well it wasn't the rc.local script

11:00 <Hammdist> don't have ethernet set up to the board

11:00 <Hammdist> don't understand why I don't get to console login but will keep digging

11:01 <DC-IRC> [Discord] <menu> do you have UART?

11:03 <Hammdist> nope. and the pi is in a case with screws and I'd have to hunt for a screwdriver.

11:03 <Hammdist> also iirc uart is completely borked for orange pi 5

11:04 <DC-IRC> [Discord] <menu> that's a pain, no networking or debug

11:04 <DC-IRC> [Discord] <menu> i haven't actually tested the UART on my oPi, don't have the correctly terminated cable

11:04 <Hammdist> don't bother - receiving from the pi is completely broken. but sending works if you do it blind

11:05 <DC-IRC> [Discord] <menu> i should get working on it then lol

11:33 <Hammdist> I have the strangest issue. early in boot, the caps lock key works to toggle the caps lock led on the keyboard. however after "Found device dev-ttyS2.device" input is completely dead

11:38 <DC-IRC> [Discord] <menu> Hammdist: does it boot without the keyboard connected?

11:41 <Hammdist> no, it gets stuck in the same place

11:41 <Hammdist> I injected an openvt bash. and I can even switch to it early in the boot. but as the boot continues the input to it dies

11:43 <DC-IRC> [Discord] <menu> that's... odd?

11:43 <Hammdist> maybe I need a console= kernel option but I don't know what to set it to

11:47 <DC-IRC> [Discord] <Github> ⤴️ **Pull request** to [armbian/documentation](<https://github.com/armbian/documentation>) by [igorpecovnik](<https://github.com/igorpecovnik>) - **Please review!** 👉 [Link](<https://github.com/armbian/documentation/pull/497>): *Move automatic configuration into separate documentation*

11:48 <DC-IRC> [Discord] <menu> you *shouldn't* require any changes to boot, i can't test baremetal unfortunately

12:15 <Hammdist> well as I said the stock image works. so one way to attack this is to bisect the changes I put on it, but I'm hoping there will be faster resolution with a different tack I'm exploring now

14:09 <DC-IRC> [Discord] <Github> ✅ **Merged** into [armbian/build](<https://github.com/armbian/build>) by [ColorfulRhino](<https://github.com/ColorfulRhino>) - [Link](<https://github.com/armbian/build/commit/435d9e29cf8ca6592b463659754df5a5613cf4cb>): *board: nanopc-t6: Bump uboot from 2024.07 to 2024.10 mainline (#7393) and add USB3 psu + pwm fan*

14:46 <DC-IRC> [Discord] <menu> does such concept as a hardware MAC address actually exist on oPi5/Armbian? i'm having trouble determining the actual MAC, it changes every boot

15:07 <DC-IRC> [Discord] <menu> other projects suggest *yes*, there should be a readable hw_addr, (DietPi etc.), but the orange pi forums say "no", and their own documentation is basically nonexistent

16:28 <DC-IRC> [Discord] <igorpec> this is hardware specific feature. if it should be, then you can enable this.

16:28 <DC-IRC> [Discord] <igorpec> or workaround / spoof mac

16:30 <DC-IRC> [Discord] <igorpec> https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstrun#L66

17:16 <DC-IRC> [Discord] <menu> from what i can tell Armbian uboot simply isn't capable

17:16 <DC-IRC> [Discord] <menu> i don't *want* to spoof the MAC, my router is having a hissy fit because the MAC keeps changing

17:48 <DC-IRC> [Discord] <beohoff3174> Hey trying to use armbian-install to boot from nvme instead of an SD results in a messed up kernel. I don't have ethernet or sound from the es8388.

17:48 <DC-IRC> [Discord] <beohoff3174> How do I debug this?

17:56 <DC-IRC> [Discord] <igorpec> then use uboot that is capable?

17:56 <DC-IRC> [Discord] <menu> i do not know how, uboot is a black box to me

17:57 <DC-IRC> [Discord] <igorpec> we can't help here. its simply too much work to fix everything

17:57 <DC-IRC> [Discord] <menu> how would i even go about loading a different uboot?

18:21 <DC-IRC> [Discord] <menu> is it as simple as editing the /boot partition or do i need to reflash the SPI?

20:06 <DC-IRC> [Discord] <runaway97> maybe. you should be able to insert a local-mac-address field in the devicetree via an overlay or just patch the base dtb.

20:08 <DC-IRC> [Discord] <runaway97> uboot can be made to generate a constant MAC by SoC serial, though i have no details if thats implemented in armbian uboot and how it would be enabled.

20:09 <DC-IRC> [Discord] <menu> i'm used to these things having a hardware address i can just read from

20:09 <DC-IRC> [Discord] <runaway97> maybe. you should be able to insert a local-mac-address field under gmac0/1 node in the devicetree via an overlay or just patch the base dtb.

20:11 <DC-IRC> [Discord] <runaway97> yes, the SoC serial can be read from OTP memory

20:12 <DC-IRC> [Discord] <runaway97> i would do some searching though rockchip/armbian uboot, pretty sure the code for it is already there

20:12 <DC-IRC> [Discord] <runaway97> i would do some searching through rockchip/armbian uboot, pretty sure the code for it is already there

20:14 <DC-IRC> [Discord] <Github> ⤴️ **Pull request** to [armbian/build](<https://github.com/armbian/build>) by [igorpecovnik](<https://github.com/igorpecovnik>) - **Please review!** 👉 [Link](<https://github.com/armbian/build/pull/7396>): *Firstlogin automation - add support for SSH key download*

20:16 <DC-IRC> [Discord] <menu> but there's no actual mac address burned in?

20:17 <DC-IRC> [Discord] <runaway97> what board?

20:18 <DC-IRC> [Discord] <menu> orange pi 5

20:19 <DC-IRC> [Discord] <runaway97> then no

20:20 <DC-IRC> [Discord] <runaway97> boards with dedicated realtek pci ethernet have means for that and some come with an address pre-burnt

20:20 <DC-IRC> [Discord] <runaway97> (not all though)

20:20 <DC-IRC> [Discord] <menu> ty, i suspected as much

20:21 <DC-IRC> [Discord] <menu> i take it the WoL support the OS reports is a complete no-go then?

20:24 <DC-IRC> [Discord] <runaway97> it may work, however i have not tested it

20:24 <DC-IRC> [Discord] <runaway97> as long as you give it a fixed mac address then there shouldn't be any issue

20:24 <DC-IRC> [Discord] <menu> without a static MAC it would appear to be impossible

20:25 <DC-IRC> [Discord] <menu> i have already tried setting the MAC and WoL mode, i do not think it will ever work

20:26 <DC-IRC> [Discord] <runaway97> how did you set the mac?

20:27 <DC-IRC> [Discord] <menu> tried setting in armbianEnv (didn't stick), nmcli (sticks but no WOL) and setting in `/etc/network/interfaces` (sticks, no WOL)

20:31 <DC-IRC> [Discord] <runaway97> the hardware certainly supports it since theres a WoL interrupt in devicetree

20:32 <DC-IRC> [Discord] <runaway97> it may just be driver issues all over again

20:32 <DC-IRC> [Discord] <runaway97> either in stmmac driver or phy

20:33 <DC-IRC> [Discord] <menu> i'd expect to see the link lights stay on if WoL was gonna work

20:34 <DC-IRC> [Discord] <runaway97> yea, maybe the driver is turning it off entirely on sleep or something

20:36 <DC-IRC> [Discord] <runaway97> https://www.forlinx.net/industrial-news/setup-linux-wake-on-lan-rk3568-582.html

20:37 <DC-IRC> [Discord] <runaway97> > Testing revealed that Wake-On-LAN is only possible in freeze mode. Observations showed that after entering mem mode, the network LED does not light up; whereas, in freeze mode, the network LED continues to blink normally. This indicates that the PHY (physical layer) is not functioning in mem mode, and therefore, it cannot trigger an interrupt for wake-up.

20:39 <DC-IRC> [Discord] <menu> i thought that would be the case, it only supports *wake*, not power-on

20:39 <DC-IRC> [Discord] <menu> at least i'm not going to continue chasing this to no avail

20:49 <DC-IRC> [Discord] <runaway97> yea so i had a quick look over the schematic

20:49 <DC-IRC> [Discord] <runaway97> the interrupt pin from the PHY does not appear to be connected at all to rk3588

20:50 <DC-IRC> [Discord] <runaway97> the driver also needs to set relevant MAC address and explicitely configure WOL, it does neither of these.

20:50 <DC-IRC> [Discord] <runaway97> so it's just a limitation of the opi 5 board

20:50 <DC-IRC> [Discord] <runaway97> the PHY driver also needs to set relevant MAC address and explicitely configure WOL, it does neither of these.

20:51 <DC-IRC> [Discord] <runaway97> lol they only had to route a single wire. soo crappy design

20:52 <DC-IRC> [Discord] <menu> i figured that would be the case, ty for looking, not even the sort of wire i could add-on, because if they haven't routed it, can guarantee it's not exposed *anywhere* on the board

21:11 <DC-IRC> [Discord] <runaway97> well it is pulled up high with a resistor on phy chip side

21:12 <DC-IRC> [Discord] <runaway97> the tricky part is finding the SoC wire. that may not be exposed indeed

21:13 <DC-IRC> [Discord] <menu> i should just use a smart socket shouldn't i

21:18 <DC-IRC> [Discord] <tussockybison54> How can i report a scammer?

21:19 <DC-IRC> [Discord] <tussockybison54> A guy messaged me in dm and he belongs to this chat

21:20 <TheSHADOW> Hi, um, did apt upgrade on my test install and it now fails to boot. Looks like it's looking for a btrfs root volume??

21:21 <TheSHADOW> Orange Pi 5, updated kernel to 6.1.75...

21:44 <DC-IRC> [Discord] <igorpec> TheShadow: probably this https://forum.armbian.com/topic/46601-2484-latest-apt-upgrade-breaks-multiple-things-including-the-gnome-desktop/#comment-204829

21:44 <TheSHADOW> TY

21:44 <TheSHADOW> I saw that though I wasn't sure it was related.

21:47 <TheSHADOW> Got to figure out how to incorporate that patch before doing an update...

21:49 <TheSHADOW> So I guess "Rock 5 ITX" is more important than Orange Pi 5. :-P