June 12, 201115 yr Author Does the beta7 release still consider an MBR in use under 4.7 as described in this post as unknown? If some other code modifies the MBR then this could cause unRaid to treat it as "unknown". I would not consider this a bug because the s/w is being used in a manner that I don't test with. A workaround is to use grub instead of lilo.
June 12, 201115 yr Author this "bug" is still being reported, although it probably does not affect the data in the unRAID array unless the syslog fills all available memory. Jun 8 04:40:01 Tower logrotate: ALERT - exited abnormally. Fixed in next beta.
June 12, 201115 yr Author In my testing, this version does all these functions successfully (except for the bug I reported earlier). Which post are you referring to? Read this post that explains the steps leading up to the bug: Prior Post And this post that explains the bug (sync errors after rebuild of MBR to GPT): Bug described here Do you have the system log from when this rebuild occurred? If not, please try and recreate; I've never seen the start of reconstruct 'hang' the webGui or transparently fail in a manner that produces sync errors.
June 12, 201115 yr In my testing, this version does all these functions successfully (except for the bug I reported earlier). Which post are you referring to? Read this post that explains the steps leading up to the bug: Prior Post And this post that explains the bug (sync errors after rebuild of MBR to GPT): Bug described here Do you have the system log from when this rebuild occurred? If not, please try and recreate; I've never seen the start of reconstruct 'hang' the webGui or transparently fail in a manner that produces sync errors. Here is the syslog. Line 1345 - Reconstucted parity onto 3T disk Line 2391 - The 3T drive was assigned to rebuild disk11 (serial number ends with 4WC) Line 2721 to line 2722 - 6 1/2 minute delay. The rebuild was going (i could see it by monitoring in unmenu, but emhttp was unresponsive. I tried launching another web browser session for the unRAID GUI, but it never loaded). Line 2760 you'll see the 4 parity errors. syslog-2011-06-12.zip
June 12, 201115 yr 6 1/2 minutes (re-sizing the file-system on the replacement disk perhaps??): Jun 9 19:20:16 Shark emhttp: shcmd (343): chown nobody:users '/mnt/disk3' Jun 9 19:26:44 Shark emhttp: resized: /mnt/disk11 Jun 9 19:26:44 Shark emhttp: shcmd (344): chmod 770 '/mnt/disk11'
June 12, 201115 yr 6 1/2 minutes (re-sizing the file-system on the replacement disk perhaps??): Jun 9 19:20:16 Shark emhttp: shcmd (343): chown nobody:users '/mnt/disk3' Jun 9 19:26:44 Shark emhttp: resized: /mnt/disk11 Jun 9 19:26:44 Shark emhttp: shcmd (344): chmod 770 '/mnt/disk11' Maybe there was some race condition between setting up the disk and the rebuild, because during those 6 1/2 minutes, the drive was rebuilding. ~20G was rebuilt at the time that emhttp finally returned control. I could watch the rebuild in unmenu (running the mdcmd status commands) the whole time. I've experienced similar oddities when a drive was replaying transactions after an unclean shutdown white a correcting parity check was going in the background. It sometimes takes 2 parity check cycles to clear all the errors due to this.
June 12, 201115 yr Does the beta7 release still consider an MBR in use under 4.7 as described in this post as unknown? If some other code modifies the MBR then this could cause unRaid to treat it as "unknown". I would not consider this a bug because the s/w is being used in a manner that I don't test with. A workaround is to use grub instead of lilo. And that is why I did not call it a bug. I just asked if it was still considered as "unknown". Thanks for the answer though... There is a reported share file-system "bug," but it existed in prior releases too. Apparently, it is one where the modification time of a given directory in the /mnt/user share file system is not the most recent of all the "disk" directories that are combined in that node. Because the modification time is not updated properly, it does not allow media players to properly scan for new content. Again, this does not affect stored content, but it does affect usability for those with the "plex" media player. Joe L.
June 12, 201115 yr Does the beta7 release still consider an MBR in use under 4.7 as described in this post as unknown? If some other code modifies the MBR then this could cause unRaid to treat it as "unknown". I would not consider this a bug because the s/w is being used in a manner that I don't test with. A workaround is to use grub instead of lilo. And that is why I did not call it a bug. I just asked if it was still considered as "unknown". Thanks for the answer though... There is a reported share file-system "bug," but it existed in prior releases too. Apparently, it is one where the modification time of a given directory in the /mnt/user share file system is not the most recent of all the "disk" directories that are combined in that node. Because the modification time is not updated properly, it does not allow media players to properly scan for new content. Again, this does not affect stored content, but it does affect usability for those with the "plex" media player. Joe L. This can also affect rsync.
June 12, 201115 yr Does the beta7 release still consider an MBR in use under 4.7 as described in this post as unknown? If some other code modifies the MBR then this could cause unRaid to treat it as "unknown". I would not consider this a bug because the s/w is being used in a manner that I don't test with. A workaround is to use grub instead of lilo. Is it confirmed that GRUB does not alter the MBR similarly to how LILO does?
June 13, 201115 yr Tom, Just went to download 5b7 from the main site and noticed the link to "release notes" is wrong, click on it and just sends you back to the main page. Shawn Edit - I think you are missing /wiki/ in the link...
June 13, 201115 yr Just did the upgrade from 4.7. Everything worked perfectly - now doing a parity check. The previous error, detecting some drives as MBR:Unknown, did not occur. Detected all the drives correctly. Shawn
June 13, 201115 yr Author 6 1/2 minutes (re-sizing the file-system on the replacement disk perhaps??): Jun 9 19:20:16 Shark emhttp: shcmd (343): chown nobody:users '/mnt/disk3' Jun 9 19:26:44 Shark emhttp: resized: /mnt/disk11 Jun 9 19:26:44 Shark emhttp: shcmd (344): chmod 770 '/mnt/disk11' Maybe there was some race condition between setting up the disk and the rebuild, because during those 6 1/2 minutes, the drive was rebuilding. ~20G was rebuilt at the time that emhttp finally returned control. I could watch the rebuild in unmenu (running the mdcmd status commands) the whole time. I've experienced similar oddities when a drive was replaying transactions after an unclean shutdown white a correcting parity check was going in the background. It sometimes takes 2 parity check cycles to clear all the errors due to this. As Joe suspected, the delay is due to a 'resize' taking place when the drives are initially mounted. Upon array start, here's what happens: 1. unraid driver loaded 2. driver given 'start' command - this makes 'md' devices available 3. if disabled drive replaced then parity sync started, or if previous unclean shutdown then parity check started 4. all hard drives are mounted (and resized upward if possible) 5. network protocol engines started (ie, samba, aftp, etc) So your delay is happening at step 4. Eventually this will be fixed (perhaps not next beta which I want to get this week). The resize is taking even longer because of parity-sync/check in background. As for the sync errors - still investigating this.
June 13, 201115 yr Author Does the beta7 release still consider an MBR in use under 4.7 as described in this post as unknown? If some other code modifies the MBR then this could cause unRaid to treat it as "unknown". I would not consider this a bug because the s/w is being used in a manner that I don't test with. A workaround is to use grub instead of lilo. And that is why I did not call it a bug. I just asked if it was still considered as "unknown". Thanks for the answer though... At some point this will be fixed (with feature that lets pre-formatted drive be recognized). There is a reported share file-system "bug," but it existed in prior releases too. Apparently, it is one where the modification time of a given directory in the /mnt/user share file system is not the most recent of all the "disk" directories that are combined in that node. Because the modification time is not updated properly, it does not allow media players to properly scan for new content. Again, this does not affect stored content, but it does affect usability for those with the "plex" media player. Fixed in next beta.
June 13, 201115 yr Author Tom, Just went to download 5b7 from the main site and noticed the link to "release notes" is wrong, click on it and just sends you back to the main page. Shawn Edit - I think you are missing /wiki/ in the link... Hmm. Fixed, thanks for the 'heads up'.
June 13, 201115 yr As Joe suspected, the delay is due to a 'resize' taking place when the drives are initially mounted. Upon array start, here's what happens: 1. unraid driver loaded 2. driver given 'start' command - this makes 'md' devices available 3. if disabled drive replaced then parity sync started, or if previous unclean shutdown then parity check started 4. all hard drives are mounted (and resized upward if possible) 5. network protocol engines started (ie, samba, aftp, etc) So your delay is happening at step 4. Eventually this will be fixed (perhaps not next beta which I want to get this week). The resize is taking even longer because of parity-sync/check in background. As for the sync errors - still investigating this. Coincidently there was a thread about two other users having parity sync errors at very low sectors after a rebuild (see THIS short support thread). Both on 4.7. So the issue I encountered may have nothing to do with beta 7. Just an idea - could you wait 3-4 minutes after starting the array before starting a parity check, parity sync, or rebuild? This would give time for replayed transactions to complete, drive resizing to complete, and even time for the user to bring up the Web GUI and stop the operation before it starts.
June 14, 201115 yr I bit the bullet and updated. I thought I was prepared but I had overlooked the one time permision reset and the PHP could not be installed by unmenu. I do see the bug where unmenu does not show the unraid main but if you go directly it works... It does work some times I just dont know why. the rest looks really good I am using my UPS and Twonky media with no problems. Here are a few lines in my syslog I dont understand. syslog attached. Jun 12 13:54:24 Dragon-Tower kernel: ide0: BM-DMA at 0xff00-0xff07 Jun 12 13:54:24 Dragon-Tower kernel: atiixp 0000:00:14.1: simplex device: DMA disabled (Errors) Jun 12 13:54:24 Dragon-Tower kernel: ide1: DMA disabled (Errors) Jun 12 13:54:24 Dragon-Tower kernel: Probing IDE interface ide0... Jun 12 15:15:18 Dragon-Tower kernel: twonkymediaserv[1391]: segfault at 30d0 ip 0806db70 sp b76a8af0 error 4 in twonkymediaserver[8048000+69000] (Errors) Jun 12 15:40:01 Dragon-Tower crond[1232]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jun 12 16:12:32 Dragon-Tower kernel: mdcmd (54): spindown 3 (Routine) Jun 12 16:12:33 Dragon-Tower kernel: mdcmd (55): spindown 6 (Routine) Jun 12 16:38:01 Dragon-Tower crond[1232]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Just wondering if any thing I did wrong?? Thank you syslog-2011-06-13.zip
June 14, 201115 yr Parity check and permissions done. Everything looks ok. My only issue is I can no longer access my flash share. If I browse or try to map to \\tower\flash I get the error it refers to a location that is unavailable. All my drive and user shares are fine though. The Flash has SMB set to Yes and Security set to Public. I have gone in and changed it to No, then back to Yes, can see the following: Jun 14 07:42:51 Tower emhttp: shcmd (128): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Jun 14 07:42:51 Tower emhttp: Restart SMB... Jun 14 07:42:51 Tower emhttp: shcmd (129): killall -HUP smbd Jun 14 07:42:51 Tower emhttp: shcmd (130): /usr/local/sbin/emhttp_event svcs_restarted Jun 14 07:42:51 Tower emhttp_event: svcs_restarted Looks like it should work, but no access.... Shawn
June 14, 201115 yr Updated from 5.0-beta6a to 5.0-beta7, run parity check, checked permissions etc, every looking good
June 14, 201115 yr Parity check and permissions done. Everything looks ok. My only issue is I can no longer access my flash share. If I browse or try to map to \\tower\flash I get the error it refers to a location that is unavailable. All my drive and user shares are fine though. The Flash has SMB set to Yes and Security set to Public. I have gone in and changed it to No, then back to Yes, can see the following: Jun 14 07:42:51 Tower emhttp: shcmd (128): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Jun 14 07:42:51 Tower emhttp: Restart SMB... Jun 14 07:42:51 Tower emhttp: shcmd (129): killall -HUP smbd Jun 14 07:42:51 Tower emhttp: shcmd (130): /usr/local/sbin/emhttp_event svcs_restarted Jun 14 07:42:51 Tower emhttp_event: svcs_restarted Looks like it should work, but no access.... Shawn I've had that happen o a Win7 client with my test array when I upgraded from 4.7 to 5.0b3 then to b4, b5, b6 and b6a. A reboot of the client has always fixed it though.
June 14, 201115 yr Installed on my Slackware 13.37 distro and all is working fine, after I switched over to using GRUB as the boot-loader.
June 14, 201115 yr Quick question, in the release notes it states: Upgrade Instructions - Version 5.0-beta6a 1.Prepare the flash: either shutdown your server and plug the flash into your PC or Stop the array and perform the following actions referencing the flash share on your network: Copy the files bzimage and bzroot from the zip file to the root of your flash device, overwriting the same-named files already there. 2.Reboot your server. Once boot-up has completed, you should see "Stopped. Configuration valid." array status with all disks assigned correctly. 3.Click on each disk link on the Main page and examine the Partition format field. If you see "MBR: error", or "MBR: unknown" for any disk, do not Start the array; instead post your finding in the Forum announcement thread for this release. If everything looks ok, click Start to bring the array on-line. But from reading the change log, since linux was upgraded (to version 2.6.37.6) would you not also need to do something additionally, (assuming here) update the syslinux.exe/syslinux.cfg and flash the USB partition...? I always start fresh, but want to learn this upgrade senario as my system will be production soon. I am assuming as long as the linux version does not change then only the bzimage and bzroot need updating?
June 14, 201115 yr You ONLY need to update the bzroot and bzimage files. You do not need to update the syslinux at all, regardless of linux version changes. bzimage IS the linux kernel. Starting fresh, as you described is a mistake.
June 14, 201115 yr You ONLY need to update the bzroot and bzimage files. You do not need to update the syslinux at all, regardless of linux version changes. bzimage IS the linux kernel. Starting fresh, as you described is a mistake. Thanks as always Joe L. (shows how much I know about linux 1,100 more questions and I will be able to help as well...)
June 14, 201115 yr But from reading the change log, since linux was upgraded (to version 2.6.37.6) would you not also need to do something additionally, (assuming here) update the syslinux.exe/syslinux.cfg and flash the USB partition...? syslinux is only used when formatting the memory stick, in order to make it bootable - it simply writes a bootloader to the device. The entire running system - the linux kernel, slackware and the ram disk image, together with the unRAID code, is contained within the two files loaded at boot time (bzimage and bzroot).
June 15, 201115 yr But from reading the change log, since linux was upgraded (to version 2.6.37.6) would you not also need to do something additionally, (assuming here) update the syslinux.exe/syslinux.cfg and flash the USB partition...? syslinux is only used when formatting the memory stick, in order to make it bootable - it simply writes a bootloader to the device. The entire running system - the linux kernel, slackware and the ram disk image, together with the unRAID code, is contained within the two files loaded at boot time (bzimage and bzroot). Thanks for the additional info, much appreciated.
Archived
This topic is now archived and is closed to further replies.