Updated 2 of my servers from 6.12.3 to 6.12.4 yesterday morning with no issues. Been stable for just over 24hrs now 🙂 thanks guys!

Update: Updated 3 of 3 servers  / 2 of the 3 were perfect but 1 had small issue.

 

UPDATED: So the 6.12.2 server had some minor issues with the upgrade.  I had 2 network connections (I was using 2.5usb) and 1g on motherboard.  After the upgrade, it went back the 1g.  I needed to move ethernet cable, reboot, load the realtek RTL8156 Drivers again (but before upgrading, checked that there was no newer version).  Then reboot and move the ethernet in network settings and I was ok.   

The smallest of things can cause issues.

 

 

I have 3 servers that I will update tonight or tomorrow.  After reading some comments in this thread, I am slightly nervous with the people that said they lost there docker containers.   Using 6.12.3 on 2 servers and 6.12.2 on the other one.  Never had any problems with upgrading other than it would choose the wrong network adapter which was easily remedied.   With the previous updates, I followed all the steps, but never saw a comment "Lost all my dockers" that I see in this thread so wish me luck.  And if there are problems, hopefully someone here can point me in right direction.  I will report back once done, unless someone does not think I should do the upgrade yet.

Edited September 3, 20232 yr by GeorgeJetson20
updated notes

3 hours ago, ConnerVT said:

 

Not 6.12.x specific, but I have had similar experiences with my server when rebooting, so now I try to power down instead when it is necessary.  Likely not happening for the same reason for both of us, but thought I'd throw it out there as another data point.

Strange and interesting.  Thanks for the data point.  In my case, this never happened until 6.12.x though.

Issues with custom IPVLANL3 Docker network after the upgrade.

All my dockers run on a custom IPVLANL3 network after the up grade none of the dockers will

start and produce this error in the log “failed to create the ipvlan port: device or resource busy”

 

The custom network is present and all dockers are assigned to it.

If I roll back everything works correctly as it always has

 

root@NAS1:~# docker network ls
NETWORK ID     NAME        DRIVER    SCOPE
c672eff05a16   bridge      bridge    local
3bbd8bb2ae5c   host        host      local
de7e521a4485   ipvlan-l3   ipvlan    local
f6fe78a2336c   none        null      local

nas1-diagnostics-20230901-2323.zip

I reverted my custom ipvlan network back to macvlan and adjusted each container appropriately...I wish the UI would *always* remember the IP address that I end up typing in over and over when I change the network types...

 

I'll be watching this to see what the conflict is with ipvlan.  I have an idea what it is but I didn't dig too deep.

 

Kev.

Updated fine for me.

 

Hi,

 

Upgraded from 6.12.3 and having issues with my dockers using custom ipv6 addresses. I'm getting this error:

 

docker: Error response from daemon: user specified IP address is supported only when connecting to networks with user configured subnets.

 

 

These are the settings which worked fine on 16.12.3:

 

 

docker run
  -d
  --name='binhex-sabnzbd'
  --net='br0'
  --ip='192.168.93.193'
  --ip6='2a02:restofip'
  -e TZ="Europe/London"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="tower"
  -e HOST_CONTAINERNAME="binhex-sabnzbd"
  -e 'TCP_PORT_8080'='8080'
  -e 'TCP_PORT_8090'='9090'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8080]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/sabnzbd-icon.png'
  -v '/mnt/disks/WDC_1TB_BLACK/Sab':'/land':'rw,slave'
  -v '/mnt/cache/appdata/sab/':'/config':'rw' 'binhex/arch-sabnzbd:latest'

366a3580aae5540d218ef2281456d083994bf8f7998a1cb51b05e378cd705ad6
docker: Error response from daemon: user specified IP address is supported only when connecting to networks with user configured subnets.

 

 

Am I missing something? Going to have to roll back for now. If i remove the specified IPv6 Address it works fine.

 

Thanks,

Daniel

 

Edited September 2, 20232 yr by dan91

18 hours ago, ljm42 said:

Upgrade first

 

Does this require two Reboots then or can I upgrade with Autostart disabled, change the settings and then start the Array. Would this Work?

Upgraded without major issue. Not a big deal as I don’t use bonds or bridges anymore and all my dockers are on my secondary network interface and unraid on primary. I moved as things were unstable and now they are I CBF reverting back. Don’t really notice the speed loss due bond. 
 

My only gripe is that the upgrade caused a Parity Check. Shutdown wasn’t unclean as I was observing it. Shame, as my scheduled monthly only finished yesterday. 

Edited September 2, 20232 yr by danioj

23 minutes ago, danioj said:

Shutdown wasn’t unclean as I was observing it.

You can only be sure that it was not unclean if you successfully stopped the array before shutdown.

Finally upgraded form 6.11.5 after having to rollback from upgrading to 6.12.3 and having issues with my 11th gen Intel system, this time everything went well, no issues, all good.

1 hour ago, itimpi said:

You can only be sure that it was not unclean if you successfully stopped the array before shutdown.

I know what you’re saying but honestly the reset happened in a matter of seconds ie the timeouts for unmounting / shutting down services that drive an unclean shutdown were not exceeded. I’m not aware of a scenario where services shutdown and drives are unmounted so quickly that still causes a unraid to think a parity check is still required on reboot? Happy to be educated though. 

When the array has been successfully stopped then Unraid normally writes this to the flash drive.   Either the stop or the write must have failed.

 

Having the syslog server enabled with mirror to flash options set to get a syslog that survives a reboot should allow confirmation of what went wrong if it happens again.

Hey guys, i just updated to 6.12.4 and was previously using ipvlan after some call traces with macvlan. I also have a bunch of dockers with custom: br0 network, so bridging was enabled. 

I updated now and disabled brdiging as per the release notes and started docker, but now my dockers wont start anymore. I have also read, that this can happen and i simply have to change to "custom: eth0", but that network does not exist. So i am unable to start my dockers now. What am i supposed to do? I want to switch back from ipvlan, because i had some issues with it, which is also documented in the release notes

I will add the GUI/scripts do not present the bond0/eth0 custom option it seems under some circumstances...for me, it was due to the presence of my custom ipvlan network.  That is expected behavior, but upon deleteion of the custom network, they should show with all the network/docker settings set appropriately.  They however do not.  I'm investigating...

Just updated from 6.11.3 to 6.12.4 and so far so good!

Previously plagued by crashing problems on 6.11.3, that always happened minutes after the appdata backup service would run successfully. When I heard news that it was related to macvlan, I changed over to ipvlan and it solved my crashing problem with an uptime of over 7 months after that. Now looking forward to learning ZFS.

 

Keep up the good work unraid team!

Ok guys, something aint right. I re-enabled bridging, but no luck. br0 is gone aswell now. Then i rolled back to 6.12.3 and i cant get br0 now there aswell

Something bricked now, i have no idea what is going on

 

Edit: It was ipv6 all along. I have no idea what happened, but the update borked my docker ipv6 settings and made unraid/docker unable to create any custom network interface

 

Edited September 2, 20232 yr by Joly0

On 9/1/2023 at 2:32 AM, Ollebro said:

Updated from Version: 6.12.3 to Version: 6.12.4 and lost all my docker containers. Any tips on how to get them back?

Did you figure out what happened/how to fix it?

Minor bug on 6.12.4 ? I perform read check ( no parity ) on array, it report duration 9hr+ but actually finish within an hour.

 

 

 

Edited September 3, 20232 yr by Vr2Io

2 hours ago, Vr2Io said:

Minor bug on 6.12.4 ? I perform read check ( no parity ) on array, it report duration 9hr+ but actually finish within an hour.

 

 

 

Did you create a bug report in stable section?

upgraded from 6.12.3

- reboot triggered a parity check (unclean shutdown detected)

- custom docker network interface changed from bro to br2. I stopped docker to revert to br0 as eth0 is a 10GB interface.

My server was not subject to call traces with macvlan.

For now it runs smooth.

upgraded from 6.12.3

- reboot triggered also a parity check (unclean shutdown detected)

 

but works stable and well as 6.12.3 in my case

-faxxe

 

Upgraded my two servers from 6.12.3 to 6.12.4 and so far so good.

 

I wasn't getting any call traces or crashes with macvlan on a custom network through br0 but I still went ahead and disabled bridge on all interfaces. I hope the macvtap will be faster than the old bridged network.  

After upgrade from 6.11.5 to 6.12.4 where can I see that everything is configured correct? I don't see IPVLAN, MACVLAN or MACVTAB anywhere within the settings:

 

 

 

CLI shows that - but shouldn't there be MACVTAB somewhere?

 

root@Tower:~# docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
8adcdd141eb5   bond0     macvlan   local
d0d7de380f93   bridge    bridge    local
bf554ebaaab7   host      host      local
68626f6bf303   none      null      local

 

Thanks in advance.

 

Edited September 4, 20232 yr by hawihoney

Hi everyone!
Update from 6.11.5 to 6.12.4.
No problems so far. (15min up time only ^^)

All my dockers work, including those behind a VPN.

Just "Fix Common Problems" reporting "macvlan call traces found".
My system has 2 network onboard motherboard. (1G + 2.5G) Only 2.5G unsed.

What do you recommend?

Should I switch to ipvlan? Or stay with macvlan?