bloggs Posted October 14, 2016 Share Posted October 14, 2016 I took the upgrade to 6.2.1 through the web gui today. Everything looked fine, so I carefully prepared everything and rebooted, and after a while realized the system didn't come back up like normal and in fact I couldn't even ping it. I hooked up a monitor and found that the system had picked up a DHCP address for some reason on br0, even though it still has the correct address in the network.cfg on the thumb drive (I checked). Oddly enough, it also no longer requires a password for root and seems to be using the hostname "Tower" again now, so it apparently has reset some defaults. I am not able to get to the web interface or any shares. I did try rebooting it, but as expected it comes back up the exact same way. I am a bit hesitant to do too much to it without some guidance. I have attached a syslog, and below is the output of ifconfig and contents of network.cfg. root@Tower:~# ifconfig -a bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 ether 00:25:22:b3:79:73 txqueuelen 1000 (Ethernet) RX packets 238 bytes 40480 (39.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126 bytes 15688 (15.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.100.122.20 netmask 255.255.255.0 broadcast 10.100.122.255 ether 00:25:22:b3:79:73 txqueuelen 1000 (Ethernet) RX packets 218 bytes 35178 (34.3 KiB) RX errors 0 dropped 2 overruns 0 frame 0 TX packets 126 bytes 15688 (15.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 00:25:22:b3:79:73 txqueuelen 1000 (Ethernet) RX packets 238 bytes 40480 (39.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126 bytes 15688 (15.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 gre0: flags=128<NOARP> mtu 1476 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 gretap0: flags=4098<BROADCAST,MULTICAST> mtu 1462 ether 00:00:00:00:00:00 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ip_vti0: flags=128<NOARP> mtu 1364 tunnel txqueuelen 1 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.255.255.255 loop txqueuelen 1 (Local Loopback) RX packets 2 bytes 140 (140.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2 bytes 140 (140.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tunl0: flags=128<NOARP> mtu 1480 tunnel txqueuelen 1 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 network.cfg contents: # Generated settings: USE_DHCP="no" IPADDR="10.100.122.192" NETMASK="255.255.255.0" GATEWAY="10.100.122.200" DHCP_KEEPRESOLV="no" DNS_SERVER1="10.100.122.200" DNS_SERVER2="" DNS_SERVER3="" BONDING="no" BONDING_MODE="1" BRIDGING="yes" BRNAME="br0" BRSTP="yes" BRFD="0" syslog-20161014.txt Quote Link to comment
bloggs Posted October 14, 2016 Author Share Posted October 14, 2016 While reading through some other posts, I found something that may be narrowing down the issue. Someone else having issues was told to look at df to see if the usb stick was being mounted in /boot, and as seen below, mine is not: root@Tower:/dev/disk/by-id# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3916320 332536 3583784 9% / tmpfs 3952196 160 3952036 1% /run devtmpfs 3916332 0 3916332 0% /dev cgroup_root 3952196 0 3952196 0% /sys/fs/cgroup tmpfs 131072 1800 129272 2% /var/log I tried mounting /boot, and get the following: root@Tower:/dev/disk/by-id# mount /boot mount: special device /dev/disk/by-label/UNRAID does not exist However, /dev/disk doesn't have a by-label directory in it: root@Tower:/dev/disk/by-id# ls /dev/disk by-id/ by-partuuid/ by-path/ by-uuid/ A listing of /dev/disk/by-id, however, shows the sandisk usb stick: root@Tower:/dev/disk/by-id# ls ata-Samsung_SSD_850_PRO_1TB_S1SRNWAF800165W@ ata-Samsung_SSD_850_PRO_1TB_S1SRNWAF800165W-part1@ ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1PX0VEN@ ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1PX0VEN-part1@ ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7SU1C0F@ ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7SU1C0F-part1@ ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0M9PKS9@ ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0M9PKS9-part1@ usb-SanDisk_Ultra_4C531001610122117120-0:0@ usb-SanDisk_Ultra_4C531001610122117120-0:0-part1@ wwn-0x15885992948620480513x@ wwn-0x15885992948620480513x-part1@ wwn-0x18274113022826270721x@ wwn-0x18274113022826270721x-part1@ wwn-0x5738913526754463745x@ wwn-0x5738913526754463745x-part1@ wwn-0x8498134172870135810x@ wwn-0x8498134172870135810x-part1@ Did something change in 6.2.1 that removed the by-label directory? Quote Link to comment
bloggs Posted October 14, 2016 Author Share Posted October 14, 2016 I forgot to include the following in the last reply. /etc/fstab contains the following: root@Tower:/dev/disk/by-id# cat /etc/fstab /dev/disk/by-label/UNRAID /boot vfat auto,rw,exec,noatime,nodiratime,umask=0,shortname=mixed 0 1 Quote Link to comment
bloggs Posted October 14, 2016 Author Share Posted October 14, 2016 So, I found https://lime-technology.com/forum/index.php?topic=49013.0 which seems to be describing a pretty much identical situation. The poster in that case ended up rebuilding onto a new USB, which seems to have fixed his issue. I'd rather get it working without doing that, but I guess it is something I can do if nothing else works. Quote Link to comment
kode54 Posted October 15, 2016 Share Posted October 15, 2016 Try: dosfslabel /dev/sda1 "UNRAID" Where /dev/sda is the USB drive. Make sure from your by-id links and from attempting to mount it manually first: mount /dev/sdx1 /boot Quote Link to comment
bloggs Posted October 15, 2016 Author Share Posted October 15, 2016 I had checked that the drive label was "UNRAID" previously, but I went ahead and did what you requested, and received the following output. root@Tower:~# dosfslabel /dev/sda1 "UNRAID" root@Tower:~# ls /dev/disk/by-label /bin/ls: cannot access '/dev/disk/by-label': No such file or directory root@Tower:~# mount /dev/sda1 /boot mount: /dev/sda1: more filesystems detected. This should not happen, use -t <type> to explicitly specify the filesystem type or use wipefs( to clean up the device. Quote Link to comment
bloggs Posted October 15, 2016 Author Share Posted October 15, 2016 I decided to just go with a new thumb drive. I just brought it back up with a copy of the config directory from the old flash and things are looking good so far. In case anyone else has this issue, the procedure I used is as follows: 1 - Made a fresh backup of my original thumb drive files. 2 - Purchased a new thumb drive 3 - Used SDFormatter to format new thumb drive as FAT32 with the "UNRAID" label specified 4 - Downloaded 6.2.1 from the Lime site 5 - Extracted 6.2.1 to the new thumb drive 6 - Booted from the new thumb drive 7 - Applied original license key - got error that it doesn't match the new drive 8 - Shut down system 9 - Copied /config directory from original thumb drive to new thumb drive 10 - Booted up again from the new thumb drive 11 - Did the replace license procedure through the NAS GUI 12 - Checked drive placement in array 13 - Brought array back online I am just double checking everything, but I'm not seeing anything that was lost for settings. My dockers are present, the VM was up and running by the time I checked, and everything else seems to be in good shape. I originally thought I lost my plugins, but it just turned out that I had less of them installed than I remembered. All in all, this was pretty successful, and I'm yet again impressed with Unraid's ability to get through stuff like this without data loss. Quote Link to comment
kode54 Posted October 16, 2016 Share Posted October 16, 2016 Care to insert your old drive somewhere and list the output of "print" from fdisk? It sounds as if your old drive got mispartitioned or something. That, or it was just bad. Quote Link to comment
bloggs Posted October 16, 2016 Author Share Posted October 16, 2016 Sorry, I would but I already wiped it. I did as much testing as I could on it and nothing seemed to be wrong, so I just decided to wipe it and use it to haul around ISOs and stuff that won't matter if it does eventually flake out on me. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.