MAM59

The messages are gone now ? ? ? strange... (BTW, DMZ sounds more what you want. The ISP Router just hands over all "real" packets to the ASUS things but keeps away status and control packets (that seem to confuse your computers) from the ISP. "Bridge Mode" is mostly used for "I want to share my line with my neighbor". Really rarely used and disabled by most ISPs. So it is quite an uncommon setup to me. But if it works ok, who cares?)

Smaller files always will be slower because it takes the same time to update directories and so on for all sizes. For a single 100G file this time is only needed once, but for 10000 100k files it takes 10000 times. This sums up really badly. The LAN needs to be pessimistic, it has to wait until the file is handled completely before it can move on to the next one. This is partly untrue for local disks because OS' make use of a "write cache" in RAM. This saves unnecessary writes to the disks with the risk of a file system corruption if a power outage happens. So it is a risky and delicate thing. LANs are very conservative because there is no way to recover or to know how the other box is currently doing. So, there is nothing you can do.

Hmm, still strange why it happens... I am wondering what you mean with "in bridge mode" ? Usually the box from the ISP is just a modem und put in front of your own router. But there is also a "bridge mode" where the ISP box does NOTHING but passes the whole line to the user's router. This would include the DHCPV6 request announcement (in normal mode this would be supressed, only the ISP Box gets an address and just passes on the prefix). So your local router will ask (and get) another address. But these bridge mode addresses are limited usually only ONE is given out. If your local router (which does not seem to be very bright in respect to IPV6) just passes on the announcements unmodified to the LAN, local computers like UNRAID also would try to get an address from the ISP but fail because the pool of TWO (one for the ISP Box, one for your Router) is already exhausted. You may try to turn off "bridge mode" and use the normal mode instead. Maybe the mystical requests will silently disappear... (People often mix up "Bridge Mode" with "DMZ Host". The first passed the line completely, the latter just turns off the firewall of the ISP Box and passes on all packets to the User's Router. The outcome looks the same, but the internals are different)

as I already said: Don't worry, it does not mean a thing. So, if everything else works: FORGET IT 🥰

I've read through the manual of your "router", it seems to be focussed on IPV4, Gaming and WLAN. There is very little about IPV6, you just can enable it (its not shown what happens then) and there is a very basic firewall for V6 which by default blocks everything. I guess it just passes on what your ISP offers you. Of course, if the connection is "borked" this may result into serious timeouts. So you better ask them what is going on, your devices do not offer much info here. But UNRAID seems to be a poor victim, nothing you can do here to fix it. Call your ISP, maybe you even need to turn off IPV6 in your router completely to protect your devices from unstable connections. (this should NOT be needed normally, but you can give it a try)

Guter Tip, obwohl Intel es mit der original Einstellung eigentlich richtig macht. Das sind 10G Karten und physikalisch gibt es keine 2,5 oder 5G Übertragung. Das ist dann immer "10G mit Pausen". Insofern ist es korrekt, wenn HighEnd Karten die Krüppelmodi gar nicht anbieten. (jaja ich weis, es ist müssig darüber zu diskutieren, 2,5G ist eben ein Abfallprodukt und wird gehyped)

my idea would be a wrong configuration in your router. Usually Routers tell their clients which methods they should use to get V6 addresses / infos. DHCPV6 is OFF by default because it is rarely used anymore. But if the router raises bit8 in the flag byte of his periodical "router announciation packet", the clients start to ask for DHCP. This even happens if you set V6 addresses to "manual" in UNRAID, there is no way on UNRAID to prevent it (neither on other OSs'). Look into your router, the flag is 0x80, often called "O" too, or, of course DHCP(V6). But then, this should not have any influence on the speed of the GUI. Jan 25 23:43:28 Blackfox rc.inet1: timeout 60 dhcpcd -w -q -n -p -t 10 -h Blackfox -C resolv.conf -6 br0 Jan 25 23:43:28 Blackfox dhcpcd[1400]: dhcpcd-10.0.10 starting Jan 25 23:43:28 Blackfox dhcpcd[1403]: DUID 00:01:00:01:XXXX:XXXX:XXXX:80:0c:9d:92:84:59:3e Jan 25 23:43:28 Blackfox dhcpcd[1403]: br0: IAID 92:84:59:3e Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: soliciting an IPv6 router Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: Router Advertisement from fe80::6d9:f5ff:feb3:89b0 Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: adding address 2001:14ba:4acb:1300:XXXX:XXXX:XXXX:593e/64 Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: adding route to 2001:14ba:4acb:1300::/64 Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: requesting DHCPv6 information Jan 25 23:43:29 Blackfox dhcpcd[1403]: br0: adding default route via fe80::6d9:f5ff:feb3:89b0 Jan 25 23:43:30 Blackfox dhcpcd[1403]: br0: REPLY6 received from fe80::6d9:f5ff:feb3:89b0 Jan 25 23:43:30 Blackfox dhcpcd[1403]: br0: refresh in 86400 seconds As you can see, you already have got an address assigned (2001:14ba:4acb:1300:XXXX:XXXX:XXXX:593e/64) via SLAAC method. But the router at fe80::6d9:f5ff:feb3:89b0 tells UNRAID to ask for an additional address with DHCPv6. A harmless misconfiguration.

Also ich würd mal crontab=0 */2 * * * als crontab="0 */2 * * *" schreiben. Die "*" werden die Shell doch irgendwie stören, nehme ich an. Alternativ mal crontab=0 \*/2 \* \* \* oder crontab='0 */2 * * *' probieren (ansonsten heißt das schon "Minute 0, alle 2 Stunden")

usually the ASUS Mobos have an USB Device for the LEDs. You need to pass it on to your Docker. Worked here for some years, suddenly stopped working but since LEDs are not really critical, I did not investigate and deleted everything that had to do with LED stuff... Cant look it up anymore.

Hmm, strange. Unless you have a watchdog in your BIOS/UEFI somewhere I dont know any setting in Unraid that lets the box sleep completely (if you find one, tell me, would gladly use it overnight 🙂 )

sounds like the normal disk standby to save energy. Look under disk settings if you want to turn it off. What is the problem with it? Usally the people are glad that it works.

just searched the web a bit.... Your board really seems to be picky with secure boot & Co (has nothing to do with UNRAID). Maybe you should read some comments on Reddit and so on and get more info how to get it to work. First start seems to be to clear cmos and start all over. maybe this can help ? https://www.asrock.com/support/faq.de.asp?id=531

and?

Ok, stomach full (brain not. lol)... Lets start the other way round, maybe the machine is too old for current UEFI. (There is currently a switch going on, BIOS older than 6 months may not work anymore). * turn off secure boot (the "EFI" Folder is not used then anymore) completely * turn on CSM with booting from legacy devices * use an USB-2 port for the stick (this is mainly to save electricity and to keep it cool. It will live longer this way) * try to boot from the stick

breakfast time... will be back later...

UEFI needs Secure Boot to be turned on. Is the stick shown in Bios? Some Boards have additional USB ports that are not allowed for booting. The stick should show up and usually there are also "boot overwrite" settings that allow you to boot from the stick manually (just for testing until you get the correct settings).

Ok, so EFI is already activated. Look into your BIOS settings for "Secure Boot". Should NOT be set to "Windows" but to "other operating systems". (Sometimes you also need to play around with CMS or something alike. Sadly all BIOS' are different, no way to tell the exact topics for your device)

I guess you need to enable UEFI boot This needs to be enabled on the Stick. Put the stick into a windows computer or something. In the main directory you will find a folder called "EFI-" rename this folder to "EFI" (without "-") This should allow you to boot in your target machine. Try it out.

"Von nix kommt nix", wie der Latriner sagt... Es ist IMMER so. Die benötigte Leistung steigt quadratisch mit der Frequenz. Ob das effizient ist, steht auf einem anderen Blatt (auch ein höherer Verbrauch kann letztendlich effizienter sein, die Rechnung ist komplizierter als Milchkannen zählen). Also, entweder abschalten oder aufhören zu Grübeln. Auch ein Treiberupdate wird nicht helfen, Ethernet verwendet NRZ (no return to zero) Übertragung. Auch wenn DU nix überträgst, auf der Leitung tut sich trotzdem was. Es gibt seit 1G keinen Ruhezustand mehr. ("Green Ethernet" schaltete runter auf 100M, das war die letzte Version mit "Ruhe")

try to clear the browser's cache with CTRL-F5 or something Also, click on "full screen", the GUI needs full 1920x1080 size to show all columns

As I said, this error happened long ago and was covered by a symlink. Maybe even before V6 already, I cannot check anymore.

No! the change was from emhttpd to emhttp !!!

Solved! Maybe I should summerize to warn potential users: If updating from a very old (not clear how old, better check always) to 7.0 take a look into the /boot/config/go file before! if it contains a line like /usr/local/bin/emhttpd & change it to /usr/local/sbin/emhttp before. (if you forget the unraid management stuff may not be started after the update. you can ssh in and start it manually by running /usr/local/sbin/emhttp but correct the go file then to prevent further problems)

but I have managed to find the differences that Limetech forgot to update: * /usr/local/bin/emhttpd has been moved to /usr/libexec/unraid/emhttpd * the 7.0 "go" file is NOT updated. The new startscript seems to be now /usr/local/sbin/emhttp (without the leading "d") This is a really stupid mistake, if you move files (which is stupid by itself already, thats why I hate Linux that much), you should also look for and update all references. A normal user has no chance to find this error. Maybe I am able to correct it... I will give it another try now (brrrrr, cccccooooooold...) Hmm, I just see, that /usr/local/sbin stuff is on 6.12.14 too already. But the link in go has never been updated. So the bug must have happened a few versions before already and did not show up because there was a symlink.... LINUX!!!

not possible, even the basic linux does not work correctly