Installing unRAID on a full Slackware distro


Recommended Posts

I rebuilt my unRAID server, so I took the opportunity to write up the steps with more detail on how to install unRAID on a full Slackware development system.

 

It's in the wiki at:

 

  http://lime-technology.com/wiki/index.php?title=Installing_unRAID_on_a_full_Slackware_distro

 

 

It is mostly a plan of steps that most experienced Linux users will know how to do, with some tricky things like running pwunconv to remove shadow passwords added where needed.  It is more of a protocol to follow so you don't miss something than a how-to.

 

It is not possible to give a complete how-to for each step... the things you need to know how to do on your own are:

 

Install a virgin Slackware 12.1 system.

Set up static IP under Linux.

Enable Apache and edit the Apache httpd.conf.

Edit various startup scripts in /etc/rc.d.

Run menuconfig, select drivers, and rebuild a kernel.

Debug panics caused by missing drivers in your kernel configuration.

Use a browser on nonstandard port numbers.

Edit lilo.conf to create multiple kernel boot options.

 

Enjoy!

Link to comment

Nicely done.

 

Looks like enough detail for the more experienced Linux folks.  As you said, not for the real beginner. 

(A beginner=someone who has mastered the CAPS-LOCK key, but not mastered CR/LF differences in editors and operating systems.)

 

I may give it a try at some point... (if I can free up a machine I can dedicate... or dual boot)

 

Joe L.

Link to comment

Thanks for this bubbaQ.  I've spent a few years with linux but it would have taken me forever to figure this out if not for your guide.  I've been following it today and just finished getting my new kernel working properly.  I had a little trouble getting dma enabled, but once I added ati-ipx to the kernel it worked.

 

Oh, also, when testing, I had to be sure to compile the new kernel from 2.6.24.5.  If I tried to compile it from my new unraid kernel I would get an error.

 

The only things I did differently were what brain:proxy mentioned in the previous thread, namely, doing "make modules_install" instead of "make modules install" and compiling those other two parts into the kernel...but I'm not sure if those changes were even really necessary.

Link to comment

User shares work without issue for me.

 

I'm running into a strange kernel panic when I restart the array (after stopping it).  I get this every time:

 

Sep  7 10:31:18 monster kernel: kobject_add_internal failed for 9:1 with -EEXIST, don't try to register things with the same name in the same directory.
Sep  7 10:31:18 monster kernel: Pid: 1516, comm: emhttp Not tainted 2.6.26.3-unRAID #3
Sep  7 10:31:18 monster kernel:  [<c020ec01>] kobject_add_internal+0x108/0x13e
Sep  7 10:31:18 monster kernel:  [<c020ef12>] kobject_add+0x4a/0x4e
Sep  7 10:31:18 monster kernel:  [<c0266e1a>] device_add+0x62/0x42c
Sep  7 10:31:18 monster kernel:  [<c020e959>] kobject_init+0x32/0x53
Sep  7 10:31:18 monster kernel:  [<c026726c>] device_create_vargs+0x78/0x99
Sep  7 10:31:18 monster kernel:  [<c0142834>] bdi_register+0x25/0x3a
Sep  7 10:31:18 monster kernel:  [<c0142863>] bdi_register_dev+0x1a/0x1e
Sep  7 10:31:18 monster kernel:  [<c020926a>] add_disk+0x4f/0x69
Sep  7 10:31:18 monster kernel:  [<c02085dc>] exact_match+0x0/0x7
Sep  7 10:31:18 monster kernel:  [<c0208fe1>] exact_lock+0x0/0xd
Sep  7 10:31:18 monster kernel:  [<f886af72>] start_array+0x581/0x5be [md_mod]
Sep  7 10:31:18 monster kernel:  [<f886c08e>] md_cmd_proc_write+0x894/0xa1f [md_mod]
Sep  7 10:31:18 monster kernel:  [<c0178cb0>] inotify_d_instantiate+0xf/0x30
Sep  7 10:31:18 monster kernel:  [<c0163f69>] d_rehash+0x1c/0x27
Sep  7 10:31:18 monster kernel:  [<c017f568>] proc_root_lookup+0xe/0x26
Sep  7 10:31:18 monster kernel:  [<c01642a5>] dput+0x15/0xb9
Sep  7 10:31:18 monster kernel:  [<c015e444>] __link_path_walk+0x9be/0xace
Sep  7 10:31:18 monster kernel:  [<c0113a51>] __wake_up_common+0x34/0x58
Sep  7 10:31:18 monster kernel:  [<c01147ac>] __wake_up+0x29/0x39
Sep  7 10:31:18 monster kernel:  [<c0168430>] mntput_no_expire+0x18/0xd7
Sep  7 10:31:18 monster kernel:  [<c015e5bb>] path_walk+0x67/0x70
Sep  7 10:31:18 monster kernel:  [<c015e7fe>] do_path_lookup+0x11e/0x139
Sep  7 10:31:18 monster kernel:  [<c017efab>] pde_users_dec+0xb/0x27
Sep  7 10:31:18 monster kernel:  [<c017f43d>] proc_reg_open+0x41/0x48
Sep  7 10:31:18 monster kernel:  [<c017f3fc>] proc_reg_open+0x0/0x48
Sep  7 10:31:18 monster kernel:  [<c015592a>] __dentry_open+0x11d/0x1e6
Sep  7 10:31:18 monster kernel:  [<c0155a0f>] nameidata_to_filp+0x1c/0x2c
Sep  7 10:31:18 monster kernel:  [<c015f6ba>] do_filp_open+0x31c/0x64a
Sep  7 10:31:18 monster kernel:  [<c01460c4>] handle_mm_fault+0x693/0x71d
Sep  7 10:31:18 monster kernel:  [<f886b7fa>] md_cmd_proc_write+0x0/0xa1f [md_mod]
Sep  7 10:31:18 monster kernel:  [<c01826b1>] proc_file_write+0x25/0x2e
Sep  7 10:31:18 monster kernel:  [<c018268c>] proc_file_write+0x0/0x2e
Sep  7 10:31:18 monster kernel:  [<c017f2ac>] proc_reg_write+0x56/0x69
Sep  7 10:31:18 monster kernel:  [<c017f256>] proc_reg_write+0x0/0x69
Sep  7 10:31:18 monster kernel:  [<c01571a7>] vfs_write+0x83/0xf6
Sep  7 10:31:18 monster kernel:  [<c01576b1>] sys_write+0x3c/0x63
Sep  7 10:31:18 monster kernel:  [<c0102b7a>] syscall_call+0x7/0xb
Sep  7 10:31:18 monster kernel:  =======================
Sep  7 10:31:18 monster kernel: BUG: unable to handle kernel NULL pointer dereference at 00000094
Sep  7 10:31:18 monster kernel: IP: [<c0187e74>] sysfs_create_link+0x36/0xda
Sep  7 10:31:18 monster kernel: *pdpt = 000000003742d001 *pde = 0000000000000000
Sep  7 10:31:18 monster kernel: Oops: 0000 [#1] SMP
Sep  7 10:31:18 monster kernel: Modules linked in: md_mod fuse e1000 sata_sil24 ahci libata i2c_i801 dock
Sep  7 10:31:18 monster kernel:
Sep  7 10:31:18 monster kernel: Pid: 1516, comm: emhttp Not tainted (2.6.26.3-unRAID #3)
Sep  7 10:31:18 monster kernel: EIP: 0060:[<c0187e74>] EFLAGS: 00210246 CPU: 1
Sep  7 10:31:18 monster kernel: EIP is at sysfs_create_link+0x36/0xda
Sep  7 10:31:18 monster kernel: EAX: c048f09c EBX: 00000078 ECX: c03a091e EDX: 0000bebe
Sep  7 10:31:18 monster kernel: ESI: c03a091e EDI: fffffff2 EBP: f76f58d0 ESP: f64f3d7c
Sep  7 10:31:18 monster kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Sep  7 10:31:18 monster kernel: Process emhttp (pid: 1516, ti=f64f2000 task=f7c56520 task.ti=f64f2000)
Sep  7 10:31:18 monster kernel: Stack: 00000009 00000001 c020926a c02085dc f64d1200 00000001 f64d6000 00000001
Sep  7 10:31:18 monster kernel:        f886af72 f64d120c f8870c46 00000001 f64d6080 f64f3df6 f64f3df6 b6465300
Sep  7 10:31:18 monster kernel:        f74aee00 f886c08e c0178cb0 f79ee9b0 f78aab00 f78aab00 c0163f69 0000000d
Sep  7 10:31:18 monster kernel: Call Trace:
Sep  7 10:31:18 monster kernel:  [<c020926a>] add_disk+0x4f/0x69
Sep  7 10:31:18 monster kernel:  [<c02085dc>] exact_match+0x0/0x7
Sep  7 10:31:18 monster kernel:  [<f886af72>] start_array+0x581/0x5be [md_mod]
Sep  7 10:31:18 monster kernel:  [<f886c08e>] md_cmd_proc_write+0x894/0xa1f [md_mod]
Sep  7 10:31:18 monster kernel:  [<c0178cb0>] inotify_d_instantiate+0xf/0x30
Sep  7 10:31:18 monster kernel:  [<c0163f69>] d_rehash+0x1c/0x27
Sep  7 10:31:18 monster kernel:  [<c017f568>] proc_root_lookup+0xe/0x26
Sep  7 10:31:18 monster kernel:  [<c01642a5>] dput+0x15/0xb9
Sep  7 10:31:18 monster kernel:  [<c015e444>] __link_path_walk+0x9be/0xace
Sep  7 10:31:18 monster kernel:  [<c0113a51>] __wake_up_common+0x34/0x58
Sep  7 10:31:18 monster kernel:  [<c01147ac>] __wake_up+0x29/0x39
Sep  7 10:31:18 monster kernel:  [<c0168430>] mntput_no_expire+0x18/0xd7
Sep  7 10:31:18 monster kernel:  [<c015e5bb>] path_walk+0x67/0x70
Sep  7 10:31:18 monster kernel:  [<c015e7fe>] do_path_lookup+0x11e/0x139
Sep  7 10:31:18 monster kernel:  [<c017efab>] pde_users_dec+0xb/0x27
Sep  7 10:31:18 monster kernel:  [<c017f43d>] proc_reg_open+0x41/0x48
Sep  7 10:31:18 monster kernel:  [<c017f3fc>] proc_reg_open+0x0/0x48
Sep  7 10:31:18 monster kernel:  [<c015592a>] __dentry_open+0x11d/0x1e6
Sep  7 10:31:18 monster kernel:  [<c0155a0f>] nameidata_to_filp+0x1c/0x2c
Sep  7 10:31:18 monster kernel:  [<c015f6ba>] do_filp_open+0x31c/0x64a
Sep  7 10:31:18 monster kernel:  [<c01460c4>] handle_mm_fault+0x693/0x71d
Sep  7 10:31:18 monster kernel:  [<f886b7fa>] md_cmd_proc_write+0x0/0xa1f [md_mod]
Sep  7 10:31:18 monster kernel:  [<c01826b1>] proc_file_write+0x25/0x2e
Sep  7 10:31:18 monster kernel:  [<c018268c>] proc_file_write+0x0/0x2e
Sep  7 10:31:18 monster kernel:  [<c017f2ac>] proc_reg_write+0x56/0x69
Sep  7 10:31:18 monster kernel:  [<c017f256>] proc_reg_write+0x0/0x69
Sep  7 10:31:18 monster kernel:  [<c01571a7>] vfs_write+0x83/0xf6
Sep  7 10:31:18 monster kernel:  [<c01576b1>] sys_write+0x3c/0x63
Sep  7 10:31:18 monster kernel:  [<c0102b7a>] syscall_call+0x7/0xb
Sep  7 10:31:18 monster kernel:  =======================
Sep  7 10:31:18 monster kernel: Code: 85 c9 75 04 0f 0b eb fe 85 c0 bd 84 6a 40 c0 74 10 8b 68 1c bf f2 ff ff ff 85 ed 0f 84 a4 00 00 00 b8 9c f0 48 c0 e8 b2 fb 1a 00 <8b> 5b 1c 85 db 74 17 83 3b 00 75 0f ba 81 00 00 00 b8 a1 36 3a
Sep  7 10:31:18 monster kernel: EIP: [<c0187e74>] sysfs_create_link+0x36/0xda SS:ESP 0068:f64f3d7c
Sep  7 10:31:18 monster kernel: ---[ end trace e065292131e2d8a2 ]---

 

It's very strange.  I was running into this repeatedly yesterday.  What I found is that if I restored my array (and rebuilt parity), this panic no longer occurred when I restarted the array.  However, as soon as I shut down unRAID using WeeboTech's powerdown script, the error returned. 

 

To me it doesn't look like a kernel configuration error.  I was running the 2.6.26 kernel on my flash previously, so I don't think that's to blame.  My suspicion is that there's something that the emhttp shutdown is doing that the powerdown script is not.  Has anyone else seen this behavior?  I mean, I can get around it by rebooting every time I change the array, but I'd rather fix the root problem.

Link to comment

So that panic doesn't occur when you use the web interface to stop and start the array?

 

The panic DOES occur when I use the web interface to stop/start the array.  If I stop the array, then reboot, or power down it comes back up normally on reboot (parity is valid). 

 

@planetscott ... are you running SMP?  I see "Oops: 0000 [#1] SMP" in your log.  That kind of panic on shutdown is typical when you try to urun unmodified unRAID  MD.c on SMP.

 

I am running SMP, yes.  In one of the other threads I described how I patched unraid.c to get rid of the panic on array shutdown by adding an additional lock (I've never seen a panic at startup).  I've been running an SMP kernel for the past month with my flash-based install with no issues.  Perhaps I'll try building a non-SMP kernel to see if I get the same behavior. 

 

One thing that's strange is that I just shut down the array, but it looks like /mnt/user has not unmounted cleanly. 

 

root@monster:/mnt# ls -l
/bin/ls: cannot access user: No such file or directory
total 36
-rw-r--r-- 1 root root  376 2006-09-25 23:09 README
drwxr-xr-x 2 root root 4096 2006-09-25 21:02 cdrecorder/
drwxr-xr-x 2 root root 4096 2002-03-16 02:34 cdrom/
drwxr-xr-x 2 root root 4096 2006-09-25 21:02 dvd/
drwxr-xr-x 2 root root 4096 2002-03-16 02:34 floppy/
drwxr-xr-x 2 root root 4096 2002-03-16 02:34 hd/
drwxr-xr-x 2 root root 4096 2006-09-25 21:02 memory/
drwxr-xr-x 2 root root 4096 2006-09-25 21:03 tmp/
d??? ? ?    ?       ?                ? user/
drwxr-xr-x 2 root root 4096 2006-09-25 21:02 zip/
root@monster:/mnt# 

 

Hmm ...

Link to comment

One thing that's strange is that I just shut down the array, but it looks like /mnt/user has not unmounted cleanly. 

I do not touch the fuse system. Perhaps I should some how.

Either that or figure out a way to post to emhttp from shell.

 

Turns out it's a problem with my use of the 2.6.26 kernel.  I guess it's not ready for primetime yet!

 

I compiled 2.6.24.4 (SMP) and I'm no longer having any problems.

Have you seen any improvement in I/O rate with SMP?

I'm thinking of enabling it.

 

 

Link to comment

Best test is to compile and test with bonnie++

 

That will give you hard evidence if there is any improvement in I/O.

 

Case in point.

I did a test with Parity on a single drive and parity on a hardware RAID0 drive.

It showed an improvement in I/O, albeit very small.

I'm waiting to redo this test on my larger machine as I used the Nordgo DS-520G and I think it's limited to PCI-X.

Whereas with the ABIT AB9 PRO, Certain drives will have their own PCIe Lanes.

 

 

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.