Update from 6.12.8 failed. The USB stick will not boot anymore. First time I used the new update dialog. USB stick is still readable and I was able to make a backup without read errors.

 

Looking into this now.  Tipps welcome. Thanks!

Edited March 29, 20242 yr by tazman

23 minutes ago, tazman said:

Looking into this now.  Tipps welcome. Thanks!

Re-create the flash drive manually or by using the USB tool, then restore the /config folder from the backup, if it still doesn't boot try a new flash drive.

43 minutes ago, JorgeB said:

Re-create the flash drive manually or by using the USB tool, then restore the /config folder from the backup, if it still doesn't boot try a new flash drive.

Thanks, JorgeB, I copied the root folder files from the 6.12.8 backup to the USB stick and ran make_bootable.bat. Server booted and it looks ok. What to do now with 6.12.9? Should I try the upgrade again from the GUI or is there a better way? USB Tool is the Creator from here? https://unraid.net/getting-started

17 minutes ago, tazman said:

Should I try the upgrade again from the GUI or is there a better way?

I would try again the upgrade, if it doesn't work:

1 hour ago, JorgeB said:

Re-create the flash drive manually or by using the USB tool*, then restore the /config folder from the backup

*with v6.12.9

1 hour ago, JorgeB said:

I would try again the upgrade, if it doesn't work:

*with v6.12.9

Happy to report that the upgrade using Tools.Update OS worked this time. Thanks, JorgeB!

Upgrade went OK but after upgrade I noticed uptime on dashboard and uptime in upper right are different.  

 

Took me a while to start the array (I don't do it automatically). 

Maybe it has always been like this and there is some reasonable reason for the discrepancy in times?  Anyway figured I'd mention it here just for giggles.

 

On 3/26/2024 at 7:55 PM, DivideBy0 said:

I lost my Intel CPU's iGPU quick sync encoding capabilities with 6.12.8 due to the kernel. Will this new kernel (6.1.82) bring it back?

 

On 3/27/2024 at 8:39 AM, ljm42 said:

 

Please let us know!

 

If the problem persists... the only discussions I can find about this issue are buried in a release thread, it would be super helpful to have a separate forum topic that summarizes what we know about it. It is very difficult to follow long running conversations across release threads.

 

Anyone running a 13th gen Intel & W680 board combo that has been able to successfully install this update? Updates after 6.12.4 resulted in loss of iGPU access and reboot hangs. Hoping things are better with this update, but also hoping to hear from others before I try again myself. Still on 6.12.4 at this time.

 

There is a thread here: 

 

Nope still does not work with this update and I still have the ast blacklisted and no kvm.  I am a bit annoyed by this 

On 3/28/2024 at 10:43 PM, ljm42 said:

 

Thanks for linking to this, it is being looked in to

 

Hello,

I would also like to report the same issue as above.

 

Mar 30 03:31:09 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000005aa165ea
Mar 30 03:31:09 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 0000000075e8eda5
Mar 30 03:31:10 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000b887951d
Mar 30 03:31:10 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000005c37aaa9
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000b590034f
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 0000000062194ea4
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000002bfc4cc1
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000b9a86e54
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000004f283bd6
Mar 30 03:31:11 Tower kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000003879e2fc
 

Regards.

 

Anyone having issues with remote NFS shares not mounting because of the "protocol not supported" problem, update UD and a patch will be applied to overecome an issue with an NFS setting we enabled that causes this issue.  UD reverts that setting so these errors do not occur.  It isn't an issue with Unraid to Unraid connections with NFS, it seems to only affect other server devices that don't behave the same way as Unraid.

Has anyone lost docker containers after updating to this version? I saw something on reddit about it. 

Update went fine for me. No data or containers lost.

From 6.12.8 absolutely smooth update.

Nothing huge but on both servers if I try to access "System Drivers" under tools it won't open, I reverted to 6.12.8 & it opens without an issue. Now back again to 6.12.9 on both of my servers & it gets stuck on loading.

 

I clicked on it by mistake while trying to open system devices & I do not care if it works or not, just a note to fix for next update if is the same issue exists for other users.

21 minutes ago, PSYCHOPATHiO said:

Nothing huge but on both servers if I try to access "System Drivers" under tools it won't open, I reverted to 6.12.8 & it opens without an issue. Now back again to 6.12.9 on both of my servers & it gets stuck on loading.

 

I clicked on it by mistake while trying to open system devices & I do not care if it works or not, just a note to fix for next update if is the same issue exists for other users.

Just read this and thought, huh, let me try. So i did.

I have the same result.

41 minutes ago, PSYCHOPATHiO said:

Nothing huge but on both servers if I try to access "System Drivers" under tools it won't open, I reverted to 6.12.8 & it opens without an issue. Now back again to 6.12.9 on both of my servers & it gets stuck on loading.

 

I clicked on it by mistake while trying to open system devices & I do not care if it works or not, just a note to fix for next update if is the same issue exists for other users.

 

19 minutes ago, wirenut said:

Just read this and thought, huh, let me try. So i did.

I have the same result.

 

Thanks, we're looking into it

15 minutes ago, ljm42 said:

Thanks, we're looking into it

When i click on it, it sits on the Unraid wave and appears to be hung.

I decided to update and things went OK so far. 

I updated my nine unRAID setups on Wednesday last week. That use HP Gen7 Microservers. They all upgraded to v6.12.9 without any issues.

i updated and i had around 5-6 Watt more idle consumption.

then i rolled back to .8 and still have 2 Watt more than before. 😞

 

tomorrow i restore the stick config, but i dont know why .9 needs so much more power in idle. 

On 3/29/2024 at 5:07 PM, mrhanderson said:

 

 

Anyone running a 13th gen Intel & W680 board combo that has been able to successfully install this update? Updates after 6.12.4 resulted in loss of iGPU access and reboot hangs. Hoping things are better with this update, but also hoping to hear from others before I try again myself. Still on 6.12.4 at this time.

 

There is a thread here: 

 

I updated my 12th gen Intel and WS W680M-ACE SE server to 6.12.9 today and had the same results with the iGPU not working and system hangs as with 6.12.8.  Blacklisting AST works but I need the remote KVM more than the iGPU for now.  Left iGPU disabled in BIOS.  I also updated to the latest BIOS (3401) and no difference.    

Updating from 6.12.8 to 6.12.9

Stuck on "retry unmounting user shares"

umount /var/lib/docker

Did not work 😞

 

root@thebox:/mnt/user/dockers# mount
rootfs on / type rootfs (rw,size=32899532k,nr_inodes=8224883,inode64)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k,mode=755,inode64)
/dev/sda1 on /boot type vfat (rw,noatime,nodiratime,fmask=0177,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,flush,errors=remount-ro)
/boot/bzmodules on /lib type squashfs (ro,relatime,errors=continue)
overlay on /lib type overlay (rw,relatime,lowerdir=/lib,upperdir=/var/local/overlay/lib,workdir=/var/local/overlay-work/lib)
/boot/bzfirmware on /usr type squashfs (ro,relatime,errors=continue)
overlay on /usr type overlay (rw,relatime,lowerdir=/usr,upperdir=/var/local/overlay/usr,workdir=/var/local/overlay-work/usr)
devtmpfs on /dev type devtmpfs (rw,relatime,size=8192k,nr_inodes=8224883,mode=755,inode64)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
hugetlbfs on /hugetlbfs type hugetlbfs (rw,relatime,pagesize=2M)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /var/log type tmpfs (rw,relatime,size=131072k,mode=755,inode64)
rootfs on /mnt type rootfs (rw,size=32899532k,nr_inodes=8224883,inode64)
/dev/md1p1 on /mnt/disk1 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md2p1 on /mnt/disk2 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md3p1 on /mnt/disk3 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md4p1 on /mnt/disk4 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md5p1 on /mnt/disk5 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md6p1 on /mnt/disk6 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md7p1 on /mnt/disk7 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md8p1 on /mnt/disk8 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sdj1 on /mnt/cache type btrfs (rw,noatime,discard=async,space_cache=v2,subvolid=5,subvol=/)
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=6583272k,nr_inodes=1645818,mode=700,inode64)

 

-edit-

Rebooted manually. Stopped array again, worked this time. Updating went without any issues after that

Edited April 2, 20242 yr by Tuumke

I do seem to have some issues with a Satisfactory server running in a docker container. Should i be worried if my syslog is full of:

 

Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(vethd83e8ba) entered disabled state
Apr  2 07:38:52 thebox kernel: device vethd83e8ba left promiscuous mode
Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(vethd83e8ba) entered disabled state
Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered blocking state
Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered disabled state
Apr  2 07:38:52 thebox kernel: device veth0a65a1f entered promiscuous mode
Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered blocking state
Apr  2 07:38:52 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered forwarding state
Apr  2 07:38:53 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered disabled state
Apr  2 07:38:53 thebox kernel: eth0: renamed from veth1f06682
Apr  2 07:38:53 thebox kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth0a65a1f: link becomes ready
Apr  2 07:38:53 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered blocking state
Apr  2 07:38:53 thebox kernel: br-18371025d7b1: port 1(veth0a65a1f) entered forwarding state
Apr  2 07:39:02 thebox kernel: br-f8a7f7f71814: port 22(vethe5dc7c2) entered disabled state
Apr  2 07:39:02 thebox kernel: veth186df87: renamed from eth0
Apr  2 07:39:02 thebox kernel: br-f8a7f7f71814: port 22(vethe5dc7c2) entered disabled state
Apr  2 07:39:02 thebox kernel: device vethe5dc7c2 left promiscuous mode
Apr  2 07:39:02 thebox kernel: br-f8a7f7f71814: port 22(vethe5dc7c2) entered disabled state
Apr  2 07:39:05 thebox kernel: br-f8a7f7f71814: port 22(vethaf4364a) entered blocking state
Apr  2 07:39:05 thebox kernel: br-f8a7f7f71814: port 22(vethaf4364a) entered disabled state
Apr  2 07:39:05 thebox kernel: device vethaf4364a entered promiscuous mode
Apr  2 07:39:06 thebox kernel: eth0: renamed from veth0d85c3c
Apr  2 07:39:06 thebox kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethaf4364a: link becomes ready
Apr  2 07:39:06 thebox kernel: br-f8a7f7f71814: port 22(vethaf4364a) entered blocking state
Apr  2 07:39:06 thebox kernel: br-f8a7f7f71814: port 22(vethaf4364a) entered forwarding state

 

54 minutes ago, Tuumke said:

Should i be worried if my syslog is full of:

Check the uptime for the containers, there may be one constantly re-starting.

4 minutes ago, JorgeB said:

Check the uptime for the containers, there may be one constantly re-starting.

Yeah there is, i just can;t figure out why. It's a satisfactory container from WolveIX. I also made an issue there, as this started before my upgrade to 6.12.9.