biwhite

Hi, my USB boot appears to have become unreadable with errors appearing on dmesg such as: [1794806.252468] FAT-fs (sda1): Directory bread(block 30551) failed [1794806.252472] FAT-fs (sda1): Directory bread(block 30552) failed [1794806.252476] FAT-fs (sda1): Directory bread(block 30553) failed [1794806.459152] FAT-fs (sda1): unable to read boot sector to mark fs as dirty [1794811.929409] fat__get_entry: 310 callbacks suppressed /boot is now unreadable, and I can't remount it as the device is no longer present: root@Tower:~# mount /dev/sda1 /boot mount: /boot: special device /dev/sda1 does not exist. root@Tower:~# cfdisk /dev/sda cfdisk: cannot open /dev/sda: No such file or directory I can't find any automatic backups of /boot, apart from one I made manually 11 months ago. There's evidence that something should have backed it up, with folder structures in /mnt/user/CommunityApplicationsAppdataBackup/Community_Applications_USB_Backup/ and /mnt/user/appdata/Community_Applications_USB_Backup/ but both of these locations only have the folder structure and a couple of 0 byte files with no other content. Can anyone suggest what I ought to take copies of from the running system before I attempt to reboot it, such that I can reconfigure the array and shares if the USB device doesn't work upon reboot? I can't pull the stick to try in another machine prior to shutting down the NAS as it's plugged into an internal USB socket, so not easily accessible.

I run IPv6 on mine with fixed addresses. Currently I use a kernel recompiled to include IPv6, then added '--ipv6 --fixed-cidr-v6='2a02:xxxx:xxxx:xxxx::/64' into the DOCKER_OPTS in /boot/config/docker.cfg I'm just an end-user, so I'm not sure how much integration they'll do to start off with adding this feature, but this may help when it comes. If you've not got IPv6 yet on the network, then you can probably get by with just adding '--ipv6' and it will assign link-local addresses to containers.

That's great news. Thanks for this.

I saw this today doing the rounds on mailing lists: http://seclists.org/nanog/2017/Mar/134 Verizon Wireless to stop issuing static IPv4 addresses from June. A big push towards forcing people onto IPv6 from them!

I've been using a single cache drive and wanted to add resilience so I've added a second drive. This appears to have just doubled the space available, rather than acting as a mirror of the first. How do I tell it to use the second SSD for resilience rather than extra space? Thanks.

Admittedly I'm likely to fall into your developer/advance user cagetories, and have some peculiar things I'm trying to do. I have 2 connections, and I balance them with primary ipv4 on one and primary ipv6 on the other, with the alternate lines acting as backup for each. Utilising IPv6 on the unRAID server gives me ability to use both lines more readily. I've dual stack IPv4+IPv6 at home currently on all equipment possible, but would like to progress towards IPv6 only. This has been covered as being done already by a bunch of companies within the Internet industry at various events such as UKNOF, NANOG etc. Most large UK providers offer native IPv6 to all of their consumer connections nowadays so it's available for the majority of consumers who won't even necessarily know they're using IPv6 for a lot of things already. As IPv4 addresses get more expensive, the trend will be to either bury connections in more layers of NAT or use native IPv6 for true end to end connectivity. The double layers of IPv4 NAT involved in going from the internet to my docker applications isn't ideal. As a compromise, how about enabling it in the kernel as a module, then if you really don't want it firing up to unwary folks, blacklist the module from loading which would suffice to protect those that don't want/know about it and those of us wanting IPv6 could simply unblacklist and configure manually as we need, rather than having to go through the hassle of building our own kernels each time unRAID kernel version bumps, purely to enable the IPv6 module.