bedna

I see. I actually tried to educate myself to see if I could help out, that is why I extracted the code in the first place. I would love to be able to help, but it seems outside of my capabilities. But I'll keep reading trying to learn, and maybe some day I will be able to make a pr rather than just a post on the forum. Thank you AGAIN for ALL you do!!

Maybe you already know, but to be sure (you guys are most likely always swamped), the keyrings workflow has failed the last two runs with the same error, on April 8 & April 15... https://github.com/armbian/armbian.github.io/actions/workflows/generate-keyring-data.yaml ERROR: Unable to find debian-archive-keyring package URL from https://packages.debian.org/sid/all/debian-archive-keyring/download Thanks for all you do! Edit With the limited understanding I have of this, I extracted relevant code and just ran a check on my local machine, and it returned: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3012 100 3012 0 0 509 0 00:05 00:05 509 Debian debian-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2025.1_all.deb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3021 100 3021 0 0 532 0 00:05 00:05 532 Debian debian-ports-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2026.02.04_all.deb (the reason it took 5s was due to the time it took me to press "allow" on the outgoing curl connection in my firewall) So maybe it was just a fluke, and it was just really unlucky failing resolving to packages.debian.org instead of ftp.debian.org those two times. Idk, just wanted to make sure everything was correctly configured. Ignore this if all is ok.

@MMGen First, thanks for a great tutorial! I have a question about gpt. I maintain shrink-backup and I use dd to copy "boot sector" and rsync the rest (VERY easily described) But I do not distinguish any difference between if it's mbr or gpt when using dd, I just copy everything before root partition with dd (and a few MiB extra) then format root, rsync, yadayadayada... (not important) So I got curious why you skip the first 64 512b blocks in the dd for gpt? (for others reading, the 512 is because fdisk ALWAYS returns 512b blocks, even though gpt is actually 4k blocks) dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704 Can you explain why? I tried to find something online referencing the first 64 512b blocks of a gpt partition table, but could not find anything. I would really appreciate you educating me, or some links where I can read up on the reason. Thank you!

It's most likely a local ipv6 op is talking about, not a public. ipv6 in range fe80::/10 is local only. To remove ipv6 in that regard, ipv6 has to be disabled on the device or it will get an address like that. And according to what is provided: 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether be:63:9c:35:dd:4f brd ff:ff:ff:ff:ff:ff inet 192.168.71.2/24 brd 192.168.71.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::bc63:9cff:fe35:dd4f/64 scope link valid_lft forever preferred_lft forever Today I learned a bit more about systemd-resolved, seems 127.0.0.53 IS the correct config for systemd-resolved: https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53 And: If dhcp server is configured correctly, nothing has to be done on the devices (except resolving domains to local ip unless that is done on the LAN by dnsmasq)

I'm sorry but, lmao, this is entertaining to read. The sd card is OBVIOUSLY corrupt, it even TELLS YOU THAT in what you posted. It's probably a good idea to go back to the basics and learn linux properly if you don't know what a msdos (MBR) partition table is. https://unix.stackexchange.com/questions/289389/what-are-the-differences-between-the-various-partition-tables As for how to NORMALLY SETUP A NETWORK, you can read my earlier responses, no host files on the devices, no hardcoded ip, just a correctly configured dhcp server that delivers the CORRECT IP:s to all devices. Then the dns server on the network (dnsmaq in this case) resolves desired domains to local ip:s. That way, there is NO NEED to do ANY CONFIG on the devices, it is all done on the entire network.

You are telling me to forget the thing I suspect is the reason for the network not working correctly...? If it is "working perfectly", why does it not resolve addresses from the bpi? Why is your bpi setting 127.0.0.53 (witch would be incorrect even if you ran a dns server ON that device, it should then be 127.0.0.1 (or the device ip), potentially at port 53 but IIRC, port 53 IS dns requests and where it will go without defining it) as dns server and not 192.168.71.1? There you go, there is another culprit. If writing 4k in each iteration fails, but 512 works, 99,99% chance the reason is the sd card is starting to completely fail. Armbian imager would have told you verification failed when verifying the image after writing it, there is zero verification when using dd. There should be no issue writing 4096 bytes (4k) each iteration with dd on a functioning sd-card. Seems you are more interested in screaming and complaining than actually getting to the bottom of it all and set it up like a NORMAL network where NOTHING has to be done on the devices because the settings will be configured correctly with the dhcp lease. Btw, here is the dev documentation for armbian imager (and the source code ofc), took me 30 seconds to find... https://github.com/armbian/imager/blob/main/DEVELOPMENT.md Not sure what useful things you expect to find in there that is not mentioned in the help. It writes an image and does verification of that image (and you can download images), that's it. Good luck I guess, I have nothing further to add.

Does it? Does not look like 192.168.71.1 to me... And: That is not correct, that is the global scope, no ip can end with 0. Ehhh... What do you call dnsmasq on your router then?!? If you don't "maintain" that, yes, things like this can happen, especially since you have set the leases to never expire. I have no idea if this is the case, it's for YOU as sysadmin of your network to know. Nobody knows what you did after install. All that is known after all things written in this thread: You have a dhcp server you have a dns server (dnsmasq) you installed Armbian_26.2.1_Bananapim5_noble_current_6.18.15_xfce_desktop.img (that comes with network manager according to documentation) It seems you have systemd-networkd enabled Unless you can prove the default config was with both systemd AND network manager, YOU have made changes that breaks the installation. Nobody can answer what you did, only you. The normal way if having a local dns server (even if it ONLY forwards request to outside dns server) is to configure the resolving for local domains in the dns server and not touch it at device level. For example a consumer grade router, it will set dns to router ip in the dhcp lease and when requests come in, resolve with asking your ISP dns servers. Hence, if looking up what dns server is used on the devices, they will NOT point to your ISP dns servers (or google or cloudflare etc), it will point to your router ip. Lets say you have a pihole on your network that acts as dns server, then you configure the router (dhcp server) to point to THAT ip for dns, hence, the dhcp lease will deliver THAT ip. And then you configure the pihole to resolve local ip:s and what outside dns servers to use. The DEVICES will ONLY see the local ip where the pihole lives in this situation. Resolving domains to local ip:s (/etc/hosts on your device) has nothing to do with your dns detection failing. This is all pretty basic networking... Edit For reference, this is what your /etc/resolve.conf should look like (or similar) if you configure your dhcp server to point at the ip where dnsmaq lives (same ip as the router itself) then propagate those settings via the dhcp lease. Then nothing has to be done on any device except for resolving local ip:s if you refuse to do that with dnsmasq. If you configure dnsmasq to do that, resolving will be done on the router instead of the devices and absolutely nothing has to be done on any device. With systemd: # Generated by resolvconf domain home nameserver 192.168.71.1 With network manager: # Generated by NetworkManager search home nameserver 192.168.71.1 If you don't want to reinstall again, make sure systemd network services are disabled and network manager is enabled and then reboot. But be mindfull you might need physical access if network completely fails at boot. IIRC relevant services are (I could be wrong here, you should read up on documentation) systemd_networkd.service, systemd_resolved.service & networkmanager.service I'm in the middle of moving, so I only have an arch desktop and laptop up and running at the moment, so I can not confirm on any armbian installation that I provide 100% accurate information.

That is supposed to be using network manager, again, see documentation Your question was about networking. How to configure your raid is a completely different question and has nothing to do with network. Since both systemd-networkd AND network manager (and you also mention dnsmasq) is enabled, you have most likely done changes to the system way outside of what you should. If you claim the image you downloaded CAME with all that installed and enabled by default, I would suggest you provide proof of that and then report back as a bug. As for your general network setup, I gave you my opinion earlier: Not on every specific device if there is a local dns server available on the network. Then it's normally done on the local dns itself by first checking local configs (like /etc/hosts) and if not available, resolve using online dns servers and then send the response to the device. And the dhcp server is obv configured to point to the local dns server. That way the configs gets propagated via the dhcp lease to all devices on the network.

If you want to use network manager you have to make sure systemd is not overriding your configs, ie disable relevant systemd services. To me, it sounds easier to just use what is installed default, in this case systemd and use networkctl to interact. But it should be irrelevant. If you configure your dhcp server and dns server correctly, both systemd and network manager should pick up correct config in default config state so you should not even have to interact with either of them. (I started assuming you are using a minimal image, therefore systemd as default. You haven't disclosed what version you use, just something 26.3)

Either the config on the device is wrong, there is supposed to be a dns ON the device or the dhcp server is handing out wrong dns to the device. Not on every specific device if there is a local dns server available on the network. Then it's normally done on the local dns itself by first checking local configs (like /etc/hosts) and if not available, resolve using online dns servers and then send the response to the device. And the dhcp server is obv configured to point to the local dns server. That way the configs gets propagated via the dhcp lease to all devices on the network. Edit As far as I know, network manager is default on armbian (correct me if I'm wrong) and that should have edited your /etc/resolv.conf. So since it's not, you have made changes outside of default config somehow. Could be that the specific release and device you use does not utilize network manager. But since you have not disclosed that info, hard to know. But it looks like you use systemd-resolved so you should check how that works. Edit2 I was wrong about network manager, see https://docs.armbian.com/User-Guide_Networking/

I repeat, what is in your /etc/resolv.conf?

What's in your /etc/resolv.conf? And what do you mean with "dhcp isn't working"? Is 192.168.71.2 not the correct ip? Where is your dhcp? Your router?

I haven't used samba for a long time so I'm probably not the best to ask, but I checked my old notes about samba, and this was my goto config: [samba] # edit, or whatever name you want to give it path = /path/to/mountlocation/ browsable = yes writable = yes read only = no force user = <your_username> force group = <your_usergroup> create mask = 0644 # edit, you should probably set this to 0640. This is for files, no need for 7 here, unless you want every file to be executable on the samba share? direcotry mask = 0755 # make sure this works on debian, errors on arch (edit, this was in my notes, so I guess 755 instead of 0755.. maybe.. Or rather 0750 or 750 to only give access to your user and group) public = no This was the only thing I changed from default IIRC, so no guest access or anything, just a uname and passwd to connect. Changing the directory permissions on the server filesystem (chmod) does not matter at all when it comes to samba. As you can see in the conf I provided, the mask is defined there, and all files will get that user/mask (if ext4, exfat does not support user/group/all masks, what you see in your filesystem is what you set in fstab for exfat) and is the mask you will se when looking through a samba mount on another computer. And as a rule of thumb, don't use 777 or 666, the solution is very rarely to completely open up everything, that's a "windows thing" (run as administrator or give everybody access to the directory/application), try to get rid of that habit.

Samba has one gazillion options, you can read about all of them here: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html You can read the wiki with examples here: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Standalone_Server I would NOT use a samba server without a password.

Also: # apt install -y iptables # iptables -v iptables v1.8.11 (nftables): no command specified https://wiki.debian.org/nftables AFAIK using iptables syntax should still work, but nft is what you probably should learn to use instead. https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

It really is as simple as possible on Armbian. Pretty good documentation too, I posted it before, but here you go again: https://docs.armbian.com/ All you have to do is to login as root from an ssh client following standards. I do not have access to a windows installation where I can confirm if what you say is true, that the ssh client does not let you login with "ssh root@xxx.xxx.xxx.xxx", so maybe you are correct, but it sounds very unlikely to me. But what I can guarantee is using an ssh client from another unix system will definitely let you connect. So use a mac or a linux computer to access. Or install wsl on windows and do it from there. https://learn.microsoft.com/en-us/windows/wsl/install Edit: I actually forgot, but I had putty installed on my system. I used it to check colors in a script I maintain and it exists in the extras repo on arch. Downloaded latest minimal image for rpi (so not same hardware as you) and... No settings changed in putty, just a standard root@192.168.99.60 that I added into the "Host Name (or IP address)" field and clicked "open". Name : putty Version : 0.83-1 So I don't know what to tell you...

"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 -vv root@xyz" Let's try again, but this will be my last time typing this: The normal way to use ssh, is to type: "ssh user@xxx.xxx.xxx.xxx" where x is the ip number. So for Armbian first login, it's "ssh root@xxx.xxx.xxx.xxx", NOTHING ELSE. Just glancing at the few first lines in that log: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2 debug2: resolve_canonicalize: hostname xyz is address debug1: Connecting to xyz [xyz] port 22. debug1: Connection established. debug1: identity file C:\\Users\\sebas/.ssh/id_rsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_rsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519 type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.0 debug1: compat_banner: match: OpenSSH_6.6.0 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to xyz:22 as 'root' debug1: load_hostkeys: fopen C:\\Users\\sebas/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory As I suspected, it looks like it is somehow trying to use keys and whatnot. Since you refuse to listen, yeah, this might be frustrating and "bad for morale". If you instead listen and do what is suggested, your morale would likely not suffer at all.

Stop providing false information, I disproved your theory earlier, please stop. On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian. This works, and is the way I have ALWAYS done it on Armbian, for years. Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234." If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

Might be because at first login, you enter 1234, it then asks for you to change that, create a user and whatnot. Not so sure putty will have any idea of what to do with those prompts. When you wrote: "once more: tried ssh through a raspi in the network. the raspi cannot connect to the armbian:" What do you mean by that? You logged in to a rpi OS with putty, and you then tried to connect to this device via the rpi? Was this before or AFTER you already tried logging in to it using putty? In your log: ### [firstrun] Recreated SSH keys (entropy: 256 256) I don't know what this means, but sounds like keys are enrolled and maybe assumed to be used in future. You will have to look into putty (and ask the devs of putty) to learn what is happening, unless you are willing to use a "normal" ssh client that will tell you what is going on by providing STDOUT & STDERR to your monitor. With a NORMAL ssh client, type "ssh root@xxx.xxx.xxx.xxx" (the ip to the device) and it will ask for passw, it will then require you to CHANGE passwd etc. Seems very likely putty has no idea how to deal with that and are doing some strange things at first login, witch then probably leads to it borking your system.

Unless they have changed something very recently, you can login as root via ssh on first-run. I double checked /etc/ssh/sshd_config on an armbian install image I had downloaded, and: # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes <snip> # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no And inside /etc/shadow (default 1234 passwd): root:$y$j9T$SAPCtO/l2ZIj6A2frqTza/$.Z8dP41gzqRHoIS8PvXFn9fghf9rgkGqAWgXVRW4dg6:20234:0:99999:7::: Edit. That can be verified: export PASS=1234 SALT='$y$j9T$SAPCtO/l2ZIj6A2frqTza/$' && perl -le 'print crypt($ENV{PASS}, $ENV{SALT})' # the output verifies the shadow file is correctly setup for passwd 1234 $y$j9T$SAPCtO/l2ZIj6A2frqTza/$.Z8dP41gzqRHoIS8PvXFn9fghf9rgkGqAWgXVRW4dg6 End edit. So that should not be an issue here. (and there are keys inside /etc/ssh that I assume can be used at first login, I have never tried) Sounds more like a faulty sd-card that gets mounted read-only, that can cause stuff like this happening. (as mentioned earlier by Igor) Try with a different sd-card (and use armbian-imager instead of balena) and see if the same happens on another card.

Yeah, don't do that.. At least read "<application> --help" before doing sensitive stuff like that if you are unfamiliar. If that happened to you, and that is the reason you typed that.. For future reference: If you have a root account, you can change to root user with "su root" and enter passwd. You are then root and can add your user back to the groups needed. Or you can use the debian "child safe" way, "adduser <user> <group>" (only works on already existing users and groups) instead of usermod to begin with. But best is you learn usermod, since that will let you utilize that knowledge on pretty much any unix system.

Tried this? https://gist.github.com/c0m4r/b3fea6342bcf5a1b25b608fc36100d68#pwm-fan-control Ie: download the script and systemd service, edit the script to your liking (or try default) and activate the service. As default It configures to user_space and checks temps every 10s. https://raw.githubusercontent.com/c0m4r/radxa_rock5c_lite/refs/heads/main/usr/local/bin/rock5c_fan_pwm ########################################################## # Radxa Rock 5C fan PWM control script # Author: https:///github.com/c0m4r # License: Public Domain ########################################################## # PWM control path PWM_PATH="/sys/devices/platform/pwm-fan/hwmon" # Configuration INTERVAL=10 # Temperature check interval (seconds) FAN_OFF=1 # 1 = turn off fan below MIN_TEMP after cooldown, 0 = keep at min RPM COOLDOWN=300 # time to wait before turning off the fan when FAN_OFF=1 # Critical temp protection POWEROFF_ON_CRIT=1 # 1 = shutdown when the temperature reaches a critical value, 0 = disable CRITICAL_TEMP=70 # Critical temperature (shutdown) # PWM Values (proper) SAFE_PWM_MIN=105 # Safe minimum PWM to keep fan spinning PWM_LOW=125 # 45–50°C (~50% speed) PWM_MID=165 # 50–55°C (~65% speed) PWM_HIGH=200 # 55–60°C (~80% speed) PWM_MAX=255 # >60°C (100% speed) # PWM Values (temporary - use these instead of proper if the fan spins at max all the time) #SAFE_PWM_MIN=50 # Safe minimum PWM to keep fan spinning #PWM_LOW=60 # 45–50°C (~50% speed) #PWM_MID=70 # 50–55°C (~65% speed) #PWM_HIGH=80 # 55–60°C (~80% speed) #PWM_MAX=255 # >60°C (100% speed) # Constants (requires also changes in code) MIN_TEMP=47 # Minimum temperature (PWM_MIN) MAX_TEMP=60 # Maximum temperature (PWM_MAX) # Set thermal policy thermal_zones=$(ls -1 /sys/class/thermal | grep thermal_zone) if [[ "$thermal_zones" ]]; then for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done else echo "No sensors found, check kernel support, setting fan to high for now!" echo $PWM_HIGH > ${PWM_PATH}/hwmon*/pwm1 exit 1 fi # Set PWM_MIN based on FAN_OFF mode if [ "$FAN_OFF" -eq 1 ]; then PWM_MIN=0 # Allow fan to turn off after cooldown else PWM_MIN=$SAFE_PWM_MIN # Keep fan at minimal safe RPM all the time fi # Validate PWM path if [ ! -d "$PWM_PATH" ]; then echo "Error: PWM control file not found: $PWM_PATH" exit 1 fi # Initialize variables current_pwm=$(cat ${PWM_PATH}/hwmon*/pwm1) # Start at current PWM last_high_temp_time=0 # Track last high temp for cooldown echo "Initializing fan at PWM $current_pwm" echo "$current_pwm" > ${PWM_PATH}/hwmon*/pwm1 # Main loop while true; do for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done <snip>

What happens if your start armbian-resize-filesystem.service manually? IE "sudo systemctl start armbian-resize-filesystem.service" and then check the log for the service?

I would use systemd. Depending on what application you are talking about, a simple or oneshot service should do the trick. Read the first two examples in the manual: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Examples Assuming you mean an application started by the system and not your user, select the version that fits your situation, create/edit the file /etc/systemd/system/name_your_service.service with the contents needed, for example: [Unit] Description=Service to start "application" [Service] Type=simple ExecStart=/path/to/application [Install] WantedBy=multi-user.target Then enable the service and reboot. sudo systemctl enable name_your_service.service sudo reboot now You can use "systemctl status name_your_service.service" to see status, or "journalctl -u name_your_service.service" to see logs. You should obv change the name of the service from name_your_service to something fitting. If you want the application to run even earlier at boot, you can change multi-user.target to basic.target instead, but be mindful that if you do that and the application requires for example network to be available, you then also need to add "After=network-online.target". Instead, it's usually better to use "Before" and "After" variables and stay on multi-user.target. Please see manual in link above and https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html for more advanced usage.

LMAO! So... What exactly is your question? Did you try "the mouse & keyboard" and they did not work? I would say you will get basic functionality on almost any usb mouse or keyboard on linux. wifi on the other hand can be a hit or miss. A quick search on "USB Logitech Unifier Nano dongle" gave me this: https://forums.linuxmint.com/viewtopic.php?t=373365 so it seems you might want to use solaar to configure the stuff. As for the Inovato Quadra4K, it looks like it is an allwinner H6 processor so I suspect it should work using armbian....