unRAID Server Release 5.0-beta8d Available


Recommended Posts

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.
Link to comment
  • Replies 243
  • Created
  • Last Reply

Top Posters In This Topic

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".

Link to comment

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?

 

Link to comment

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

Link to comment

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)

Link to comment

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.

Link to comment

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.

Link to comment

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.  :-[

Link to comment

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.  ::)

Link to comment

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

Link to comment

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.)

 

Link to comment

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.

Mounting_Resizing.png.c000f9b3b08c7e77455703db9b391afb.png

Link to comment

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

Link to comment

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.

 

 

CF9Dr.png

Link to comment

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!

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.