Hi,

 

I've been using Unraid for a few weeks now and got it to work under slackware 13.1 all virtualized under VMware ESXi 4.1 (now that USB is supported). I had to recompile my kernel numerous times and... I'm not even sure I would be able to redo it quickly as at some point, I stopped documenting my changes as it was taking forever without success.

 

So, basically, my request would be to have Unraid as a package for slackware (or any other linux distro, particularly when they have a server version like Ubuntu and a few other offer). This way, we would be able to keep our distro up to date with security fixes and to add some other package that we may want easily. I understand we can already maintain a development environment beside the Unraid server and create the package there before moving those to Unraid but... it require effort and tweaking that I would prefer not to do, particularly when I know those efforts have been done elsewhere and are available for installation with tools like installpkg, apt-get and so on.

 

It would also allow us to install this easily on a distro that has VMware tools fully installed and supported. I got the paravirtual NIC and HDD working on my installation and it is way faster. I have now enough performance to share a single quad-core CPU and have my Unraid server (over 10TB), my SageTV server (with a HD-PVR attached to it), my Astaro 8 FW and a few other VMs running without any skipping while recording and listening HD content on up to 3 clients and downloading at full speed (5 Mbps) from the internet. I think it is a nice setup but it took too much time to get the Unraid/Slackware 13.1 part of the system running and I'm afraid it will be hard to support over time (with new version of Unraid and new update of slackware coming).

 

Having Unraid as a package would allow people to configure a barebone Unraid server or a fully configured version without any changes on the package itself. It would be made at the linux distro level, before installing Unraid.

 

Thank you for your attention.

 

ehfortin

It's kind of odd that you're asking for such a thing, as I've been meaning to see what it would take to do such a thing for some time now. The one item I'm not certain quite how to handle is the kernel module portion of unRAID (md). The best that might be able to be done in that case is providing the md driver source and letting the user do the kernel configuration, compilation, and installation.

 

Though my efforts will first be for the unRAID 5.0 series, likely starting with the 64bit Slackware Current distro.

 

Unfortunately my time has been monopolized by other pending efforts to make much progress on this.

You can't do it with a Slackware "package" as you have to build a new kernel.

 

You can, however, build an alternate kernel, and boot it with a modified syslinux config..... that is what BubbaRaid was.

Virtualbox and the vmware tools package are two examples of apps that are packaged but still need to be compiled against the kernel. I'm not sure if it is as close as the md driver need to be but as I saw that the md is dynamic, I would think it can be packaged in a way that a simple compile (that can be part of the installation script) can handle.

 

I can be wrong however. I'm not a kernel/driver coder at all. That's just based on my observation while I was recompiling the kernel numerous times to get Unraid working. The drivers that were mandatory in the kernel are the one of the disks so that they can be recognized during the boot process. The stock slackware kernel is recognizing all my disks. But maybe not in a way emhttp was looking for. I'll revisit this soon with a new slackware 13.1 install and the beta 2 of Unraid 5.0 just to see if I can reduce the effort needed to have it working to a minimum. I'll look back at the Wacom driver project that was compiling against the kernel without having to do a reconfig of the kernel at all. Hope to be able to try this soon as it sound an interesting avenue.

 

BubbaQ, why are you saying that "that is what BubbaRaid was". It is not anymore? I've saw this package in the wiki but didn't dig into it as I needed a working Unraid ASAP (my older NAS was dying on me and I didn't want to spend on it before moving to Unraid so... I've put all emphasis to just have a working Unraid on Slackware, nothing more yet).

 

Thanks.

 

ehfortin

Virtualbox and the vmware tools package are two examples of apps that are packaged but still need to be compiled against the kernel. I'm not sure if it is as close as the md driver need to be but as I saw that the md is dynamic, I would think it can be packaged in a way that a simple compile (that can be part of the installation script) can handle.

 

I can be wrong however. I'm not a kernel/driver coder at all. That's just based on my observation while I was recompiling the kernel numerous times to get Unraid working. The drivers that were mandatory in the kernel are the one of the disks so that they can be recognized during the boot process. The stock slackware kernel is recognizing all my disks. But maybe not in a way emhttp was looking for. I'll revisit this soon with a new slackware 13.1 install and the beta 2 of Unraid 5.0 just to see if I can reduce the effort needed to have it working to a minimum. I'll look back at the Wacom driver project that was compiling against the kernel without having to do a reconfig of the kernel at all. Hope to be able to try this soon as it sound an interesting avenue.

 

BubbaQ, why are you saying that "that is what BubbaRaid was". It is not anymore? I've saw this package in the wiki but didn't dig into it as I needed a working Unraid ASAP (my older NAS was dying on me and I didn't want to spend on it before moving to Unraid so... I've put all emphasis to just have a working Unraid on Slackware, nothing more yet).

 

Thanks.

 

ehfortin

bubbaRaid must be used with unRAID 4.3.3.  That is no longer available from lime-technology as a download, so it would prove difficult for any new user of unRAID to install.  (Counting beta-versions, it was 29 versions of unRAID ago)

One of the possible difficulties is that the unRAID low level device drivers replace already existing device drivers. I'm not up to speed on doing kernel module swap-outs to know exactly what housekeeping must be performed. I think there's more to it than doing the following:

 

KERNEL_VERSION=`uname -r`

# need a better way to match current version and prepackaged versions

PRECOMP_VERSION=${KERNEL_VERSION}

 

rm /lib/modules/${KERNEL_VERSION}/kernel/drivers/md/*

cp ${INSTALL_BASE}/modules/${PRECOMP_VERSION}/* /lib/modules/${KERNEL_VERSION}/kernel/drivers/md/

 

if [ -r /boot/System.map  -a -x /sbin/depmod ]

then

  /sbin/depmod -ae -F /boot/System.map  ${KERNEL_VERSION}

fi

 

This assumes to have the kernel module precompiled and prepackaged in the Slack Package under a modules/ subdir. Of course this needs to be improved to do version checking so it won't install the kernel module if the versions don't match.

 

I'd like this too.

 

But not for slackware (which has always seemed an odd choice).

 

ubuntu deb or a rhel compatible rpm would be the most useful for many people I suspect.

 

I'm not sure this will happen, and from looking at the code and as above I think things would need to be changed so the unraid md drivers didn't clobber the existing kernel ones so much.

 

Or at least changed so they can be loaded as a module at runtime rather than needing to be compiled in.

 

I don't think this is at all the focus of limetech with unraid.

As for the unraid md driver, to be pedantic... It isn't compiled into the kernel. It is loaded as a module at runtime. The only thing that's desirable is for it to use a different device driver name (perhaps 'ud' for unRAID Disks instead of 'md'). Maybe, then it could be placed into /lib/module/${KERNEL_VERSION}/extra.

 

As for your other topic...

 

That's an entirely different ball of wax. It may not be doable at all because of the way emhttp is coded to perform certain tasks, it expects certain files to exist in certain places and certain sequences to occur in a certain order. That may not be the case at all on the different distros. The efforts involved are substantially more difficult as significantly more unknowns exist.

 

So while it's something perhaps desirable for some, I'm going to completely ignore it within the context of this thread. Feel free to create a topic elsewhere discussing getting unraid running on a different distro, so it can get the attention desired.

So while it's something perhaps desirable for some, I'm going to completely ignore it within the context of this thread. Feel free to create a topic elsewhere discussing getting unraid running on a different distro, so it can get the attention desired.

 

package for slackware (or any other linux distro, particularly when they have a server version like Ubuntu and a few other offer).

 

I didn't realise I was off topic.

 

You are, of course, welcome to ignore it within this thread as you see fit.

 

I have contributed to a thread regarding getting unraid working under unbuntu and made some headway but, as you point out above, soon got tired trying to second guess emhttp's hardcoded file locations and expected formats. Part of the solution could also be to make these user configurable or set at compile time / runtime with mappings to distribution specific files and locations.

 

Interesting point about the module though.

I'm with you on this. emhttp should use a config file so that we could add/change path for needed utilities. Do we have a list of all the executable and libraries required? Well, for libraries we can find them with ldd (the list is actually not that long) so it is mostly for utilities. We can use strace but I don't know if we would find everything. And it can be long to analyze. Way better to have a config file that is fully supported/documented.

 

For the md, if somebody want to do more then just unraid, yes it could be a good idea to change the name to something else. As pointed, it is already loaded dynamically so it remove the issue of needed to recompile a kernel.

 

I've tried to play again with slackware 13.1 stock and to just add the md driver but... it seems that the kernel that is installed from the CD is not an easy one to modify just to add pvscsi (vmware paravirtual driver). I'll redo some testing with standard SATA driver to see if I get a quicker time to full install (even if not fully optimized for VM).

 

Will keep you posted.

 

ehfortin

Hi,

 

It has been a long time but I finally put some time into this. I have been able to compile a new md-mod.ko without recompiling the whole kernel but... I can't use it without recompiling the slackware kernel (or, up to now, any distro that is based on slackware like Salix and SMS where I got V5 beta2 to works as well). The reason is that "md" is already compiled in the kernel so... we can't just overwrite the module. There is also a dependency on the module "xor" which is related to "md" to calculate the raid parity.

 

So, I basically have to recompile the kernel just to put "md" as a module which I can then replace with the unraid version.

 

This means that if the driver could be renamed to something else like "unraid-md" for example, it could be compiled by itself against the kernel to create a module that could be loaded without disrupting the default "md". I assume there are some stuff that would need to be changed in emhttp or some others binaries maintained by Limetech but it would be the thing to do anyway. This way there would be no module alias conflict and everything should work.

 

This should also make the job to convert unraid as a package for Slackware relatively easy. The only missing link is to know if the original "md" and the new "unraid-md" would interfere during the boot process after the disks are discovered. I'm not familiar enough with this part to say but I expect it should be workable in some way if not directly as it is.

 

Any comments or ideas? Thanks.

 

ehfortin

 

 

 

 

Any comments or ideas?

 

What about Major/Minor device numbers, I had always thought there would be a collision between the unraid md and the software raid md drivers.

You can't just rename it.... you can't have both stock md and unRAID's modified md as they would conflict and step on each other.

To have them co-exist, would you need to rename the raw device name and the device Major/Minor numbers inside the kernel module and then do the same rename inside of all external management tools such as emhttp and also rename the kernel module name? And also have to switch from using /dev/md#/ to something different, like /dev/ud#/ assuming /dev/ud isn't used by something else already?

 

It's a lot of work that the community can't readily tackle because the management console has to change too.

Hey there,

 

Well, if unraid and md can't coexist and that's too much job, can I suggest that unraid is provided based on a customized version of slackware (or SMS or Salix) that act as a standard OS (like what we get when getting Unraid to work on Slackware by ourselves) so that we can easily add package? It also allow permanent config without having to script anything (as needed when starting from original Unraid installation)

 

I've get unraid working on SMS and Salix (core mode) and it is very pleasant to be able to do a slapt-get to install new packages with the dependencies without too much work.

 

I would think that it is relatively easy and quick to get Unraid on a core installation of Slackware 13.1 (reducing effort needed for now to a minimum) for version 5.

 

Would this make more sense based on current status and resource availability?

 

Thank you.

 

ehfortin

Hey there,

 

Well, if unraid and md can't coexist and that's too much job, can I suggest that unraid is provided based on a customized version of slackware

 

<snip>

 

Would this make more sense based on current status and resource availability?

You are assuming it is the desire of lime-technology to make it a full-customized version of slackware.  I strongly suspect it is not, and that the additional sales would not be offset by the huge increase in support needed.

 

unRAID is a network attached storage appliance.  It is not a print server, an torrent client, or anything other than bulk storage.

 

If any of us advanced users decide to make it more, it is our headache to support it, not lime-tech's.  I think their decision to simplify fits their business model.  To ask them for anything more is possible, but don't hold your breath waiting. 

 

The current 5.0 beta is the beginning to make it easier to add features to unRAID, but even then, it will only support the base network attached storage "md" device they created, and not anything else.

 

Good luck with your server.  Make it what you like, but the odds of seeing any change to the "md" driver in the direction you are stating is verrrrrrrrrrrrry slim.

Well, unraid is already running a customized version of Slackware but with large chunk removed. I would hope for a little bit less stripped down version and something that is on par with a specific version (like 13.1). This would help adding packages to Unraid.

 

Based on the fact that there is currently some evolution regarding a standard way of adding plugins, I would expect it would make sense to be inline with the existing features of slackware that would help adding packages that may be required for these plugins (a plugin is not much if it doesn't add functionalities). Lot of NAS device are now supporting media streaming, torrent, print server, etc.

 

I'm not asking Limetech to create their own packages of these services and to support them. I'm just proposing to base Unraid on an official distro release (like 13.1 is) that has sufficient tools installed to let us add other packages easily using the standard tools (slapt-get, slackpkg and the alike). Once that is done, people can be on their own and install additional packages like webmin which will help them to configure print server and other services without having to depend on Limetech for those (which means it should not increase the support needed).

 

There is so much documentation about how to install unraid on Slackware or how to create package on a dev machine and then move them to Unraid that I can only think it shows people want to do a little bit more then just NAS on their always on machine even if not supported. Nothing should change there but I can hope for an easier base setup that would allow that without having to revert to one of the two currently available alternatives.

 

Thank you for reading.

 

ehfortin

I believe unRAID is on par with slackware 12.2.

It's easy to add packages.

Download the slackware package and run installpkg.

Or put the package in /boot/extra and it will be installed on boot up.

 

unRAID is designed to run off a root ram filesystem.

The more applications and files you add, the more you have to spend on ram.

Then, more ram is wasted storing files that are not used that often.

 

A seasoned linux person can move /usr to a hard drive and install to their hearts content.

 

I personally don't see the need to put unRAID on a slackware system.

 

I like it running in root ram and being able to spin down every hard drive while daemons and applications still run from the root ram filesystem.

 

If I need to add something to unRAID I develop on a slackware system.

Create a package, drop it in /boot/extra and start unRAID.

Understood. UnRAID running from RAM is effectively another story which require a small environment. I'm not using it this way. I'm more on a permanent setup that sit on disk that would not be as minimalist as unRAID (certainly don't want a full desktop either. Something like Salix Core is just fine for me).

 

Anyway, in the meantime, I have my Salix server running UnRAID which is offering me everything I want. It is just not as straight forward as adding a package but... I'm getting better at it. I've done that on Slackware a few times and tried SMS, VectorLinux and Salix as well.

 

I've posted my interest for the unRAID package as well as for a more complete distro running from a disk. I'll let Limetech decide where they want to go from there.

 

Thank you for your comments.

 

ehfortin