clevoir Posted June 12, 2016 Share Posted June 12, 2016 I have syslog and syslog.1 syslog.1 is 3072KB in size, attached is a zipped version syslog.1.zip Link to comment
HellDiverUK Posted June 12, 2016 Share Posted June 12, 2016 I appreciate that you get the occassional disk red balled, Well, no. I've never had a red balled disk, and I've been running UnRAID for a long, long time. If you're getting red balled disks that turn out to be fine, you have other issues that need addressed. Link to comment
Akio Posted June 12, 2016 Share Posted June 12, 2016 i am a little confused as it achieved either score from the transfer, as i havent set up a cache on the unraid server, and at the moment its currently sitting with 2 disks in the array (1x 500gb wd blue for iso's etc) (1x 3tb wd red for media share) both in XFS. I noticed the other drives that are freshly wiped and ready for the server are 3x 3tb wd reds, and those are unformated as the new beta wants them at btrfs??? hmm surely the 1 wd red can't pull off reads/writes that high? In both cases, you were writing TO the unRAID server. The Linux kernel automatically caches using all available RAM. Edit: so your faster result was pure network, RAM to RAM. The slower test was local disk to RAM, over the network. thanks rob just got myself some more ram for the server, now its 128gb [glow=red,2,300]muhahaha [/glow] not to sure if there's an issues atm, mem test went ok. just a side note question: # seem to be locked out of the web gui ! i can access the shares still on the network but it wont shut down via server power button either... strange. i feel the need do a force shutdown...ouch. will try to log into ipmi and do it that way. Hopefully when it reboots i can see the log's Link to comment
dlandon Posted June 12, 2016 Share Posted June 12, 2016 I am now getting the 'Update Ready' on MineOS and after update the status stays 'Update Ready'. I've not seen this before b23. Link to comment
RobJ Posted June 12, 2016 Share Posted June 12, 2016 I have syslog and syslog.1 syslog.1 is 3072KB in size, attached is a zipped version Thank you clevoir, syslog.1 is the one we needed. And thank you bonienl for the truncations! Unfortunately, this case was a good one, that showed just truncating was still not enough. The current syslog was 3MB (obviously truncated to 3M) of nothing but repeated errors, of which same there were already more than 1.5MB in syslog.1. And worse, there were 2 files this huge, which blew up the diagnostics zip file. Since we don't want anything but the very first syslog part, I'm going to change my recommendation to the following procedure, in this order - - tail of syslog, 200 lines - delete syslog - rename highest numbered syslog file to syslog - delete all remaining numbered syslogs (syslog.?), if any - truncate syslog (2M or 3M, I'm now leaning toward 2M in case there are any other giants) - then collect for diagnostics In other words, keep only the first part of the syslog plus the first odd MB of errors, and a tail. And these deletions and truncations should open up log space allowing them to complete the diagnostics process, and possibly do other testing. clevoir, in your syslog, it looks like something goes wrong with the SAS card, first at Jun 9 20:41:51. (You booted at about Jun 9 20:16:07.) No issues appear, which is strange, this usually means trouble with the card, and results in drive issues. But the system *appears* to continue on, running fine until Jun 10 05:07:29, and this time you don't get away with it! The kernel crashes over and over, and if you had known about it, you should probably have shut down right then, because the system was corrupted. You can ignore all errors after that. And you may want to check any files saved or moved after this for corruption. Not sure what to advise. Check for newer firmware for the SAS card. Your BIOS is from 2012, check for a newer one. If you can move all drives off the SAS card, or replace it, that could be a good test. How sure are you that this hasn't happened before? This too is probably a support issue, but it's very remotely possible that there's a driver change in the kernel update that's buggy (mvsas?). Link to comment
clevoir Posted June 12, 2016 Share Posted June 12, 2016 Thanks, I have 3 AOC-SASLP-MV8 cards, 2 of which I have had for over 5 years - one of these is to where the 2 faulty drives are connected The third card is about 2 years old, I have never had a problem with any of them before. All are running the last version of firmware before Supermicro offered RAID options They were working faultlessly under b21, and I did wonder the Marvell drivers may have changed under b22, now b23, which may have caused these problems. I know people have had drivers problems before, but understand that this was AOC-SAS2LP-MV8? I did have an email heath report on Saturday morning @0200, and then at 07.24 2 further emails staing that the disk had faults Link to comment
aptalca Posted June 12, 2016 Share Posted June 12, 2016 cant remember were i read it in the forums but some said that the author rebuilds the docker on git hub it then works EDIT I have this issue with DelugeVPN and also had it with one of my personal dockers. I did a rebuild on docker hub for mine and it fixed the issue, so possibly if binhex forces a rebuild at docker hub might fix it. I pushed a rebuild on docker hub for jdownloader, but unfortunately still getting the constant 0B updates Link to comment
archedraft Posted June 12, 2016 Share Posted June 12, 2016 If a parity check finds 1563 errors shouldn't the history status say something other than "OK" in the status? Link to comment
AmishJoe Posted June 12, 2016 Share Posted June 12, 2016 I re-enabled MTU9000 in the Network settings (with 2x 802.3ad bonded cards, with a properly configured switch for LACP) and I am still unable to check for Docker updates. "Fix Common Problems" is reporting that I don't have DNS set up properly, although this works fine as soon as I disable MTU9000. I can view the WebGUI and SSH to the server no problem. Diagnostics attached. wopr-diagnostics-20160612-1236.zip Link to comment
AmishJoe Posted June 12, 2016 Share Posted June 12, 2016 After setting MTU back to default, I am unable to configure a DNS server in the GUI (grayed out, unable to change from Automatic) and still unable to talk to Github or ping google.com Link to comment
bonienl Posted June 12, 2016 Share Posted June 12, 2016 I re-enabled MTU9000 in the Network settings (with 2x 802.3ad bonded cards, with a properly configured switch for LACP) and I am still unable to check for Docker updates. "Fix Common Problems" is reporting that I don't have DNS set up properly, although this works fine as soon as I disable MTU9000. I can view the WebGUI and SSH to the server no problem. Diagnostics attached. Couple of things to check: 1. Enable MTU 9000 on the LAN interface of your router 2. Keep default MTU size on the WAN interface of your router 3. Check your switch can handle jumbo frames of 9000 bytes Link to comment
bonienl Posted June 12, 2016 Share Posted June 12, 2016 After setting MTU back to default, I am unable to configure a DNS server in the GUI (grayed out, unable to change from Automatic) and still unable to talk to Github or ping google.com Post a screenshot, sounds like something not set right. Link to comment
ljm42 Posted June 12, 2016 Share Posted June 12, 2016 'unraidlabel' wasn't mentioned in the changelog for b23, but I thought I'd go ahead and provide updated diagnostics in case it helps track down the problem. Slight change, this time I loaded both in safe mode. To recap: * Config 1 - The diag shows how the VM boots and everything works when 'unraidlabel' is not specified (and the USB label is UNRAID) per the instructions here: https://www.linuxserver.io/index.php/2015/12/14/creating-an-unraid-virtual-machine-to-run-on-an-unraid-host/ * Config 2 - The diag shows how things break when 'unraidlabel' is specified in syslinux.cfg (and the USB label is UNRAID-CONF). Those are the only config changes between the two diagnostics. A few more details: * unRAID 6.2b23 is running in a VM on an unRAID 6.1.9 host. A USB controller is hidden from the host (with pci-stub.ids=8086:8c2d) so that the VM's USB drive labeled 'UNRAID' won't conflict with the hosts' USB drive with the same label. The reason I asked LT for the ability to rename the USB drive is so that there wouldn't be a need to stub the USB controller like this. * In the VM, the /boot folder points at the VM's USB drive, which contains the config folder but not the boot files, which are in a separate unraid-vm.img file. Sorry, that part is kind of confusing. * Note that config 1 shows "Plus key detected" whereas config 2 is "unregistered" * Note that config 1 boots fine, but config 2 throws a device_by_name error and then emhttp segfaults: device_by_name: device_by_name: () not found emhttp[2614]: segfault at 528 ip 000000000040bace sp 00007ffd22b74480 error 4 in emhttp[400000+22000] * Another interesting point... the original name of the Config1.zip file was towervm-diagnostics[date].zip whereas Config2.zip defaulted back to tower-diagnostics[date].zip (i.e. "tower" rather than "towervm") So 'unraidlabel' works partially (it mounts the right drive to /boot) but a lot of other things break. Config1.zip Config2.zip Link to comment
hawihoney Posted June 12, 2016 Share Posted June 12, 2016 Just two question. I'm running B23 with Dual Parity and had to replace a failed drive: * After restart with a replacement drive I could read something like that behind the "Start" Button "Data-Rebuild and/or Parity Check". Is this correct? Can please somebody explain that? * I did start the Data Rebuild. After completion the Main page reports a completed Parity Check with the same DateTime as the Data Rebuild. How come? Will Data Rebuild do a Parity Check at the same time? Where can I find some more info on that? TIA Link to comment
RobJ Posted June 12, 2016 Share Posted June 12, 2016 'unraidlabel' wasn't mentioned in the changelog for b23, but I thought I'd go ahead and provide updated diagnostics in case it helps track down the problem. Slight change, this time I loaded both in safe mode. To recap: * Config 1 - The diag shows how the VM boots and everything works when 'unraidlabel' is not specified (and the USB label is UNRAID) per the instructions here: https://www.linuxserver.io/index.php/2015/12/14/creating-an-unraid-virtual-machine-to-run-on-an-unraid-host/ * Config 2 - The diag shows how things break when 'unraidlabel' is specified in syslinux.cfg (and the USB label is UNRAID-CONF). Those are the only config changes between the two diagnostics. A few more details: * unRAID 6.2b23 is running in a VM on an unRAID 6.1.9 host. A USB controller is hidden from the host (with pci-stub.ids=8086:8c2d) so that the VM's USB drive labeled 'UNRAID' won't conflict with the hosts' USB drive with the same label. The reason I asked LT for the ability to rename the USB drive is so that there wouldn't be a need to stub the USB controller like this. * In the VM, the /boot folder points at the VM's USB drive, which contains the config folder but not the boot files, which are in a separate unraid-vm.img file. Sorry, that part is kind of confusing. * Note that config 1 shows "Plus key detected" whereas config 2 is "unregistered" * Note that config 1 boots fine, but config 2 throws a device_by_name error and then emhttp segfaults: device_by_name: device_by_name: () not found emhttp[2614]: segfault at 528 ip 000000000040bace sp 00007ffd22b74480 error 4 in emhttp[400000+22000] * Another interesting point... the original name of the Config1.zip file was towervm-diagnostics[date].zip whereas Config2.zip defaulted back to tower-diagnostics[date].zip (i.e. "tower" rather than "towervm") So 'unraidlabel' works partially (it mounts the right drive to /boot) but a lot of other things break. You've outlined the problem quite well. I can add 2 more things, one very important, the other possibly important. * The systems using unraidlabel do not have 'vars' set up(!), except for the new network section. That explains why no registration or tower name, and probably other issues too if you had been able to continue further. Without the basic system 'vars', a segfault was probably the cleanest abort you could get. * In the beta22 system with unraidlabel, the cache drive assignment was recognized in the syslog, and the device_by_name error occurs immediately after. In the beta23 system with unraidlabel and safe mode, there's no cache drive assignment (even though it's still in disk.cfg) and no device_by_name error. The fact that there is no device_by_name error could either be because of something about the cache drive assignment, or because of safe mode. If it's related to safe mode, then it would be related to a plugin that's not allowed to run in safe mode. It seems more likely to me to be related to the cache drive handling, that didn't happen here. Hopefully, these additional clues will help solve this sooner. Link to comment
archedraft Posted June 12, 2016 Share Posted June 12, 2016 Is it normal to get these notifications periodically in your syslog? Jun 12 15:49:43 unRAID kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1 Jun 12 15:49:53 unRAID kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1 Link to comment
Squid Posted June 12, 2016 Share Posted June 12, 2016 Is it normal to get these notifications periodically in your syslog? Jun 12 15:49:43 unRAID kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1 Jun 12 15:49:53 unRAID kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1 Yes... Harmless message Link to comment
AmishJoe Posted June 12, 2016 Share Posted June 12, 2016 After setting MTU back to default, I am unable to configure a DNS server in the GUI (grayed out, unable to change from Automatic) and still unable to talk to Github or ping google.com Post a screenshot, sounds like something not set right. Network attached. Have tried multiple reboots. This configuration worked before upgrading to Beta23 (came from Beta21). MTU9000 worked before upgrading to 6.2, others have reported it broken. Switch is configured fine (PowerConnect 6248), and I can access WebGUI and SSH no problem. EDIT: I manually added nameserver 172.17.10.1 to my /etc/resolv.conf and this allows me to ping google, but interesting how I cannot configure this from GUI. I also assume this will not survive a reboot. Have not yet tested with MTU set back to 9000. Link to comment
bonienl Posted June 12, 2016 Share Posted June 12, 2016 After setting MTU back to default, I am unable to configure a DNS server in the GUI (grayed out, unable to change from Automatic) and still unable to talk to Github or ping google.com Post a screenshot, sounds like something not set right. Network attached. Have tried multiple reboots. This configuration worked before upgrading to Beta23 (came from Beta21). MTU9000 worked before upgrading to 6.2, others have reported it broken. Switch is configured fine (PowerConnect 6248), and I can access WebGUI and SSH no problem. EDIT: I manually added nameserver 172.17.10.1 to my /etc/resolv.conf and this allows me to ping google, but interesting how I cannot configure this from GUI. I also assume this will not survive a reboot. Have not yet tested with MTU set back to 9000. Looks like a remnant of your previous configuration. - Switch the setting for IP assignment to "automatic", this will enable the setting for DNS. - Now you can change DNS setting to static and enter the desired IP address(es) - Switch IP assignment back to static Link to comment
sarf Posted June 13, 2016 Share Posted June 13, 2016 Hi Guy's, I have had an issue with unraid 6.2Beta since its release that was not present in 6.1.9. It's not a major issue and is extremely intermittent. Basically I have multiple VM's from windows 8 and 7 to fedora 23 with no problems at all. However I have one VM which is my Windows 10 VM which is passing through my 980Ti GPU and sound blaster Z sound card which I use for gaming. The problem I'm having is when starting the Windows 10 VM after rebooting the server, or if I have to reboot just the VM for updates etc, it intermittently locks up at the windows 10 blue center square and does not boot. To rectify this I simply force stop the VM, at which point the blue center window 10 boot icon stays on the screen even though the VM is now off. I then simply start it up again, repeating this process until it finally boots. It's more of an anoyance than anything else. I have attached diagnostics for your review and I know this is probably a difficult one to solve as it's intermittent. I have already applied all the tips and tweaks along with fix common problems but the issue is still there. Any help or advice would be great! Cheers. Just uploaded my hardware profile too Regards Sarf. core-diagnostics-20160613-1137.zip Link to comment
RobJ Posted June 13, 2016 Share Posted June 13, 2016 I have had an issue with unraid 6.2Beta since its release that was not present in 6.1.9. It's not a major issue and is extremely intermittent. Basically I have multiple VM's from windows 8 and 7 to fedora 23 with no problems at all. However I have one VM which is my Windows 10 VM which is passing through my 980Ti GPU and sound blaster Z sound card which I use for gaming. The problem I'm having is when starting the Windows 10 VM after rebooting the server, or if I have to reboot just the VM for updates etc, it intermittently locks up at the windows 10 blue center square and does not boot. To rectify this I simply force stop the VM, at which point the blue center window 10 boot icon stays on the screen even though the VM is now off. I then simply start it up again, repeating this process until it finally boots. It's more of an anoyance than anything else. I have attached diagnostics for your review and I know this is probably a difficult one to solve as it's intermittent. If you line up the libvirtd.log with the syslog, and adjust times by one hour (libvirtd+1H=syslog times), you can see the VM start activity. The non-Win10 starts are uneventful, the Win10 starts are accompanied by considerable USB instability, lots of USB port resets and often disabled inputs ('Dell USB Keyboard' and 'ROCCAT Kone XTD'). I can't say whether the USB troubles are the cause, or just another casualty of something else wrong, but this *may* be an avenue for troubleshooting. One known troublemaker is USB 3.0, ports and drivers. If you can avoid it, try testing without using any USB3. The fact that it works some times and not others, and all other functions work correctly, implies a race condition somewhere. It could be a hardware component that's marginal, responds correctly or fast enough only part of the time. This would most probably (but not necessarily) be a component used only by the Win10 VM. Or it could be a load order issue, where it's almost random who loads first, and in the wrong order some component is blocked. If it's specific to the Win10 VM, then you'll have to play with its config, make sure its drivers are up to date, etc. Less likely but if it involves something more basic to the unRAID system, then you may have to play with the unRAID config, and underlying hardware. Check for newer BIOS, etc. You have a lot of plugins and packages, so you might try Safe Mode, just to eliminate that possibility. Link to comment
AmishJoe Posted June 13, 2016 Share Posted June 13, 2016 After setting MTU back to default, I am unable to configure a DNS server in the GUI (grayed out, unable to change from Automatic) and still unable to talk to Github or ping google.com Post a screenshot, sounds like something not set right. Network attached. Have tried multiple reboots. This configuration worked before upgrading to Beta23 (came from Beta21). MTU9000 worked before upgrading to 6.2, others have reported it broken. Switch is configured fine (PowerConnect 6248), and I can access WebGUI and SSH no problem. EDIT: I manually added nameserver 172.17.10.1 to my /etc/resolv.conf and this allows me to ping google, but interesting how I cannot configure this from GUI. I also assume this will not survive a reboot. Have not yet tested with MTU set back to 9000. Looks like a remnant of your previous configuration. - Switch the setting for IP assignment to "automatic", this will enable the setting for DNS. - Now you can change DNS setting to static and enter the desired IP address(es) - Switch IP assignment back to static I'm sure this will work, but I do have to say - I have only ever had a static configuration here. DNS worked previously... Link to comment
Vr2Io Posted June 13, 2016 Share Posted June 13, 2016 If a parity check finds 1563 errors shouldn't the history status say something other than "OK" in the status? You will found detail in "Tools" -> "Archived Notifications", it will show 0 or XXXX errors. Link to comment
archedraft Posted June 14, 2016 Share Posted June 14, 2016 I figured out why I was getting the following errors after upgrading from 6.1.9 Warning: libvirt_domain_xml_xpath(): namespace warning : xmlns: URI unraid is not absolute in /usr/local/emhttp/plugins/dynamix.vm.manager/classes/libvirt.php on line 936 Warning: libvirt_domain_xml_xpath(): It was because of the lines in the config that had to do with the VM icon <metadata> <vmtemplate xmlns="unraid" name="OSX" icon="OSX-10.10.png" os="OSX"/> </metadata> I have a second test server I upgraded from 6.1.9 and if I remove the metadata lines above the error goes away, but if I try and use the unRAID VM editor to add another image back the same warning message appears no matter which icon I choose. As of right now my second server just has the metadata lines removed as I do not want to set up that server from scratch like I did on my first server. Could it be because I was using custom icons when I upgraded and once I got into 6.2 it didn't know how to handle that situation? Link to comment
dmacias Posted June 14, 2016 Share Posted June 14, 2016 I figured out why I was getting the following errors after upgrading from 6.1.9 Warning: libvirt_domain_xml_xpath(): namespace warning : xmlns: URI unraid is not absolute in /usr/local/emhttp/plugins/dynamix.vm.manager/classes/libvirt.php on line 936 Warning: libvirt_domain_xml_xpath(): It was because of the lines in the config that had to do with the VM icon <metadata> <vmtemplate xmlns="unraid" name="OSX" icon="OSX-10.10.png" os="OSX"/> </metadata> I have a second test server I upgraded from 6.1.9 and if I remove the metadata lines above the error goes away, but if I try and use the unRAID VM editor to add another image back the same warning message appears no matter which icon I choose. As of right now my second server just has the metadata lines removed as I do not want to set up that server from scratch like I did on my first server. Could it be because I was using custom icons when I upgraded and once I got into 6.2 it didn't know how to handle that situation? I have several VM's with custom icons in 6.2. <metadata> <vmtemplate xmlns="unraid" name="Ubuntu" icon="mythbuntu.png" os="Linux"/> </metadata> <metadata> <vmtemplate xmlns="unraid" name="ElCapitan" icon="apple-logo.png" os="OSX"/> </metadata> Not sure but I think the location might have changed in 6.2. .../dynamix.vm.manager/templates/images Link to comment
Recommended Posts