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