unRAID Server Release 6.0-beta8-x86_64 Available


limetech

Recommended Posts

A interesting note in 6b8: If you try xfs_check ( the primary tool for checking XFS disks) it returns with "xfs_check is deprecated and scheduled for removal in June 2014.  Please use xfs_repair -n instead." 

 

Something is wrong: code definitely uses 'xfs_repair', never used 'xfs_check'.  Where are you seeing this message?

 

Looks like the xfs_check is on its way out the door and replaced with xfs_repair -n.

 

If if did:

xfs_check /dev/sdg1

 

it returns:

xfs_check is deprecated and scheduled for removal in June 2014.

Please use xfs_repair -n <dev> instead.

 

xfs_repair -n /dev/sdg1 works just fine.

 

however its still in the man pages "xfs_check and xfs_repair can be used to cross check each other":

http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/ch11s02.html

 

found this:

https://bugzilla.redhat.com/show_bug.cgi?id=1029458

 

That's why 'Check Filesytem' button for xfs uses xfs_repair.  Why are you using 'xfs_check' from the command line?

 

Defaulted to old school:

Didn't realize the "check filesystem" was in the GUI...  I see it now...

Summary of changes from 6.0-beta6 to 6.0-beta7

"- webGui: add "check filesystem" functions on DiskInfo page."

 

Link to comment
  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Well sort of. You can replace a smaller disk with a larger disk, and your data will still be safe, right? You just won't get any of the extra space automatically at this time. Annoying for sure, but I'd still consider it "safe to use" in the context of that particular flaw, although it is obvious that there are different opinions regarding what "safe to use" means...

 

Speaking of beta software, it is certainly the case that things that “used to work” in the stable release might stop working in a beta.

 

After running betas flawlessly for a while on a dedicated lab computer I decided to try 6b8 on a more normal server that previously ran 5.0.5 flawlessly. Didn’t start too well, of course… Long story short, two disks were missing after booting 6b8, and I had to chase the problem for a bit before I could have everything up and running. Was tempted for a while to revert to my backup…

 

So what went wrong? The server in question has a Gigabyte Z87X-UD3H motherboard, and the two missing disks were both connected to the Marvell 88SE9172 chip. Combing the dmesg output, the kernel indeed detected the disks when booting, but then lost them after DMAR errors. Upgrading the BIOS didn’t help, but disabling VT-d in BIOS made everything work nicely.

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Well sort of. You can replace a smaller disk with a larger disk, and your data will still be safe, right? You just won't get any of the extra space automatically at this time. Annoying for sure, but I'd still consider it "safe to use" in the context of that particular flaw, although it is obvious that there are different opinions regarding what "safe to use" means...

 

Yes, but it is a step backward in basic NAS functionality.

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Since there are no instructions on how to expand the drive size after expansion, no it does not fully function. Part of it functions, but not all of it. Nor does it seem like there would be a separate upgrade step added in future versions, so if you replace a smaller drive with a larger drive on beta 7 or 8 there likely is no means at all to ever use the additional drive space. Ie: the feature is broken. You must downgrade to beta6 or earlier for the feature to function as intended.

Link to comment

Since there are no instructions on how to expand the drive size after expansion, no it does not fully function. Part of it functions, but not all of it. Nor does it seem like there would be a separate upgrade step added in future versions, so if you replace a smaller drive with a larger drive on beta 7 or 8 there likely is no means at all to ever use the additional drive space. Ie: the feature is broken. You must downgrade to beta6 or earlier for the feature to function as intended.

It has been stated that this expansion to fill the drive WILL work if you later boot on a release that supports this feature.  I remember seeing a post that this was temporarily disabled as it was not yet implemented for all the file systems now supported in beta 8.  I expect that will be in place by beta 9, so at that point the extra space would be used.  I can also see that as a good reason for not confusing things by posting a workaround for doing this manually if it will happen automatically at the next beta.

 

The need to do such an expansion is rare enough that I do not see this being a good reason for not running this beta. 

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Yes there is code added that changed the way expansion was done but for XFS code not added yet, so I thought, "Hey, instead of delaying the release a couple more days, let's just leave this out the for a beta release or two.  How many people using a beta will want to replace smaller disk with larger one, I bet I can get away with this and no one will notice."  Obviously someone noticed  ::)  I won't make that mistake again.

Link to comment

 

 

 

So what went wrong? The server in question has a Gigabyte Z87X-UD3H motherboard, and the two missing disks were both connected to the Marvell 88SE9172 chip. Combing the dmesg output, the kernel indeed detected the disks when booting, but then lost them after DMAR errors. Upgrading the BIOS didn’t help, but disabling VT-d in BIOS made everything work nicely.

 

OK this is an interesting theory but I fail to see the connection between VTd and the disk device drops.  I realize you performed these steps and got a good result, but what made you think to disable vtd in the first place?

 

Link to comment

Google "dmesg vtd marvell" There is a known issue with marvell chipset sata controllers and VT-d.

 

So it's HBA-specific to the marvell controller, not the motherboard or anything like that...  That's what I wanted to double-check.  We will definitely want to alert folks that are having this problem to turn that mode off.

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Yes there is code added that changed the way expansion was done but for XFS code not added yet, so I thought, "Hey, instead of delaying the release a couple more days, let's just leave this out the for a beta release or two.  How many people using a beta will want to replace smaller disk with larger one, I bet I can get away with this and no one will notice."  Obviously someone noticed  ::)  I won't make that mistake again.

 

Nope.  Just note it clearly and include the appropriate statement, "  We are testing and developing new features and sometimes that means other features  have to be disabled. if this is a problem for you, do not use betas!"

Link to comment
OK this is an interesting theory but I fail to see the connection between VTd and the disk device drops.  I realize you performed these steps and got a good result, but what made you think to disable vtd in the first place?

 

Right, probably should've mentioned the connection. I wasn't just randomly changing settings, although I realise it might have sounded like that. :D

 

After upgrading BIOS and verifying that all (reasonably related) settings still had decent values, I started looking up the error messages more thoroughly and the trace eventually led to a discussion about VT-d. Archedraft's suggestion of googling "dmesg vtd marvell" probably says it all, but if needed I could provide dmesg output with the problem.

Link to comment
Archedraft's suggestion of googling "dmesg vtd marvell" probably says it all, but if needed I could provide dmesg output with the problem.

 

might be helpful to confirm that the message you're receiving is the same as what folks with the marvell issue are reporting (want to rule this out as an unRAID problem for certain).

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Yes there is code added that changed the way expansion was done but for XFS code not added yet, so I thought, "Hey, instead of delaying the release a couple more days, let's just leave this out the for a beta release or two.  How many people using a beta will want to replace smaller disk with larger one, I bet I can get away with this and no one will notice."  Obviously someone noticed  ::)  I won't make that mistake again.

 

Nope.  Just note it clearly and include the appropriate statement, "  We are testing and developing new features and sometimes that means other features  have to be disabled. if this is a problem for you, do not use betas!"

 

My issue was, Tom noted it in the original post, and followed up with, "If anybody needs to do this before I put it back in, I will post the code to do it"... or something to that effect.  Well, he never did that, despite several folks asking for it.

 

 

Link to comment

Safe to use?

Is what safe to use?

 

If you simply mean beta 8 then it is certainly as safe to use if you are using base unRAID features.

 

Assuming by base features you do not mean disk replacement expansion. It does not support replacing a smaller disk with a larger disk.

 

Yes, it does. It won't expand the hard drive, tho.

 

This feature, I suspect, was removed temporarily due to lack of proper testing of expansion with the newly offered file systems.

 

Yes there is code added that changed the way expansion was done but for XFS code not added yet, so I thought, "Hey, instead of delaying the release a couple more days, let's just leave this out the for a beta release or two.  How many people using a beta will want to replace smaller disk with larger one, I bet I can get away with this and no one will notice."  Obviously someone noticed  ::)  I won't make that mistake again.

 

Nope.  Just note it clearly and include the appropriate statement, "  We are testing and developing new features and sometimes that means other features  have to be disabled. if this is a problem for you, do not use betas!"

 

My issue was, Tom noted it in the original post, and followed up with, "If anybody needs to do this before I put it back in, I will post the code to do it"... or something to that effect.  Well, he never did that, despite several folks asking for it.

 

I don't know why it couldn't have been left as-is for reiserfs, but make a note that a manual expansion was necessary for XFS or BTRFS.

Link to comment

Google "dmesg vtd marvell" There is a known issue with marvell chipset sata controllers and VT-d.

 

So it's HBA-specific to the marvell controller, not the motherboard or anything like that...  That's what I wanted to double-check.  We will definitely want to alert folks that are having this problem to turn that mode off.

 

My experience was that it was a marvell sata controller preventing the OS to boot when VT-d was enabled. If I turned off VT-d the sata controller worked just fine or if I removed the sata controller and turned on VT-d the OS booted just fine (The OS was Linux Mint FWIW) The sata controller was a Syba SATA III 2 Port PCI-e x1 Controller Card with Marvell 9170 Chipset. I ended up just returning the sata card.

Link to comment

Minor issue: I cannot turn off the banner image on the top of unRAID.

 

EDIT: disregard. It's working as it should. As an rule of thumb do NOT pass through your unRAID USB to a windows VM... UnRAID doesn't like that... Good news is a restart does wonders and everything is back up and working.

 

EDIT #2: it's also funny that of all the stuff that was wrong after I passed through the USB, I only noticed that the banner wouldn't turn off.

Link to comment

seems unmenu is not very happy with that loop thing

 

Sep 5 19:38:20 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:40:34 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:42:37 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:44:58 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:47:02 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:49:04 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:51:08 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory

 

Joe will have to take a look

 

I would appreciate if someone could explain an error message I have started receiving after opening UnMenu.

I am running V6 beta 8  a cache drive with Docker on the cache drive

 

Sep 6 16:40:18 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

Sep 6 17:17:53 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

Sep 6 17:45:13 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

 

 

With only the basic beta 8 upgraded from Beta 7 install I started receiving the same error messages everytime UnMenu is started.

Is there a correction needed or some other change or is it a bug in Beta 8 causing an error in Unmenu that wa not there in beta7

 

Link to comment

it is definately a unmenu issue....

i narrowed it down to a line in unmenu.awk

but my coding fu is not strong enough to figure out where the drive designation gets deprecated to 3 letters

 

normal drive assignment in unraid is 3 letters (MD1/ SDA)

so this deprecation is happening to loop8 to which makes it appear as loo...

 

i put it in the unmenu thread in the hope Joe will have a look at it

Link to comment

I had a strange issue today on beta8, though I don't know if it's specific to beta8.

 

I've been building a new UnRAID server for a family member, and have it up and running with various docker containers and OpenVPN server. I had a power blip last night, and it seemed to cause some issues.

 

I figure no problem, I will quickly rebuild, so did a reformat of the USB, copied over some config files( disk, share, ident, network, license), and everything came up fine. I reinstalled dockers (by re-pointing to the existing docker.img) and all was good.

 

As soon as I added OpenVPN to the server and rebooted the boot cycle would hang at 'Starting libvirtd'. When I goggled the message it appears to be a virtualization issue, but I was running non-Xen mode.

 

I re-wiped the USB, went through the process again, and it hung the same way, at the same place (twice more actually).

 

The machine is accessible via Putty, but not GUI, and none of the drives are available (/mnt is empty).

 

I am going to try and boot it up again tomorrow and copy out the syslog as I didn't do that today, but I am very confused on why I am getting this issue. I had made sure to remove any OpenVPN folders from my appdata share, as well as from the USB as I thought maybe old SSL keys were causing it as the IP had changed (though the same hostname - Tower), but even with a clean config I am getting this.

 

Has anyone seen this before, or have any idea what is going on? I realize a syslog will help and I hope to post one tomorrow, but wanted to see if there was any thoughts before then.

Link to comment

Guys,

 

trying to clear out my old beta7 docker settings and im getting the following when running through the instructions on the OP.

 

btrfs subvolume delete /mnt/cache/docker/btrfs/*

returns: Transaction commit: none (default)

ERROR: error accessing '/mnt/cache/docker/btrfs/*'

 

rm -r /mtn/cache/docker/

rm: cannot remove â/mnt/cache/docker/btrfsâ: Device or resource busy

 

 

EDIT:

 

Missed the DockerMan.plg hiding in the plugins directory. Deleted the plg and the DockerMan directory, rebooted and i was able to remove the legacy docker directory in /mnt/cache/docker. must have been locking a file and preventing deletion.

 

 

also get this message on the docker page now:

 

Fatal error: Cannot redeclare pgrep() (previously declared in /usr/local/emhttp/plugins/webGui/include/helpers.php:112) in /usr/local/emhttp/plugins/webGui/include/myPage_content.php(71) : eval()'d code on line 14

 

 

Any ideas?

 

Link to comment

seems unmenu is not very happy with that loop thing

 

Sep 5 19:38:20 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:40:34 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:42:37 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:44:58 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:47:02 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:49:04 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory
Sep 5 19:51:08 R2D2 unmenu[2584]: cat: /sys/block/loo/stat: No such file or directory

 

Joe will have to take a look

 

I would appreciate if someone could explain an error message I have started receiving after opening UnMenu.

I am running V6 beta 8  a cache drive with Docker on the cache drive

 

Sep 6 16:40:18 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

Sep 6 17:17:53 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

Sep 6 17:45:13 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory

 

 

With only the basic beta 8 upgraded from Beta 7 install I started receiving the same error messages everytime UnMenu is started.

Is there a correction needed or some other change or is it a bug in Beta 8 causing an error in Unmenu that wa not there in beta7

I am not running the beta versions of unRAID, so I cannot check personally, but I did look quickly at where the device names are being captured.

 

It appears as if the device names are being captured from the output of the /root/mdcmd status command.

 

Perhaps somebody with this issue can type

/root/mdcmd status | strings | grep loo

and post the output to see if the "loop" device names are being truncated in it, or if I need to look further in unMENU's code.

 

Joe L.

 

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.