Joe L. Posted July 8, 2011 Share Posted July 8, 2011 From the release notes, it would appear that a lot of the 'MBR unknown' checks have been removed. However, from what is written, it is not clear whether multiple partitions will still cause the checks to fail. As long as there exists a "partition 1" on the Cache drive, the Cache drive will not be re-partitioned. Also note that the Cache drive can have any of these file systems: reiserfs, ntfs (readonly), ext2/3/4 (though 'lost+found' will appear as a share). If ever unRaid formats the Cache drive however, currently will always build reiserfs. Ha! a read-only NTFS cache drive... Not too useful as a "cache" drive, is it? Will it mount as writable if we load the ntfs-3g driver? Joe L. The idea was that if you had an NTFS-formatted drive you could plug into the Cache slot and be able to access files contained therein. It's a work-in-process but I thought I'd mention it in case someone plugs one in (or plugs in an ext2/3/4). Good point.. Actually, it might make data migration easier for many. Will it also work for the Apple HFS formatted drives? the HFS driver is included, but not normally loaded. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 From the release notes, it would appear that a lot of the 'MBR unknown' checks have been removed. However, from what is written, it is not clear whether multiple partitions will still cause the checks to fail. As long as there exists a "partition 1" on the Cache drive, the Cache drive will not be re-partitioned. Also note that the Cache drive can have any of these file systems: reiserfs, ntfs (readonly), ext2/3/4 (though 'lost+found' will appear as a share). If ever unRaid formats the Cache drive however, currently will always build reiserfs. Ha! a read-only NTFS cache drive... Not too useful as a "cache" drive, is it? Will it mount as writable if we load the ntfs-3g driver? Joe L. The idea was that if you had an NTFS-formatted drive you could plug into the Cache slot and be able to access files contained therein. It's a work-in-process but I thought I'd mention it in case someone plugs one in (or plugs in an ext2/3/4). Good point.. Actually, it might make data migration easier for many. Will it also work for the Apple HFS formatted drives? the HFS driver is included, but not normally loaded. Forgot about that one, yes "should" work, but I have never tested it. Also FAT should work too. So the list of permitted file systems for the cache disk is: reiserfs, ntfs (readonly), ext2/3/4, hfs, fat. Edit: I should emphasize that what happens is when cache disk partition 1 is mounted, the "auto" option is given to mount command. So if disk is formatted with any above file system it will get mounted. However, there may be other issues, e.g., permissions. Again, this is not really a "published feature". Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 The unMENU package to exclude directories with a leading underscore will not have any effect, since there is no longer any logic to exclude directories with any leading character. The script will do no harm though, it will just have no effect at all. Actually there is logic to explicitly exclude top level directories starting with a "." character by virtue of bash's "dotglob" not being set. The third unMENU package to eliminate extra syslog entries will edit the mover script, but have no effect either, it will relocate the "-print" argument from the end of one line to the beginning of the next, essentially making no change. I think this was corrected a few rev's back in the stock mover script, correct? Quote Link to comment
SSD Posted July 8, 2011 Share Posted July 8, 2011 Update: This was a false alarm. Ok - I installed beta8 and started a non-correcting parity check. It immediately got 60 sync errors. I did it twice to confirm it was not correcting the errors. I didn't think I had any parity errors in beta7, so rebooted. Sure enough, a beta7 non-correcting parity check did not show any sync errors. Here are the sync errors from the beta8 log: Jul 7 21:29:54 Shark kernel: md: parity incorrect: 128 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1576 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1584 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1592 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1600 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1608 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1616 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1624 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1632 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1640 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1648 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1656 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1664 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1672 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1680 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1688 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1696 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1704 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1712 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1720 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1728 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1736 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1744 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1752 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1760 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1768 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1776 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 1784 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31392 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31400 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31408 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31416 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31424 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31432 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31440 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31448 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31456 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31464 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31472 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31480 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31488 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31496 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31504 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31512 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31520 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31528 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31536 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31544 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31552 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31560 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31568 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31576 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31584 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31592 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31600 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31608 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31616 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 31624 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 65680 Jul 7 21:29:54 Shark kernel: md: parity incorrect: 65688 Quote Link to comment
Joe L. Posted July 8, 2011 Share Posted July 8, 2011 The unMENU package to exclude directories with a leading underscore will not have any effect, since there is no longer any logic to exclude directories with any leading character. The script will do no harm though, it will just have no effect at all. Actually there is logic to explicitly exclude top level directories starting with a "." character by virtue of bash's "dotglob" not being set. The third unMENU package to eliminate extra syslog entries will edit the mover script, but have no effect either, it will relocate the "-print" argument from the end of one line to the beginning of the next, essentially making no change. I think this was corrected a few rev's back in the stock mover script, correct? True... on both. (I overlooked that fact about "dotglob") Since you now loop on the directory names present on /mnt/user/*, it will not see the hidden directories, and they will not be moved. This change in logic will impact those who were writing directly to the cache drive, since if they create a new top level directory on the cache drive, it will stay on the cache drive until they create the equivalent directory on a data disk. (I do like the new change... it is much easier to understand) Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 This change in logic will impact those who were writing directly to the cache drive, since if they create a new top level directory on the cache drive, it will stay on the cache drive until they create the equivalent directory on a data disk. Yes that's right with one caveat: if you write files to that share and eventually the cache disk fills up, then it will start writing onto the array. But if you go to the "Share settings" for that share and specify it's cache usage as "only", then if the cache disk is full, the operation will terminate with "out of space" error. This is true even if the directory exists on the array as well. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 Ok - I installed beta8 and started a non-correcting parity check. It immediately got 60 sync errors. I did it twice to confirm it was not correcting the errors. I didn't think I had any parity errors in beta7, so rebooted. Sure enough, a beta7 non-correcting parity check did not show any sync errors. You're saying, if you boot beta7 and run Check/nocorrect, you get no sync errors; then if you boot beta8 and run Check/nocorrect, you do get sync errors; then if you go back to beta7 and run Check/nocorrect again you get no sync errors? No disk errors either, correct? If this is true, please reconfirm. Quote Link to comment
SSD Posted July 8, 2011 Share Posted July 8, 2011 Ok - I installed beta8 and started a non-correcting parity check. It immediately got 60 sync errors. I did it twice to confirm it was not correcting the errors. I didn't think I had any parity errors in beta7, so rebooted. Sure enough, a beta7 non-correcting parity check did not show any sync errors. You're saying, if you boot beta7 and run Check/nocorrect, you get no sync errors; then if you boot beta8 and run Check/nocorrect, you do get sync errors; then if you go back to beta7 and run Check/nocorrect again you get no sync errors? No disk errors either, correct? If this is true, please reconfirm. I tried to reconfirm - but looks like when I started the second parity check under beta8 (before booting back into beta7), I ran a CORRECTing check (I thought since I had clicked the checkbox to run a noncorrecting check, that it would stay that way, but when I just reverified, I see the checkbox gets rechecked after each check completes.) I did have a power outage a day ot two ago, but server was connected to a UPS and server came up clean without running a parity check. I didn't think anything of it. That's the only idea why I got sync errors. Does not seem to be a difference in beta7 and beta8 behavior. Sorry for the false alarm. Quote Link to comment
JM2005 Posted July 8, 2011 Share Posted July 8, 2011 I also noticed that it defaults to Correct any Parity-Check errors by writing the Parity disk with corrected parity with the check mark there. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 I also noticed that it defaults to Correct any Parity-Check errors by writing the Parity disk with corrected parity with the check mark there. Right, default behavior in 5.0 is same as all previous unRaid releases: a) Before the correct/nocorrect feature was introduced, if the array was started, and the disk config was valid (no changes), and this is a startup following an un-clean shutdown, then an automatic "parity check/correct" was started at the same time the array was started. Pre-beta8 behavior under same cicumstances is to start a "parity check/nocorrect". I think this is wrong and in beta8 it has been changed to "parity check/correct". b) The default state of the Checkbox that says whether to correct or not correct parity check errors is "not checked". Again, I think this is wrong and in beta8 it has been changed to be checked by default. The reasoning behind both changes is similar. First, I want the behavior to be the same for people migrating from 4.7 to 5.0, where CORRECT is the action that takes place. But second (and more importantly), in almost all cases you really do want to CORRECT parity check errors (that is, write parity disk with corrected data). The reason for this is that parity needs to be correct in order to reliably re-build any data disk in the array - not just the one that was improperly written. By not correcting parity errors, if some other disk fails, you now have two disks with bad data somewhere: the original disk that didn't get written, and the reconstructed disk that now has incorrect reconstructed data. In tracking down the parity sync errors being reported, I had to review all the code in the driver having to do with parity sync/check/rebuild, etc., and re-realize why this is the correct thing to do. In addition, since reiserfs is a journal file system, any metadata issues on individual disks should be corrected by transaction replays when the disks are mounted. While on the subject... Parity disk being "valid" means that there is a parity disk present, and sometime in the past a parity sync completed without error (or being cancelled). Once parity sync has completed, the parity disk will always be "valid" (and have a green dot). "Valid" in this sense means that it can be used to reconstruct a failed data disk. Actually, "valid" is a status that applies to all array disks, both data disks and the parity disk. If all array disks are valid except for one of them, it means that the one that's not valid can be reconstructed using the data from all the other ones. I've seen confusion arise from users when a parity check/nocorrect produces errors, and they wonder why the Parity disk is now still "valid". The answer is this: if the s/w marked the parity disk "invalid" because of a handful of parity errors, then another disk fails, that other disk can not be reconstructed (because now you have 2 invalid disks in the array). So I don't want to mark the entire parity disk invalid because of detected parity errors. Of course user can always deem parity invalid by un-assigning it. So maybe "valid/invalid" is an unfortunate choice of terms, but on the other hand, if all parity checks were the "CORRECT" variety, this case would never come up because at end of such a check parity is "totally valid" at the end. One other thing about parity - once parity has been calculated there should only be 2 ways that there should be parity check errors: a) a non-clean shutdown, ie, sudden power loss or system reset. What happens here is there could be pending writes to the parity and/or data disks which don't get completed, leaving corresponding stripe with inconsistent parity. b) undetected hardware fault (such as silent memory corruption). Well I guess there's a third: software bug. Quote Link to comment
JM2005 Posted July 8, 2011 Share Posted July 8, 2011 Tom thanks for explaining that so well. I have a better understanding of it all now. Quote Link to comment
ajeffco Posted July 8, 2011 Share Posted July 8, 2011 Plus key issue is fixed, thanks much Tom. Quote Link to comment
mikejp Posted July 8, 2011 Share Posted July 8, 2011 Just went from beta7 to beta8. Works fine except... now the temps don't show for the drives hooked to the motherboard. The temps show fine on the 2 BR10i cards with both betas. Motherboard is a GIGABYTE GA-790XT-USB3. Syslogs from both versions attached. syslog_b7.zip syslog_b8.zip Quote Link to comment
Thornwood Posted July 8, 2011 Share Posted July 8, 2011 Hello I just found something weird, I just updated from 5b7 to 5b8a and my flash drive shows completely full with no empty space in either smb or main page. Because of this Unmenu wood not boot because of a divide by 0 error. I removed the drive and checked it and it is formatted fat32 and I did a check disk with no problems. If I return to 5b7 it shows the correct amount of free space. Please help. See log of 5b8a and 5b7 log.zip Quote Link to comment
madburg Posted July 8, 2011 Share Posted July 8, 2011 Tom, I wanted to report that the "- emhttp: fixed issue where disk 'Spin down delay' could get erroneously set to 'never'" is looking good. I started a new flash from scratch. Loaded 5.0Beta8a. Only configured the network.cfg (hard code IP and DNS entries). Booted up, then set up all my configurations in MAIN including settting "Disk Settings" to 15 minutes for "Default spin down delay" and clicked "Apply" then "Done". and this was before I assigned ANY disks. I then proceeded to assigned 13 disk in various Disk #'s and did not even reboot. All 13 disks spun down now with 5.0 Beta8a. Good job! Thank you for this fix. for AFP, Noticed "netatalk" in the syslog viewer: Jul 8 00:00:48 Tower afpd[1949]: uam: loading (/etc/netatalk/uams/uams_guest.so) Jul 8 00:00:48 Tower afpd[1949]: uam: uams_guest.so loaded Jul 8 00:00:48 Tower afpd[1949]: uam: loading (/etc/netatalk/uams/uams_dhx2.so) Jul 8 00:00:48 Tower afpd[1949]: uam: uams_dhx2.so loaded Jul 8 00:00:48 Tower afpd[1949]: uam: "DHX2" available Jul 8 00:00:48 Tower afpd[1949]: uam: "No User Authent" available Jul 8 00:00:48 Tower afpd[1949]: Finished parsing Config File Did not notice anything about this in the release notes. Something new? Moving on to spinning up the drives, then stopping the array (I would get all disks displaying unformatted and then only option was to click stop again and then it would crash) and going to try and reboot. I will post results. If I did this procedure quickly after server booted up it was always fine, its after it was up for a while (many hours or 1+ days this crashed 1 out of 2 times in 5.0beta7 for me.) Quote Link to comment
madburg Posted July 8, 2011 Share Posted July 8, 2011 I did get the "Mounting" and "Resizing" statements when I started the array, waited a few seconds refreshed and as you stated they went away. But reading the thread I get a "-" under "Free" for the flash drive, and under 5.0Beta7 it had stated "3.74 GB" under "Free" so something is weird here. Screenshots attached. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 Just went from beta7 to beta8. Works fine except... now the temps don't show for the drives hooked to the motherboard. The temps show fine on the 2 BR10i cards with both betas. Motherboard is a GIGABYTE GA-790XT-USB3. Syslogs from both versions attached. Pick one of your drives hooked to the motherboard and note the device identifier, say it's (sdb). Please type this command, capture output and post: smartctl -A /dev/sdb <--- instead of 'sdb' use whatever one corresponds to drive on motherboard port Quote Link to comment
madburg Posted July 8, 2011 Share Posted July 8, 2011 Syslog once I clicked "Stop" array: Jul 8 01:06:48 Tower emhttp: shcmd (313): /usr/local/sbin/emhttp_event stopping_svcs Jul 8 01:06:48 Tower emhttp_event: stopping_svcs Jul 8 01:06:48 Tower emhttp: Stop SMB... Jul 8 01:06:48 Tower emhttp: shcmd (314): /etc/rc.d/rc.samba stop |& logger Jul 8 01:06:48 Tower emhttp: Stop NFS... Jul 8 01:06:48 Tower emhttp: shcmd (315): /etc/rc.d/rc.nfsd stop |& logger Jul 8 01:06:49 Tower emhttp: Stop AFP... Jul 8 01:06:49 Tower emhttp: shcmd (316): /etc/rc.d/rc.atalk stop |& logger Jul 8 01:06:49 Tower afpd[1949]: shutting down on signal 15 Jul 8 01:06:49 Tower emhttp: Stop AVAHI... Jul 8 01:06:49 Tower emhttp: shcmd (317): /etc/rc.d/rc.avahidaemon stop |& logger Jul 8 01:06:49 Tower logger: Stopping Avahi mDNS/DNS-SD Daemon: stopped Jul 8 01:06:49 Tower avahi-daemon[1962]: Got SIGTERM, quitting. Jul 8 01:06:49 Tower avahi-dnsconfd[1973]: read(): EOF Jul 8 01:06:49 Tower avahi-daemon[1962]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.190. Jul 8 01:06:49 Tower emhttp: shcmd (318): /etc/rc.d/rc.avahidnsconfd stop |& logger Jul 8 01:06:49 Tower logger: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Jul 8 01:06:49 Tower emhttp: Spinning up all drives... Jul 8 01:06:49 Tower emhttp: Sync filesystems... Jul 8 01:06:49 Tower emhttp: shcmd (319): sync Jul 8 01:06:49 Tower kernel: mdcmd (66): spinup 2 Jul 8 01:06:49 Tower kernel: mdcmd (67): spinup 3 Jul 8 01:06:49 Tower kernel: mdcmd (68): spinup 4 Jul 8 01:06:49 Tower kernel: mdcmd (69): spinup 5 Jul 8 01:06:49 Tower kernel: mdcmd (70): spinup 6 Jul 8 01:06:49 Tower kernel: mdcmd (71): spinup 7 Jul 8 01:06:49 Tower kernel: mdcmd (72): spinup 8 Jul 8 01:06:49 Tower kernel: mdcmd (73): spinup 10 Jul 8 01:06:49 Tower kernel: mdcmd (74): spinup 16 Jul 8 01:06:49 Tower kernel: mdcmd (75): spinup 17 Jul 8 01:06:49 Tower kernel: mdcmd (76): spinup 18 Jul 8 01:06:49 Tower kernel: mdcmd (77): spinup 19 Jul 8 01:06:49 Tower kernel: mdcmd (78): spinup 20 Jul 8 01:07:02 Tower emhttp: shcmd (320): /usr/local/sbin/emhttp_event unmounting_disks Jul 8 01:07:02 Tower emhttp_event: unmounting_disks Jul 8 01:07:02 Tower emhttp: Unmounting disks... Jul 8 01:07:02 Tower emhttp: shcmd (321): umount /mnt/disk2 &> /dev/null Jul 8 01:07:02 Tower emhttp: shcmd (322): rmdir /mnt/disk2 &>/dev/null Jul 8 01:07:02 Tower emhttp: shcmd (323): umount /mnt/disk3 &> /dev/null Jul 8 01:07:02 Tower emhttp: shcmd (324): rmdir /mnt/disk3 &>/dev/null Jul 8 01:07:02 Tower emhttp: shcmd (325): umount /mnt/disk4 &> /dev/null Jul 8 01:07:03 Tower emhttp: shcmd (326): rmdir /mnt/disk4 &>/dev/null Jul 8 01:07:03 Tower emhttp: shcmd (327): umount /mnt/disk5 &> /dev/null Jul 8 01:07:03 Tower emhttp: shcmd (328): rmdir /mnt/disk5 &>/dev/null Jul 8 01:07:03 Tower emhttp: shcmd (329): umount /mnt/disk6 &> /dev/null Jul 8 01:07:03 Tower emhttp: shcmd (330): rmdir /mnt/disk6 &>/dev/null Jul 8 01:07:03 Tower emhttp: shcmd (331): umount /mnt/disk7 &> /dev/null Jul 8 01:07:03 Tower emhttp: shcmd (332): rmdir /mnt/disk7 &>/dev/null Jul 8 01:07:03 Tower emhttp: shcmd (333): umount /mnt/disk8 &> /dev/null Jul 8 01:07:03 Tower emhttp: shcmd (334): rmdir /mnt/disk8 &>/dev/null Jul 8 01:07:03 Tower emhttp: shcmd (335): umount /mnt/disk10 &> /dev/null Jul 8 01:07:04 Tower emhttp: shcmd (336): rmdir /mnt/disk10 &>/dev/null Jul 8 01:07:04 Tower emhttp: shcmd (337): umount /mnt/disk16 &> /dev/null Jul 8 01:07:04 Tower emhttp: shcmd (338): rmdir /mnt/disk16 &>/dev/null Jul 8 01:07:04 Tower emhttp: shcmd (339): umount /mnt/disk17 &> /dev/null Jul 8 01:07:04 Tower emhttp: shcmd (340): rmdir /mnt/disk17 &>/dev/null Jul 8 01:07:04 Tower emhttp: shcmd (341): umount /mnt/disk18 &> /dev/null Jul 8 01:07:04 Tower emhttp: shcmd (342): rmdir /mnt/disk18 &>/dev/null Jul 8 01:07:04 Tower emhttp: shcmd (343): umount /mnt/disk19 &> /dev/null Jul 8 01:07:04 Tower emhttp: shcmd (344): rmdir /mnt/disk19 &>/dev/null Jul 8 01:07:04 Tower emhttp: shcmd (345): umount /mnt/disk20 &> /dev/null Jul 8 01:07:04 Tower kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jul 8 01:07:04 Tower kernel: IP: [] queue_delayed_work_on+0x33/0xbf Jul 8 01:07:04 Tower kernel: *pdpt = 0000000029c1e001 *pde = 0000000000000000 Jul 8 01:07:04 Tower kernel: Oops: 0000 [#1] SMP Jul 8 01:07:04 Tower kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/host7/target7:0:0/7:0:0:0/block/sdh/stat Jul 8 01:07:04 Tower kernel: Modules linked in: md_mod xor ahci libahci i2c_i801 i2c_core e1000e mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod] Jul 8 01:07:04 Tower kernel: Jul 8 01:07:04 Tower kernel: Pid: 8487, comm: umount Not tainted 2.6.37.6-unRAID #3 Supermicro X8SIE/X8SIE Jul 8 01:07:04 Tower kernel: EIP: 0060:[] EFLAGS: 00210246 CPU: 4 Jul 8 01:07:04 Tower kernel: EIP is at queue_delayed_work_on+0x33/0xbf Jul 8 01:07:04 Tower kernel: EAX: f8eef138 EBX: ffffffff ECX: f8eef134 EDX: 00000000 Jul 8 01:07:04 Tower kernel: ESI: 00000000 EDI: f8eef134 EBP: eea55e44 ESP: eea55e38 Jul 8 01:07:04 Tower kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jul 8 01:07:04 Tower kernel: Process umount (pid: 8487, ti=eea54000 task=ee2ba7c0 task.ti=eea54000) Jul 8 01:07:04 Tower kernel: Stack: Jul 8 01:07:04 Tower kernel: f8edf000 f75bd554 f75bd500 eea55e50 c1038a6f 0000000a eea55eb4 c10d467a Jul 8 01:07:04 Tower kernel: f8edf000 00000012 00000000 ee715498 00000dfb 03b89d50 00000000 00000010 Jul 8 01:07:04 Tower kernel: f75bd518 00000012 00000004 f8edf000 00001ad4 00000000 eef5d000 ef76bbc0 Jul 8 01:07:04 Tower kernel: Call Trace: Jul 8 01:07:04 Tower kernel: [] ? queue_delayed_work+0x1b/0x1e Jul 8 01:07:04 Tower kernel: [] ? do_journal_end+0x747/0x92a Jul 8 01:07:04 Tower kernel: [] ? journal_end_sync+0x5b/0x63 Jul 8 01:07:04 Tower kernel: [] ? reiserfs_sync_fs+0x32/0x51 Jul 8 01:07:04 Tower kernel: [] ? __sync_filesystem+0x53/0x65 Jul 8 01:07:04 Tower kernel: [] ? sync_filesystem+0x2c/0x40 Jul 8 01:07:04 Tower kernel: [] ? generic_shutdown_super+0x1d/0xb5 Jul 8 01:07:04 Tower kernel: [] ? kill_block_super+0x1d/0x31 Jul 8 01:07:04 Tower kernel: [] ? reiserfs_kill_sb+0x7d/0x80 Jul 8 01:07:04 Tower kernel: [] ? deactivate_locked_super+0x1a/0x36 Jul 8 01:07:04 Tower kernel: [] ? deactivate_super+0x32/0x36 Jul 8 01:07:04 Tower kernel: [] ? mntput_no_expire+0xb0/0xcc Jul 8 01:07:04 Tower kernel: [] ? sys_umount+0x8f/0x98 Jul 8 01:07:04 Tower kernel: [] ? sys_oldumount+0xd/0xf Jul 8 01:07:04 Tower kernel: [] ? syscall_call+0x7/0xb Jul 8 01:07:04 Tower kernel: Code: d6 53 89 c3 f0 0f ba 29 00 19 d2 31 c0 85 d2 0f 85 9d 00 00 00 83 79 10 00 74 04 0f 0b eb fe 8d 41 04 39 41 04 74 04 0f 0b eb fe 06 02 b8 08 00 00 00 75 19 89 c8 e8 9d e6 ff ff 85 c0 74 08 Jul 8 01:07:04 Tower kernel: EIP: [] queue_delayed_work_on+0x33/0xbf SS:ESP 0068:eea55e38 Jul 8 01:07:04 Tower kernel: CR2: 0000000000000000 Jul 8 01:07:04 Tower kernel: ---[ end trace 1b4f077bd650b9e7 ]--- Jul 8 01:07:04 Tower emhttp: _shcmd: shcmd (345): exit status: -119 Jul 8 01:07:04 Tower emhttp: shcmd (346): rmdir /mnt/disk20 &>/dev/null Jul 8 01:07:04 Tower emhttp: Retry unmounting disk share(s)... Jul 8 01:07:09 Tower emhttp: Unmounting disks... Jul 8 01:07:09 Tower emhttp: shcmd (347): /usr/local/sbin/emhttp_event stopping_array Jul 8 01:07:09 Tower emhttp_event: stopping_array Jul 8 01:07:09 Tower emhttp: mdcmd: write: Device or resource busy Jul 8 01:07:09 Tower kernel: mdcmd (79): stop Jul 8 01:07:09 Tower kernel: md: 2 devices still in use. Jul 8 01:07:10 Tower emhttp: shcmd (348): /usr/local/sbin/emhttp_event stopped Jul 8 01:07:10 Tower emhttp_event: stopped Jul 8 01:07:10 Tower emhttp: shcmd (349): :>/etc/samba/smb-shares.conf Jul 8 01:07:10 Tower emhttp: shcmd (350): cp /etc/netatalk/AppleVolumes.default- /etc/netatalk/AppleVolumes.default Jul 8 01:07:10 Tower emhttp: Start SMB... Jul 8 01:07:10 Tower emhttp: shcmd (351): /etc/rc.d/rc.samba start |& logger Jul 8 01:07:10 Tower logger: Starting Samba: /usr/sbin/nmbd -D Jul 8 01:07:10 Tower logger: /usr/sbin/smbd -D Jul 8 01:07:10 Tower emhttp: Start AFP... Jul 8 01:07:10 Tower emhttp: shcmd (352): /etc/rc.d/rc.atalk start |& logger Jul 8 01:07:10 Tower afpd[8545]: Registering CNID module [last] Jul 8 01:07:10 Tower afpd[8545]: Registering CNID module [cdb] Jul 8 01:07:10 Tower afpd[8545]: Registering CNID module [dbd] Jul 8 01:07:10 Tower logger: starting appletalk daemons: cnid_metad afpd Jul 8 01:07:10 Tower afpd[8545]: Loading ConfigFile Jul 8 01:07:10 Tower emhttp: Start AVAHI... Jul 8 01:07:10 Tower emhttp: shcmd (353): /etc/rc.d/rc.avahidaemon start |& logger Jul 8 01:07:10 Tower afpd[8545]: main: atp_open: Address family not supported by protocol Jul 8 01:07:10 Tower afpd[8545]: dsi_tcp: hostname 'PNTower' resolves to loopback address Jul 8 01:07:10 Tower afpd[8545]: dsi_tcp: '192.168.0.190' on interface 'eth0' will be used instead. Jul 8 01:07:10 Tower afpd[8545]: ASIP started on 192.168.0.190:548(5) (2.0.5) Jul 8 01:07:10 Tower afpd[8545]: uam: loading (/etc/netatalk/uams/uams_guest.so) Jul 8 01:07:10 Tower afpd[8545]: uam: uams_guest.so loaded Jul 8 01:07:10 Tower afpd[8545]: uam: loading (/etc/netatalk/uams/uams_dhx2.so) Jul 8 01:07:10 Tower afpd[8545]: uam: uams_dhx2.so loaded Jul 8 01:07:10 Tower afpd[8545]: uam: "DHX2" available Jul 8 01:07:10 Tower afpd[8545]: uam: "No User Authent" available Jul 8 01:07:10 Tower afpd[8545]: Finished parsing Config File Jul 8 01:07:10 Tower logger: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Jul 8 01:07:10 Tower avahi-daemon[8558]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Jul 8 01:07:10 Tower avahi-daemon[8558]: Successfully dropped root privileges. Jul 8 01:07:10 Tower avahi-daemon[8558]: avahi-daemon 0.6.25 starting up. Jul 8 01:07:10 Tower avahi-daemon[8558]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Jul 8 01:07:10 Tower avahi-daemon[8558]: Successfully called chroot(). Jul 8 01:07:10 Tower avahi-daemon[8558]: Successfully dropped remaining capabilities. Jul 8 01:07:10 Tower avahi-daemon[8558]: Loading service file /services/afpd.service. Jul 8 01:07:10 Tower avahi-daemon[8558]: Loading service file /services/samba.service. Jul 8 01:07:10 Tower avahi-daemon[8558]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.190. Jul 8 01:07:10 Tower avahi-daemon[8558]: New relevant interface eth0.IPv4 for mDNS. Jul 8 01:07:10 Tower avahi-daemon[8558]: Network interface enumeration completed. Jul 8 01:07:10 Tower avahi-daemon[8558]: Registering new address record for 192.168.0.190 on eth0.IPv4. Jul 8 01:07:10 Tower avahi-daemon[8558]: Registering HINFO record with values 'I686'/'LINUX'. Jul 8 01:07:10 Tower emhttp: shcmd (354): /etc/rc.d/rc.avahidnsconfd start |& logger Jul 8 01:07:10 Tower logger: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Jul 8 01:07:10 Tower avahi-dnsconfd[8569]: Successfully connected to Avahi daemon. Jul 8 01:07:10 Tower emhttp: shcmd (355): /usr/local/sbin/emhttp_event svcs_started Jul 8 01:07:10 Tower emhttp_event: svcs_started Jul 8 01:07:11 Tower avahi-daemon[8558]: Server startup complete. Host name is PNTower.local. Local service cookie is 1758179236. Jul 8 01:07:12 Tower avahi-daemon[8558]: Service "PNTower-SMB" (/services/samba.service) successfully established. Jul 8 01:07:12 Tower avahi-daemon[8558]: Service "PNTower" (/services/afpd.service) successfully established. Anything out of the ordinary above, Tom? Array Never stopped, I did not get "unformatted" disks like in 5.0Beta7 but it came back with the array still started. Waited 7 minutes click stop array again. Hung: Jul 8 01:07:12 Tower avahi-daemon[8558]: Service "PNTower" (/services/afpd.service) successfully established. Jul 8 01:14:57 Tower emhttp: shcmd (356): /usr/local/sbin/emhttp_event stopping_svcs Jul 8 01:14:57 Tower emhttp_event: stopping_svcs Jul 8 01:14:57 Tower emhttp: Stop SMB... Jul 8 01:14:57 Tower emhttp: shcmd (357): /etc/rc.d/rc.samba stop |& logger Jul 8 01:14:57 Tower emhttp: Stop NFS... Jul 8 01:14:57 Tower emhttp: shcmd (358): /etc/rc.d/rc.nfsd stop |& logger Jul 8 01:14:58 Tower emhttp: Stop AFP... Jul 8 01:14:58 Tower emhttp: shcmd (359): /etc/rc.d/rc.atalk stop |& logger Jul 8 01:14:58 Tower afpd[8545]: shutting down on signal 15 Jul 8 01:14:58 Tower emhttp: Stop AVAHI... Jul 8 01:14:58 Tower emhttp: shcmd (360): /etc/rc.d/rc.avahidaemon stop |& logger Jul 8 01:14:58 Tower logger: Stopping Avahi mDNS/DNS-SD Daemon: stopped Jul 8 01:14:58 Tower avahi-daemon[8558]: Got SIGTERM, quitting. Jul 8 01:14:58 Tower avahi-dnsconfd[8569]: read(): EOF Jul 8 01:14:58 Tower avahi-daemon[8558]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.190. Jul 8 01:14:58 Tower emhttp: shcmd (361): /etc/rc.d/rc.avahidnsconfd stop |& logger Jul 8 01:14:58 Tower logger: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Jul 8 01:14:58 Tower emhttp: Spinning up all drives... Jul 8 01:14:58 Tower emhttp: Sync filesystems... Jul 8 01:14:58 Tower emhttp: shcmd (362): sync Jul 8 01:14:58 Tower kernel: mdcmd (80): spinup 2 Jul 8 01:14:58 Tower kernel: mdcmd (81): spinup 3 Jul 8 01:14:58 Tower kernel: mdcmd (82): spinup 4 Jul 8 01:14:58 Tower kernel: mdcmd (83): spinup 5 Jul 8 01:14:58 Tower kernel: mdcmd (84): spinup 6 Jul 8 01:14:58 Tower kernel: mdcmd (85): spinup 7 Jul 8 01:14:58 Tower kernel: mdcmd (86): spinup 8 Jul 8 01:14:58 Tower kernel: mdcmd (87): spinup 10 Jul 8 01:14:58 Tower kernel: mdcmd (88): spinup 16 Jul 8 01:14:58 Tower kernel: mdcmd (89): spinup 17 Jul 8 01:14:58 Tower kernel: mdcmd (90): spinup 18 Jul 8 01:14:58 Tower kernel: mdcmd (91): spinup 19 Jul 8 01:14:58 Tower kernel: mdcmd (92): spinup 20 Screenshot of what the browser is displaying, syslog viewer and tail from telnet session. You will have to scroll to the right as it is a very wide image to get all 3 windows in one screenshot. Quote Link to comment
speeding_ant Posted July 8, 2011 Share Posted July 8, 2011 Well, just upgraded. It was successful, as far as I can tell. No more MBR:unknown issues. All disks are either MBR:unaligned, or MBR:aligned. I figured it was safe to start the array, and it kicked off a parity sync. Presuming this is because I erased the super.dat file, initializing the disk config? Anyway, all looks well so far. Thanks! Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 Hello I just found something weird, I just updated from 5b7 to 5b8a and my flash drive shows completely full with no empty space in either smb or main page. Because of this Unmenu wood not boot because of a divide by 0 error. I removed the drive and checked it and it is formatted fat32 and I did a check disk with no problems. If I return to 5b7 it shows the correct amount of free space. Please help. See log of 5b8a and 5b7 Right, that's not good New release -beta8b corrects this problem. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 Syslog once I clicked "Stop" array: ... There is a crash of the 'umount' command being recorded in you system log - this is not good. Looks like it's with you disk20. Please run a 'reiserfsck' on this disk. Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 I figured it was safe to start the array, and it kicked off a parity sync. Presuming this is because I erased the super.dat file, initializing the disk config? That's right. Quote Link to comment
peter_sm Posted July 8, 2011 Share Posted July 8, 2011 Thanks for the new beta, but I can't longer access unmenu ? http://tower:8080/ edit: Added a log file. 8 08:36:09 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:36:09 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:36:09 Tower unmenu[3669]: unmenu.awk unable to open port. It may already be running Jul 8 08:36:19 Tower unmenu-status: Starting unmenu web-server Jul 8 08:36:36 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:36:36 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:36:36 Tower unmenu[3669]: unmenu.awk unable to open port. It may already be running Jul 8 08:36:46 Tower unmenu-status: Starting unmenu web-server Jul 8 08:37:18 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:37:18 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:37:18 Tower unmenu-error: Fatal error:Exiting uu, unmenu may already be running, exit status=2 systemlog.zip Quote Link to comment
limetech Posted July 8, 2011 Author Share Posted July 8, 2011 Thanks for the new beta, but I can't longer access unmenu ? http://tower:8080/ edit: Added a log file. 8 08:36:09 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:36:09 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:36:09 Tower unmenu[3669]: unmenu.awk unable to open port. It may already be running Jul 8 08:36:19 Tower unmenu-status: Starting unmenu web-server Jul 8 08:36:36 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:36:36 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:36:36 Tower unmenu[3669]: unmenu.awk unable to open port. It may already be running Jul 8 08:36:46 Tower unmenu-status: Starting unmenu web-server Jul 8 08:37:18 Tower unmenu[3669]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 08:37:18 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 08:37:18 Tower unmenu-error: Fatal error:Exiting uu, unmenu may already be running, exit status=2 Try -beta8b. 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.