bubbaQ Posted September 4, 2008 Share Posted September 4, 2008 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! Quote Link to comment
Joe L. Posted September 4, 2008 Share Posted September 4, 2008 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. Quote Link to comment
bubbaQ Posted September 4, 2008 Author Share Posted September 4, 2008 I wanted this to be as fault-tolerant as possible... so if the Linux install get's hosed, just boot from flash and you are back to a standard unRAID system just by rebooting. Quote Link to comment
musicmann Posted September 5, 2008 Share Posted September 5, 2008 Great info, bubbaQ! I think in the previous writeup, you had said that you were not using user shares. Have you tried them out, or do you know if there are any issues with the full install and using them? Quote Link to comment
bubbaQ Posted September 5, 2008 Author Share Posted September 5, 2008 I don't use use shares, but the FUSE FS loads and appears to work. Quote Link to comment
brain:proxy Posted September 5, 2008 Share Posted September 5, 2008 User shares work without issue for me. Quote Link to comment
tribble222 Posted September 5, 2008 Share Posted September 5, 2008 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. Quote Link to comment
planetscott Posted September 5, 2008 Share Posted September 5, 2008 This is great bubbaQ, I think I may have to try this over the weekend! Quote Link to comment
bubbaQ Posted September 6, 2008 Author Share Posted September 6, 2008 Thanks tribble... I corrected the typo and added a note about 2.6.24.5. I'm actually running 2.6.24.5 now. Quote Link to comment
planetscott Posted September 7, 2008 Share Posted September 7, 2008 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. Quote Link to comment
tribble222 Posted September 7, 2008 Share Posted September 7, 2008 So that panic doesn't occur when you use the web interface to stop and start the array? Quote Link to comment
bubbaQ Posted September 7, 2008 Author Share Posted September 7, 2008 @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. Quote Link to comment
planetscott Posted September 7, 2008 Share Posted September 7, 2008 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 ... Quote Link to comment
planetscott Posted September 7, 2008 Share Posted September 7, 2008 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. Quote Link to comment
WeeboTech Posted September 10, 2008 Share Posted September 10, 2008 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. Quote Link to comment
planetscott Posted September 11, 2008 Share Posted September 11, 2008 Have you seen any improvement in I/O rate with SMP? I'm thinking of enabling it. To be honest, I havn't done any comparisons with the old kernel. Like I've said, my main reason for running SMP is to fully take advantage of virtualization. Are you running into I/O bottlenecks now? Quote Link to comment
WeeboTech Posted September 11, 2008 Share Posted September 11, 2008 Are you running into I/O bottlenecks now? Yeah, my my machine gets high %WA states. Buit then again, I'm workin it pretty hard. Two rtorrent sessions seeding, plus my rips go to it simultaneously. Quote Link to comment
bubbaQ Posted September 13, 2008 Author Share Posted September 13, 2008 @WeeboTech , I did a test with SMP enabled, and using the patch to md.c ... I did not see any appreciable difference in IO using the stopwatch method, but some tests using hdparm were faster... particularly the fully RAM buffered test. Quote Link to comment
WeeboTech Posted September 14, 2008 Share Posted September 14, 2008 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. Quote Link to comment
bubbaQ Posted September 14, 2008 Author Share Posted September 14, 2008 Consider installing bwm-ng .... the disk i/o data is enlightening. Quote Link to comment
Recommended Posts
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.