I've a pair of Dell PowerEdge T110 II servers with what Dell calls Unified Server Configurator with I'm assuming (silly me) is UEFI (sure smells that way) and no operating system (so no Windows pollution to deal with but I'm not sure about UEFI on a raw box).

Before I start installing Slackware 64-bit 14.0 on these guys, I'm wondering what sort of trouble I might expect; e.g., am I going to be able to boot from the MBR, set the hardware clock to UTC, do I want to RAID the things (they have two 500G drives) with the built-in RAID controller, little things like that (I am willing to forgo RAID and use the second drive for data base storage, the second server being used as a development platform and back up for the first sever). Not real sure about doing RAID in any event, but is it worth doing on a two-drive server? Just those little details that can come back to haunt you.

Also wondering if it's worthwhile to wait a week or two for Slackware 14.1 -- never had a problem upgrading from one release to the next but, you know, maybe worth a wait? Don't really want to download (I prefer installing from DVD and have a subscription). Of course there are folks champing at the bit so that may be moot -- get it going now and worry about upgrade later if you know what I mean: users!

Just wondering if there's any gotchas and would appreciate any advice before I get bit.

Unified Server Configurator is software installed to a flash memory chip inside the server. You can select it from the boot menu, and perform tasks like flashing the BIOS and managing RAID volumes, as well as installing an OS on the server. It has nothing to do with UEFI.

Unified Server Configurator is very similar to the Intelligent Provisioning software found on HP Proliant Gen8 servers. Previous server models came with an installation DVD (HP called it "SmartStart") that automated the installation of a number of different OSes, from partitioning and license keys right down to the installation of drivers and management software. This software is now built into the server itself (but can be removed, reinstalled and upgraded with bootable DVDs).

If you're planning on installing a non-mainstream OS like Slackware, USC will be of no use to you. But it won't get in the way either.

1 members found this post helpful.

Thanks for clearing that up.

Don't really know if Slackware is a "non-mainstream" distribution, though, especially after just celebrating the 20th anniversary.

Onward and upward.

1 members found this post helpful.

Probably, judging by some of the misguided reviews it gets.

IMO there is no risk trying.

About 14.1 and if I may extrapolate from former development cycles, I wouldn't expect a release sooner than one month or two, as there was no announce of an RC yet in a Current (pre-release) ChangeLog. But of course that's only a guess.

So I'd install Slackware 14.0 and delay the decision of replacing or upgrading or keeping it till the official announcement of 14.1. Anyway I'm sure you will have made backups of all your important data, so whatever be your choice you shouldn't encounter big issues.

Yeah, that's kind of what I figured too. Can't remember how many upgrades I've been though (lots, though) and it's always been a clean process, one of the many things I like about Slackware (and why I'm doing these servers with Slackware, for that matter).

Thanks.

tronayne,
You were asking about raid/noraid - and I guess there are as many opinions about that as posters ...
_My_ opinion - for whatever its worth - is to stay away from raid - particularly if you have only two physical drives. What can you do with 2? - basically mirroring or striping. The downside with striping is that if one disk goes - you are well and truly snookered. Mirroring - I guess that would work, but again - even if one drive goes, there's a lot of work involved in the salvage operation. Had it been me, I would set up an OS (read slackware) partition and then use the rest for data. Then use the 2nd disk as a data backup (eg. run rsync say 2am - crontab). Somehow, I have always shunned raid simply because recovery can be a real headache - just look at the partition-types of a raid system!! The same problem you have with striping, will be the same if you use lvm ... so - if it were me - keep'em as seperate disks and use one for backup of user data - the OS itself is easily redone, so just keep OS and userdata/userapps seperate from the OS.

Now - if you have several disks - say 10 or so - then it becomes a different matter - then raid is a real possibility, infact - even _I_ would use it in that case.

If I may suggest a setup ... use the following partition setup for both disks:
#1 - OS - 20 gigs
#2 - swap (if you need it)
#3 - userapps and data (remainder of disk)

Then, for your backup, you just use the blkid of partition #3 on the 2nd drive and mount it, then run rsync and then umount it ...
This way, the backup disk will keep spinning, but it will only be mounted during the actual backup. If your main disk goes, then its easy enough to reinstall the OS on the 2nd disk, remove the offending disk and just keep going ...


Obviously though, if you need the greater part of 2x500 gigs for data, then this wont work and you have to use striping (raid-0) or lvm ...

1 members found this post helpful.

Your opinion is worth quite a lot (at least to me) and I thank you for sharing it.

I have a goofy way of partitioning disks. I do swap (2X RAM), 15-20G root, /home, /opt, /usr/local, /var/lib/mysql, /var/lib/pgsql, /var/lib/virtual and whatever is left that I call /spares (typically for large GIS data files). What that allows me to do is a clean install of a Slackware release without destroying everything else (/etc is copied off to /spares, local fonts are too -- I have the Adobe Type Library -- and maybe some other stuff).

Now these two servers aren't going to look exactly like that -- there won't be any GIS, there won't be any virtual machines (well, maybe, someday), there won't be any licensed-to-me software. The primary job of these things is to run DSpace, storing a fairly large repository (think Smithsonian writ smaller without the bugs, bones and airplanes but pretty much everything else). I'm thinking syncing one with two in the middle of the night and possibly syncing with an external site while I'm at it just in case (I, like pretty much everybody else have had catastrophic disk failures). These servers are going to follow the same partitioning scheme just because I've found that it works for me on my own four servers.

I have been reading and thinking about RAID and, well, I'm thinking no, not now, maybe someday. Studying up on RAID I just kind of got to... well, no, don't want to do that (and a RAID array of disks is more expensive than the organization can afford at the moment). Could come back an haunt me, but I think I'll have enough redundancy to cover our butts for the next five or so years. The disk-intensive stuff will be on the second drive leaving the first drive to do the system workings. Cripes, I've been looking at tape cartridge back up boxes (I'm old, I kind of like those carousel contraptions for hot back up but, lordy-do, they are expensive!) and disk drive array gadgets (ditto on the expensive part).

I've gotten down to back up the main server to the secondary server with rsync periodically (meaning at least every night) and maybe sign up for some cloud service. RAID is attractive but... well, I don't think so for now. The other problem is that I'm coming up on 70 and don't know how long I'm going to be able so I want to have the thing as easy as possible to understand and as automated as it can be -- all the folks involved are smart and diversified talented but they ain't computer geeks and that must be taken into consideration. Fortunately there are a couple of guys that are Linux savvy and they're willing to volunteer now and again so I think we're covered.

So, anyway, thank you for your thoughts, I do appreciate you taking the time and trouble.

OK, maybe not what you'd like to do, but this is something worth considering-

Take out 1 x 500GB or even both 500GB HDDs from one of the machines. Install them in the other machine with RAID5 or RAID6 (and depending on exactly which controller you have, maybe use mdadm)

Buy a 1-2TB drive, put it in the discless machine.

That way you've got a RAID arrary for data protection, and another machine with enough HDD space to rsync all the data on the RAID array to a large, single drive.

I'd probably also get 1 or 2 small SSDs for the OS if its not too expensive.

I tend to use mdraid 1 with 0.9 metadata so that the kernel will autodetect them and bring them up. And yes I've had one drive fail and the other just kept going. Of course my setups tend to be:

I uses extlinux from syslinux:
sda1 ext2 /boot
sdb1 ext2 /boot

I dislike initrd so I use / as something like that
md0 ext4 /
With sda2 and sdb2 as it's members

And then:
md1 as LVM
with sda3 and sdb3 as it's members.

And everything else like /usr, /home, swap, etc... is carved out of that LVM.

*chuckles* Oh you ole man, you! You've got me beat by 2 measly years!!
As far as partitioning is concerned, we all do what we have to do - or rather, we do what works best for each and every one of us - there is no single shoe fitting every foot!

Me, I'm an addicted distro-hoe (though, in all earnest - these days they are all running slacks), never have less than 3 different distros on every one of my rigs. This is why I put everything on one partition and never use /home for other than dot-files and config-files. Makes it easy when something new and shiny catches my eye and I've just gotta try it *lol* After a couple of weeks the novelty wears off and I'm back to being a slacker again ...

Since this kinda relates to this MRB/UEFI topic, I ran across this article on GPT (GUID Replacement Table) vs MBR. Just curious if any of you have used it and how it's working out for you.

https://www.linux.com/learn/tutorial...e-ancient-mbr-

That last sentence is not even remotely correct.

Recovering from drive failure in a RAID array using any RAID level other than 0 is as easy as pulling the old drive and inserting a replacement drive. You don't even have to manually initialize a rebuild with most controllers, it all happens automatically.

An important fact to remember is this: All drives will fail eventually, and often suddenly and catastrophically (SSDs are the worst in that respect). Even if it fails slowly by growing a steadily increasing amount of defects, and you have smartd running to alert you of this fact, you'll still have to power down the server to replace the drive and migrate data from the old drive (or restore from backup if the drive is too far gone). Now that takes time and effort.

A RAID setup can handle a scenario like the one above without so much as a hiccup. No downtime, no restore, no drive imaging. Add to that the fact that hard drives are cheap while downtime (not to mention your time) is not, and I think it's fair to conclude that running a server without RAID makes very little sense.

1 members found this post helpful.

It most certainly is if you don't have a spare drive around with larger or equal capacity.
I have been on the receiving end of countless (well, maybe not countless, but sufficiently many) who has come with all weird and wonderful rigs with raid-1 ... when you are left with just the one (out of two) - that is _not_ a no-brainer. With 2 disks, I always run a rsync in the early morning hours rather than using raid *shrugs* each to his or her own ....

Why can't you just run the degraded array while you order another hard drive? A RAID-1 setup should run just fine with one disk.

1 members found this post helpful.