Trying to run unRAID on regular hard drive


Recommended Posts

I didn't mean the server was just sitting there doing nothing with both cores maxxed out.

Ooops, I did not know. On my system the slackware distro I installed had both cores maxed out in my diual xeon

The dev environment was basically idle, yet using 100% for two of the 4 cores ???

I installed the vmware tools and the environment chilled out.

I know on my solaris environment I had to install some patches so the HLT CPU call was made.

So when you said your cores were maxed out, I thought of these scenarios.

Link to comment
  • 3 weeks later...
  • Replies 65
  • Created
  • Last Reply

Top Posters In This Topic

Ok, I made some new packages.  Check out the url in the first post, it has prebuilt kernel and kernel-module binaries now.  Also there's one more goodie not on the how-to yet.  You can now make your own unRAID package to use with installpkg.  I made a package myself, but have not received permission yet to redistribute the binaries, so I made a script that will make the package for you.

 

Download http://downloads.thetechguide.com/unraid/unRAIDpackage.sh

 

Put it somewhere on your server (which needs to be running a stock install of Slackware, and you also need to already have the kernel and kernel-modules for unRAID installed).  Do a chmod 755 on it, then run it with the name of the unRAID release you want to use after it.  Simply go here:

 

http://lime-technology.com/dnlds/

 

And write down the name of the release you want to use.  Let's say you want to use the current newest 4.3 beta6.  The commands you'd run to download this script then download 4.3 beta6 and create the package are as follows:

 

wget http://downloads.thetechguide.com/unraid/unRAIDpackage.sh

chmod 755 unRAIDpackage.sh

./unRAIDpackage.sh unRAID Server 4.3-beta6.zip

 

It will take a while to run, basically it downloads the file you told it to, unzips it, unzips the bzroot, downloads a file from my server (which contains a list of all files and directories that need to be copied, I figured this may change over time), and packages up a package in the working directory named unRAID-4.3.tgz (and then deletes the unraid-temp directory it had made).  It's only tested with unRAID-4.3-beta6, but should work with any of the 4.3 series (and maybe others, haven't tested, have no idea).

 

Now all you have to do is run "installpkg unRAID-4.3.tgz" and all the unRAID files will be copied to your system.  Simply reboot and you should be good to go.

 

Note:  Installing this package will delete the "x" for the root user in /etc/passwd, if it's there unRAID will ask for a username/password but nothing will work.  Taking it out will make it work again.  It will also overwrite any other /boot/config files you have, so if you install this once, then configure everything just the way you want, then install again, you'll have to configure your system all over again.

 

Todo:

 

The script is smart enough to compensate if you give it a filename with %20 instead of spaces, but not if you give it the whole url.  I don't know how to run sed on a variable, I'll check into that later.

 

Backup the /boot/config scripts somewhere on each install, or see if there's a way to not have it overwrite the config scripts if they already exist.

 

If/when Tom gives the ok, I will simply give you the url to the package itself instead of having your run a script, saving everyone (except me) some bandwidth.

 

If/when Tom gives the ok, I will also see about packaging up everything into a custom install iso.  Just install Slackware and you've got unRAID ready to go.

 

IMPORTANT!!!  This has not been extensively tested.  Some things may not work as expected.  If you do this don't email or pester Tom for support.  Just post in this thread for now and I'll try to help out.

Link to comment

Running unRAID from a hard drive seems promising.  I'm actually getting ready to build my first unRAID box once my new motherboard arrives and was wondering if this would work with one of the Slackware derivatives such as GoblinX?  I guess I can always try myself and see if it works but I thought I might ask before I invest the time.  Thanks.

Link to comment

Running unRAID from a hard drive seems promising.  I'm actually getting ready to build my first unRAID box once my new motherboard arrives and was wondering if this would work with one of the Slackware derivatives such as GoblinX?  I guess I can always try myself and see if it works but I thought I might ask before I invest the time.  Thanks.

 

No idea.  It depends just how closely related it is to Slackware 12.  Also remember that there's no official support for doing this.  If anything messes up you can post about it here, but you can't email Tom about it expecting any help.  If you have issues, best bet is to boot unRAID the official way and see if the problems persist.

Link to comment

unRAID is currently built on top of Slackware 12, so that's what I geared it towards.  I haven't tried Slackware 12.1, but just from the version number it sounds like Slackware 12 with updates applied.  I think you'd have a decent chance of that working, but you'd be the first to try it out.

Link to comment

Following josetann's directions, I also decided to copy the rc.local from the unRAID distro to the hard drive so that fuse and emhttp are automatically started.  Since my rc.local was basically empty, I just overwrote it.  Otherwise, the unRAID rc.local could just be appended to the end of the existing one on the hard drive.

 

Only issue is that since the mount points become persistent on the hard drive install, I get a warning that /mnt/disk1 already exists.  I doubt if this is a real problem.  Also, I don't have user shares enabled on the development box, but I'd bet that similar warnings would occur for them.

 

Does this happen when fuse and emhttp are started manually?

 

 

Link to comment
  • 3 weeks later...

josetann, i noticed your system does not modify the drivers built into the kernel, but leaves them as modules.  I prefer to build the necessary drivers into the kernel, and do away with the initramfs... it frees up RAM.  And it makes installing things like Apache easier.  Was there a particular reason you left support in for the initramfs?  Plus, your instructions didn't seem to account for the initramfs.

 

Also, did you consider symlinking necessary files back to the flash rather than copying?  The reason I do it that way is so if I have any problems with the HD install of Linux, I can do a conventional boot from the unRAID flash and have the regular unRAID system booted.

Link to comment
  • 2 weeks later...

josetann, i noticed your system does not modify the drivers built into the kernel, but leaves them as modules.  I prefer to build the necessary drivers into the kernel, and do away with the initramfs... it frees up RAM.  And it makes installing things like Apache easier.  Was there a particular reason you left support in for the initramfs?  Plus, your instructions didn't seem to account for the initramfs.

 

Simple, I tried to keep it as close to a stock unRAID kernel as possible.

 

Also, did you consider symlinking necessary files back to the flash rather than copying?  The reason I do it that way is so if I have any problems with the HD install of Linux, I can do a conventional boot from the unRAID flash and have the regular unRAID system booted.

 

No, for one main reason.  Not everyone needs the flash drive (i.e., those who use the free version and don't have a license file).  Those that need the flash drive, don't need it to actually boot linux.  All I have to do is have a flash drive with UNRAID as the volume name, and that has its GUID tied to my license file.  I can use it for other stuff, have it bootable to use to flash bioses, store regular files on it, etc.  Now, you should definitely keep a backup of your config files and definitely your license file, if you do then you can easily boot from flash and see what's up if your regular drive won't boot.

Link to comment
  • 2 weeks later...
  • 1 month later...

There's very little (read: none that I could find) documentation on just what the paranoia bit is supposed to be for.  Since it says up above it's for debugging, one would assume it's not that necessary.  Then again it's enabled by default.  Who knows?

 

I "think" that leaving the define as is, and restricting the cpu to one core, would still cause a crash.  I haven't tested it yet though, if I get bored I might.  I'm just happy it's working the way I want on my system, but I would like to see just what's going on and make sure it's safe for others to run too.

 

BTW I'm using VMware server 1 as well.  I couldn't get RAW disks to work in 2, plus with the expiration date since it's a beta...I just want to get this working and then forget about it.

 

I'm resurrecting this thread because today I bought a new dual core CPU for the purpose of running Virtual Box within unRAID, and I'd like to enable SMP in my kernel.  I'm wondering if anyone has a stack trace from one of the CHECK_DEVLOCK() errors?  I've compiled an SMP kernel on my box, but I can't seem to hit it (yet).

 

I'm not a pro Linux kernel hacker, and I've only just browsed the code, but it looks like the only place that this could happen is through the shrink_stripes function (unraid.c, line 1387):

 

static void shrink_stripes(unraid_conf_t *conf)
{
        struct stripe_head *sh;

        while ((sh = get_free_stripe(conf)) != NULL) {
        ....

 

This code is calling get_free_stripe() without first locking device_lock.  And it looks like shrink_stripes() is only called when the array is shutting down.  The comments in the header of unraid.c state:

 

* The write list and read list both act as fifos.  The read list is
* protected by the device_lock.

 

as well as ...

 

* The inactive_list, handle_list and hash bucket lists are all protected by the
* device_lock.

 

It looks like all of these scenarios are covered based on what I've read in the code.  So I'm thinking that in order to fix this, we should only need to add a lock around shrink_stripes.  Perhaps I'm missing something?

Link to comment

Looks like that was it.  I just tried shutting down my array and got:

 

Aug  3 21:47:04 Tower kernel: ------------[ cut here ]------------
Aug  3 21:47:04 Tower kernel: kernel BUG at drivers/md/unraid.c:278!
Aug  3 21:47:04 Tower kernel: invalid opcode: 0000 [#1] SMP
Aug  3 21:47:04 Tower kernel: Modules linked in: abituguru3 md_mod fuse pata_jmicron i2c_i801 ahci jmicron ide_core r8168 sata_sil24 libata dock
Aug  3 21:47:04 Tower kernel:
Aug  3 21:47:04 Tower kernel: Pid: 2404, comm: powerdown Not tainted (2.6.26-unRAID #7)
Aug  3 21:47:04 Tower kernel: EIP: 0060:[<f88a9a99>] EFLAGS: 00010246 CPU: 1
Aug  3 21:47:04 Tower kernel: EIP is at get_free_stripe+0x15/0x105 [md_mod]
Aug  3 21:47:04 Tower kernel: EAX: 0000008b EBX: f795ac80 ECX: c3e21080 EDX: 0000008b
Aug  3 21:47:04 Tower kernel: ESI: f795ac80 EDI: 00000003 EBP: f79a8000 ESP: cb65dd54
Aug  3 21:47:04 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Aug  3 21:47:04 Tower kernel: Process powerdown (pid: 2404, ti=cb65c000 task=f7884a20 task.ti=cb65c000)
Aug  3 21:47:04 Tower kernel: Stack: f795ac80 f795ac80 00000003 f79a8000 f88a9cbd f79a8000 f795ac80 f79a8000
Aug  3 21:47:04 Tower kernel:        00000003 f79a8000 f88aad14 f78a3000 00000000 f88a5929 00000010 f79a9010
Aug  3 21:47:04 Tower kernel:        f79a8000 00000000 cb601080 f88a66fe cb65ddf6 cb65ddf6 080f3808 f88a6fe1
Aug  3 21:47:04 Tower kernel: Call Trace:
Aug  3 21:47:04 Tower kernel:  [<f88a9cbd>] shrink_stripes+0x6b/0x8a [md_mod]
Aug  3 21:47:04 Tower kernel:  [<f88aad14>] unraid_stop+0x19/0x32 [md_mod]
Aug  3 21:47:04 Tower kernel:  [<f88a5929>] do_stop+0x89/0xac [md_mod]
Aug  3 21:47:04 Tower kernel:  [<f88a66fe>] stop_array+0x79/0x9a [md_mod]
Aug  3 21:47:04 Tower kernel:  [<f88a6fe1>] md_cmd_proc_write+0x89f/0xa17 [md_mod]
Aug  3 21:47:04 Tower kernel:  [<c0111142>] do_page_fault+0x310/0x73a
Aug  3 21:47:04 Tower kernel:  [<c01111a9>] do_page_fault+0x377/0x73a
Aug  3 21:47:04 Tower kernel:  [<c013d4aa>] get_page_from_freelist+0x30d/0x394
Aug  3 21:47:04 Tower kernel:  [<c0164b2c>] dput+0x15/0xb9
Aug  3 21:47:04 Tower kernel:  [<c015d1c6>] __follow_mount+0x1e/0x60
Aug  3 21:47:04 Tower kernel:  [<c015d31b>] do_lookup+0x53/0x145
Aug  3 21:47:04 Tower kernel:  [<c016ed9c>] __mark_inode_dirty+0xb6/0x129
Aug  3 21:47:04 Tower kernel:  [<c01677af>] notify_change+0x229/0x236
Aug  3 21:47:04 Tower kernel:  [<c01566d0>] do_truncate+0x6b/0x75
Aug  3 21:47:04 Tower kernel:  [<c017980c>] inotify_d_instantiate+0xf/0x30
Aug  3 21:47:04 Tower kernel:  [<c017f473>] pde_users_dec+0xb/0x27
Aug  3 21:47:04 Tower kernel:  [<c0112c26>] ptep_set_access_flags+0x40/0x48
Aug  3 21:47:04 Tower kernel:  [<c0144201>] do_wp_page+0x1b3/0x47f
Aug  3 21:47:04 Tower kernel:  [<c0144474>] do_wp_page+0x426/0x47f
Aug  3 21:47:04 Tower kernel:  [<c015fe4d>] do_filp_open+0x334/0x63c
Aug  3 21:47:04 Tower kernel:  [<c014656e>] handle_mm_fault+0x69c/0x722
Aug  3 21:47:04 Tower kernel:  [<f88a6742>] md_cmd_proc_write+0x0/0xa17 [md_mod]
Aug  3 21:47:04 Tower kernel:  [<c0182bb0>] proc_file_write+0x25/0x2e
Aug  3 21:47:04 Tower kernel:  [<c0182b8b>] proc_file_write+0x0/0x2e
Aug  3 21:47:04 Tower kernel:  [<c017f770>] proc_reg_write+0x56/0x69
Aug  3 21:47:04 Tower kernel:  [<c017f71a>] proc_reg_write+0x0/0x69
Aug  3 21:47:04 Tower kernel:  [<c015781d>] vfs_write+0x83/0xf6
Aug  3 21:47:04 Tower kernel:  [<c0157d56>] sys_write+0x3c/0x63
Aug  3 21:47:04 Tower kernel:  [<c0102b26>] syscall_call+0x7/0xb
Aug  3 21:47:04 Tower kernel:  =======================
Aug  3 21:47:04 Tower kernel: Code: c0 0f b6 c0 50 68 1f c7 8a f8 e8 8c 19 87 c7 31 c0 83 c4 20 5b c3 55 57 56 89 c6 53
8b 40 3c 0f b6 d4 25 ff 00 00 00 39 c2 75 04 <0f> 0b eb fe 8b 5e 20 8d 46 20 31 ff 39 c3 0f 84 d5 00 00 00 8b
Aug  3 21:47:04 Tower kernel: EIP: [<f88a9a99>] get_free_stripe+0x15/0x105 [md_mod] SS:ESP 0068:cb65dd54
Aug  3 21:47:04 Tower kernel: ---[ end trace 4d29f377d2d62533 ]---

 

I've recompiled unraid.c with the changes I mentioned above.  Once I finish my parity check, I'll try restarting again to see if it's fixed.

Link to comment

Just to confirm, after making that fix I no longer get the kernel error on shutdown.

 

Here's a diff of my change:

 

root@slackware:/usr/src/linux/drivers/md# diff -up /root/initrd-unraid-4.3.3/usr/src/linux/drivers/md/unraid.c ./unraid.c
--- /root/initrd-unraid-4.3.3/usr/src/linux/drivers/md/unraid.c 2008-07-15 18:16:09.000000000 -0400
+++ ./unraid.c  2008-08-03 21:16:19.000000000 -0400
@@ -1388,6 +1388,7 @@ static void shrink_stripes(unraid_conf_t
{
        struct stripe_head *sh;

+       spin_lock_irq(&conf->device_lock);
        while ((sh = get_free_stripe(conf)) != NULL) {
                if (atomic_read(&sh->count))
                        MD_BUG();
@@ -1395,6 +1396,8 @@ static void shrink_stripes(unraid_conf_t
                kmem_cache_free(conf->slab_cache, sh);
                atomic_dec(&conf->active_stripes);
        }
+       spin_unlock_irq(&conf->device_lock);
+
        if (conf->slab_cache) {
                kmem_cache_destroy(conf->slab_cache);
                conf->slab_cache = NULL;
root@slackware:/usr/src/linux/drivers/md#

 

Hope this helps.

 

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.