July 13, 200817 yr Maybe I should just stick with 4.2.4 I'm starting to have the same thoughts. Jim Just to add another data point, I went back to 4.2.4. 4.3.1 just wasn't stable for me. unraid would crash every few days requireing a hard reboot. Even the console was dead. Hopefully in a later release it will get better again. Were you using the "cache" drive in 4.2.4? (just trying to pinpoint what was causing the crash... Tom might be able to figure out from symptoms.) I do know that the "mv -v" command in the "mover" script affiliated with the cache drive is causing lots of log entries, and once the log file used up all of the available RAM, the system would crash. Joe L.
July 15, 200817 yr Hi, No I wasn't using the cache drive. Configuration was unchanged from 4.2.4, which I'm now using and is not giving me problems under heavier useage. perhaps if I get time, I'll try and capture a syslog from a 4.3 crash.
July 15, 200817 yr I just tried syslinux 3.70 and that didn't help either. I guess it's back to 4.2.4 for the time being. Jim
July 15, 200817 yr Joe, I just got through trying rootdelay=20 when I read your reply. I will try rootdelay=30 and rootdealy=5 soon. The flash drive is plugged directly into the motherboard. I tried a Lexar flash drive a little bit earlier this morning. It is buliker than the Sony Micro Vault Tiny so I had to put it in a different USB port of the motherboard because the video connector was in the way. The results were the same though. I seem to be seeing a pattern with successes and failures. When at the boot menu, if I press ENTER to bypass the 5 second delay or if I let the 5 second delay to play out, the boot will most likely fail. When at the boot menu, if I press TAB and then ENTER (with no changes the the defaults) the boot will most likely be successful. Jim The rootdelay parameter doesn't do anything & we'll be taking it out in the 4.4 series. When you say "boot will most likely fail" - how far does it get in booting? Couple other questions: 1. Are you using the latest bios for your motherboard? 2. Is it possible to set USB1.1 (sometimes also called "full speed" as opposed to "hi speed") in your bios? If so, it will take forever, but I'd be interested to know if it boots correctly in this case.
July 16, 200817 yr Joe, I just got through trying rootdelay=20 when I read your reply. I will try rootdelay=30 and rootdealy=5 soon. The flash drive is plugged directly into the motherboard. I tried a Lexar flash drive a little bit earlier this morning. It is buliker than the Sony Micro Vault Tiny so I had to put it in a different USB port of the motherboard because the video connector was in the way. The results were the same though. I seem to be seeing a pattern with successes and failures. When at the boot menu, if I press ENTER to bypass the 5 second delay or if I let the 5 second delay to play out, the boot will most likely fail. When at the boot menu, if I press TAB and then ENTER (with no changes the the defaults) the boot will most likely be successful. Jim The rootdelay parameter doesn't do anything & we'll be taking it out in the 4.4 series. When you say "boot will most likely fail" - how far does it get in booting? Couple other questions: 1. Are you using the latest bios for your motherboard? 2. Is it possible to set USB1.1 (sometimes also called "full speed" as opposed to "hi speed") in your bios? If so, it will take forever, but I'd be interested to know if it boots correctly in this case. The boot makes it all the way to the login. Welcome to Linux 2.6.24.4-unRAID (tty1) Tower login: Where it fails is where it tries to mount the non-root local filesystem. Mounting non-root local filesystems: mount: special device /dev/disk/by-label/UNRAID does not exist The motherboard has the next to the last BIOS. I have downloaded the latest but I have to decide how I am going to get it installed. It requires booting to DOS or Windows. I'll probably see if I can attach a floppy drive and go the DOS route. The only USB options are Enable/Disable and Legacy Enable/Disable.
July 16, 200817 yr If you are getting that far, then you ARE booting Linux! This is often as simple as restoring the UNRAID volume label to your flash drive. I would recheck (I know, one more time!) the USB Flash Drive Preparation page for the tips there, and also capture a syslog for us. The message you are getting about not finding the device labeled UNRAID just means it was going back to the flash drive for the networking config, but could no longer find the flash drive (labeled UNRAID). Several others have had a change in the way the IRQ's are set up between versions, that possibly affected the access to the USB drive and other things. It *might* help to see the 2 syslogs you compared earlier, the working and non-working ones.
July 16, 200817 yr Several others have had a change in the way the IRQ's are set up between versions, that possibly affected the access to the USB drive and other things. It *might* help to see the 2 syslogs you compared earlier, the working and non-working ones. They are attached to a post earlier in this thread. http://lime-technology.com/forum/index.php?topic=2159.msg16244#msg16244 note that the USB flash drive detection is the very last thing in the syslog.in the fail log prior to logging in.
July 16, 200817 yr According to this thread, http://lime-technology.com/forum/index.php?topic=2159.msg16284#msg16284 interrupt handling has changed on the newer kernel It appears that adding pci=noacpi as a boot code on the "append" line in syslinux.cfg might route the interrupts through the PIC as with the older kernel. An alternative boot code to try is acpi=off You might try one or the other and see if they help. Joe L.
July 16, 200817 yr Several others have had a change in the way the IRQ's are set up between versions, that possibly affected the access to the USB drive and other things. It *might* help to see the 2 syslogs you compared earlier, the working and non-working ones. They are attached to a post earlier in this thread. http://lime-technology.com/forum/index.php?topic=2159.msg16244#msg16244 note that the USB flash drive detection is the very last thing in the syslog.in the fail log prior to logging in. Those logs are for 'santan17'. I wanted to make sure 'jru' is having the exact same problem. jru: if you look at you system log upon unsuccessful boot, do you see this as the last line (before the telnet login message)? kernel: usb-storage: device scan complete
July 16, 200817 yr According to this thread, http://lime-technology.com/forum/index.php?topic=2159.msg16284#msg16284 interrupt handling has changed on the newer kernel It appears that adding pci=noacpi as a boot code on the "append" line in syslinux.cfg might route the interrupts through the PIC as with the older kernel. An alternative boot code to try is acpi=off You might try one or the other and see if they help. Joe L. Yes, please try these options on at a time.
July 16, 200817 yr I'll try to look at system log later today after I get home from work. I did try both options (one at a time) this morning before work. Neither one had any affect. I also tweaked the BIOS (what little it can be tweaked). I disabled the audio, serial port, parallel port and even shut off ACPI. I edit the syslinux.cfg on a Windows computer so I always power down the server before removing the flash drive and power it up after I replace the flash drive. That almost always results in a successful boot. Once the boot is successful, I access unRAID from the web interface, stop the array and then initiate a reboot. That almost always fails. Thanks all for your help and patience. Jim
July 17, 200817 yr jru: if you look at you system log upon unsuccessful boot, do you see this as the last line (before the telnet login message)? kernel: usb-storage: device scan complete Yes. Edit: added a syslog from a successful boot.
July 17, 200817 yr Unfortunately, the failing syslog is from a run with acpi=off, and all it proves is that that definitely does not work. Since the good one has no extra boot options, it is hard to compare them. Interestingly, there is a hint in the good one about trying pci=routeirq. I wonder if that might make a difference. By the way, were you able to obtain and load the latest BIOS? You also reported earlier that you could usually successfully boot if you pressed TAB and then Enter, and that it would usually fail to boot if you only pressed Enter. If nothing else, you may have found a workaround. Since this seems so repeatable, would it be possible to see a syslog from both keying methods, so we can check for anything different in the syslogs, that might provide a clue? (I'm sorry about my post about 6 or 7 back. I was tired and it was very late.)
July 17, 200817 yr Unfortunately, the failing syslog is from a run with acpi=off, and all it proves is that that definitely does not work. Sorry about that. What was I thinking? Interestingly, there is a hint in the good one about trying pci=routeirq. I wonder if that might make a difference. No. Same end result. You also reported earlier that you could usually successfully boot if you pressed TAB and then Enter, and that it would usually fail to boot if you only pressed Enter. If nothing else, you may have found a workaround. Since this seems so repeatable, would it be possible to see a syslog from both keying methods, so we can check for anything different in the syslogs, that might provide a clue? Attached are 3 syslogs. They were all made with the option pci=routeirq. 1. syslog_routeirq_boot_5seconds_success.txt This is from a cold boot. The 5 second wait at the boot menu was allowed to expire. It was successful. 2. syslog_routeirq_reboot_5seconds_failed.txt This is from a reboot triggered from the web interface. The 5 second wait at the boot menu was allowed to expire. It failed. 3. syslog_routeirq_reboot_tab-enter_success.txt This is from a reboot triggered from the web interface. [TAB] followed by [ENTER] was pressed immediately after the boot menu appeared. It was successful. Thanks to all. Jim
July 17, 200817 yr Excellent work! Unfortunately no clues though. In fact, what is notable is that nothing in the syslog is notable. They are essentially identical up to the "usb-storage: device scan complete" message, at which point the device scan seems complete for all drives, and it is turning its attention to getting the network set up, and needs to access network.cfg on the flash drive. What is strange is that nothing further, good or bad, is logged here. So if anything is different at this point, the syslogs are not helping us... but the console messages might. Perhaps you (since you have been so cooperative!) could examine the final console messages on a boot that fails, then look for them on a boot that succeeds. You of course won't see any fuse or unRAID or ntp messages on the failed boot, but what else may be different? Since I don't know of a way to capture the screens, possibly a digital camera could help? One note, the pci=routeirq boot option produced identical interrupt assignments as the new kernel in v4.3.3, so no help there. It 'routed' them more publicly than ACPI does, but must use an identical method. The only other effect is a fraction slower performance, so I suggest you remove it. It consistently slowed XOR speed from 6468.000 MB/sec to 6387.600 MB/sec.
July 18, 200817 yr Here's what I have been able to transcribe. I hope it is what you are looking for. I had quite a time getting a successful boot after work today. This may indicate that the patterns I was seeing before were coincidences. The following section is the same for successful and unsuccessful boots. The successful part was hard to get because it scrolled by so fast. I finally used my camera to make a video that I could pause when needed. Mounting non-root local filesystems: scsi 0:0:0:0: Direct-Access Sony Storage Media 0100 PQ: ansi: 0 cc sd 0:0:0:0: [sdd] 506880 512-byte hardware sectors (260 MB) sd 0:0:0:0: [sdd] Write Protect is off sd 0:0:0:0: [sdd] Assuming drive cache: write through sd 0:0:0:0: [sdd] 506880 512-byte hardware sectors (260 MB) sd 0:0:0:0: [sdd] Write Protect is off sd 0:0:0:0: [sdd] Assuming drive cache: write through sdd: sdd1 sd 0:0:0:0: [sdd] Attached SCSI removable disk An unsuccessful boot continues as follows. mount: special device /dev/disk/by-label/UNRAID does not exist INIT: Entering runlevel: 3 Going multiuser... Updating shared library links: /sbin/ldconfig & Starting sysklogd daemons: /usr/sbin/syslogd -m0/usr/sbin/klogd -c 3 -x Triggering udev events: /sbin/udevtrigger --retry-failed /etc/rc.d/rc.inet1.conf: line 18: /boot/config/network.cfg: No such file or dir ctory /etc/rc.d/rc.inet1.conf: line 19: /var/tmp/network.cfg: No such file or directo y Welcome to Linux 2.6.24.4-unRAID (tty1) Tower login: And this is the continuation of a successful boot. /dev.sdd1 on /boot type vfat (rw) INIT: Entering runlevel: 3 Going multiuser... Updating shared library links: /sbin/ldconfig & Starting sysklogd daemons: /usr/sbin/syslogd -m0/usr/sbin/klogd -c 3 -x Triggering udev events: /sbin/udevtrigger --retry-failed Polling for DHCP server on interface eth0: dhcpcd: MAC address = 00:1e:90:8e:00:34 dhcpcd: your IP address = 192.168.0.184 Starting RPC portmapper: /sbin/rpc.portmap Starting RPC NSM (Network Status Monitor): /bin/rpc.statd Starting Internet super-server daemon: /usr/sbin/inetd Starting NTP daemon: /usr/sbin/ntpd -G Starting ACPI daemon: /usr/sbin/acpid Starting Samba: /usr/sbin/smbd -D /usr/sbin/nmbd -D Starting ifplugd: /etc/rc.d/rc.ifplugd start Starting Network Interface Plugging Daemon: eth0. Starting FUSE support: /etc/rc.d/rc.fuse start Loading fuse module. Mounting fuse control filesystem. Welcome to Linux 2.6.24.4-unRAID (tty1) Tower login: Jim
July 18, 200817 yr Great work again, lots of time and effort expended here I know. I guess we were all hoping for a new clue, but assuming an apparently identical environment, we are back to the one common issue, that the flash drive is randomly dropped or unreadable. If it were only your system doing this, I would say move to another USB port, perhaps that one is flaky, but with others having the same problem, with this specific kernel, I am out of ideas. Perhaps Tom can prepare a debug version of the startup script, that might step through the process at the point of 'flakiness'. Unless Tom, with his much more extensive knowledge of what is going on at this point, has any other ideas, you and the others may have to stick with v4.2.4 until Tom has a release with kernel 2.6.26. Thanks for all your work. You proved that the problem is unrelated to any setting, and probably unrelated to hardware. Just a thought, I wonder if we are waiting long enough, after the flash drive is mounted and the FAT system is mounted, before checking for the UNRAID label. Perhaps some machines or ports need a little more time...
July 18, 200817 yr I have seen this exact behavior on a laptop... it wasn't booting unRAID, but another flavor of *nix for security and penetration testing. The problem turned out to be a bad connection of the USB socket to the mobo.... probably caused by stress when the USB drive was pushed up or down accidentally, and damaging the mobo connection. It affected BOTH USB ports (side by side, and on the same header on the mobo) I know this may be hard to do, but if you can boot Windows, then insert the USB key, and wiggle it a little, and see if Windows drops and adds the drive as if it was being removed and reinserted. You might also try a PCI card that has USB ports on it to eliminate the mobo USB ports as a point of failure.
July 18, 200817 yr I have seen this exact behavior on a laptop... it wasn't booting unRAID, but another flavor of *nix for security and penetration testing. The problem turned out to be a bad connection of the USB socket to the mobo.... probably caused by stress when the USB drive was pushed up or down accidentally, and damaging the mobo connection. It affected BOTH USB ports (side by side, and on the same header on the mobo) I know this may be hard to do, but if you can boot Windows, then insert the USB key, and wiggle it a little, and see if Windows drops and adds the drive as if it was being removed and reinserted. You might also try a PCI card that has USB ports on it to eliminate the mobo USB ports as a point of failure. That's a good thought. I kind of doubt that would be the problem. It's a Sony Micro Vault Tiny. It has almost no bulk or weight. The motherboard finds and starts unRAID every time. Even after a failed boot, I can manually mount the flash drive. Evidence that it is still has a good connection. However, after my parity-sync finishes, I will try some of these suggestions. I've go nothing to lose. Thanks, Jim
July 19, 200817 yr hello, I am also having the same problem :-( 4.2.4 works well, 4.3.3 has the same problem described as above. I am attaching my syslogs and devices list also, any help is appreciated. My motherboard is Gigabyte GA-EG31M-S2, ICH7, 8111c (lan) according to specs.
July 21, 200817 yr 4.2.4 works well, 4.3.3 has the same problem described as above. I am attaching my syslogs and devices list also, any help is appreciated. A comparison of your syslogs indicates the identical scenario that jru has, so the identical advice above applies to you also, back to v4.2.4 until a release with a newer kernel that works better with your hardware. Your v4.2.4 syslog indicates a fair amount of trouble (a series of exception Emask (device errors) with each of the 3 drives), but I don't know yet if that is from a more systemic problem, or just a side effect of returning to the older version. I suspect that the changes in v4.3.3 to work around the model name handling may not be completely backward compatible, so super.dat has to be regenerated.
July 21, 200817 yr Thanks, I will wait for the new version, and continue using 4.2.x for now. As for the errors, i don't know hopefully its nothing dangerous. The drives are practically new. 4.2.4 works well, 4.3.3 has the same problem described as above. I am attaching my syslogs and devices list also, any help is appreciated. A comparison of your syslogs indicates the identical scenario that jru has, so the identical advice above applies to you also, back to v4.2.4 until a release with a newer kernel that works better with your hardware. Your v4.2.4 syslog indicates a fair amount of trouble (a series of exception Emask (device errors) with each of the 3 drives), but I don't know yet if that is from a more systemic problem, or just a side effect of returning to the older version. I suspect that the changes in v4.3.3 to work around the model name handling may not be completely backward compatible, so super.dat has to be regenerated.
July 28, 200817 yr I am having the same problem as well with an Asus P5PE-VM. Like in the previous case, I am getting a bunch of errors on drives. The first indication is at the "mounting of USB mass storage - UNLINK after no IRQ?" Then: ATA1.00 QC Timeout ATA1.00 failed to read native address HPA support seems broken -will skip HPA handling Failed to recover some devices - retry in 5 seconds ... and so on. It does that for all the drives (6 of them) and then the infamous "Special device /dev/disk/by-label/UNRAID does not exists" line. Unraid 4.2.4 works great. The 4.3 series just won't work. Hope this helps in finding a cure... Thanks!
November 22, 200817 yr Just thought I would say in case it helps anybody that I have now updated to 4.4 beta 2 and it seems to have solved the intermittent boot problem some people including myself were having with 4.3. It now boots every time without any problems and not only that but compared to 4.2.4 my write speeds have doubled from 12MB/s to 25MB/s and my read speeds have tripled from 20MB/s to over 60MB/s! Santan17
Archived
This topic is now archived and is closed to further replies.