...making Linux just a little more fun!

<-- prev | next -->

Mailbag, Part II

Rick Moen has been forwarding messages from various other Linux venues ([ILUG], the [conspire] list, the comp.os.linux.setup newsgroup, etc.) for quite some time. These discussions have been sitting patiently waiting for me; the end of the year roundup seemed like the right time to dust them off with care and send them out to the world. Enjoy! - Kat


Linux malware, yet again

Rick Moen [rick at linuxmafia.com]
Mon, 14 Aug 2006 12:03:41 -0700

From: Michael Soibelman <not-here@there.net>
To: TAG <tag@lists.linuxgazette.net>
Subject: How do we know when we're there yet ?
Newsgroups: alt.os.linux.suse
User-Agent: KNode/0.10.4
Date: Fri, 11 Aug 2006 03:08:51 GMT
This is not flame bait. Just an observation. As many of you know, I am a regular here. I try to help as many posters as I can. Though I am not a guru, I do have some knowledge and often get a "Thanks very much" from OPs. I've been using Linux since 1999 for 99.5% of my computer needs, and have finally made the transition to 100% after I got my scanner working. Though it did work for a while, the change to the 2.6.x kernel broke something needed for my scanner to work. So I kept a copy of W2K around just for the occasional image scan.

One of the programs I found while still a Windows user was a virus scanner from Trend Micro called PCcillin. Probably the best virus scanner for Windows users available. I say that because I had tried a few others and then, when I tried PCcillin it found several viruses the others had missed. Take it from someone who had actually had a hacker break into my box and physically fry my hard drive...this was a lesson well learned. Since the time I switched to Linux, I still have friends who use Windows. And I always recommend that if they are going to continue using Windows that they should buy PCcillin... I don't recommend using Windows, but if they must, at least they should get the best protection possible. I've convinced several people of the wisdom of using this anti-virus software and all have thanked me several times over. All have been saved by this program...

So, going back to my original question in the title of this article, how do we know when we're there? I have several anti-virus and anti-spam applications that are all free as in cost and free as in freedom installed. Also, a couple of rootkit detectors as well as port scan detectors, etc... So I think I'm pretty safe. Never have had any problems since I switched OS. But I'm sure the day will come when some clever hacker will (finally) produce a Linux virus... Mark my word, the day will come! But, as I said, I'm ready, as I'm sure most Linux users are. I just wanted to point out the fact that my favorite Windows anti-virus company has realized that the Linux users are a substantial market force. And, after all the wait, there free as in cost, online virus detection service is available for Linux! It's called 'House Call' and it works.... Free... Just like in Windows... You'll need to use Firefox or, well I forget the other Linux browser that works, but it does work.

I'm NOT saying anyone should spend there money on this product.. Just pointing out that there is one more commercial company to recognize the Linux community and offer their services/products. In the meantime, I'll just keep using the other free products available to Linux users. F-Prot is free for personal use. Of course ClamAV (with KlamAV front end) is a must. Spam Assasin, Bogofilter, etc... are all great programs that I highly recommend.

[ ... ]

[ Thread continues here (1 message/17.69kB) ]


Making your own distribution

Rick Moen [rick at linuxmafia.com]
Tue, 18 Jul 2006 13:53:02 -0700

-- forwarded message --

From: Rick Moen <rick@linuxmafia.com>
To: TAG <tag@lists.linuxgazette.net>
Subject: Re: Making your own distribution
Newsgroups: alt.os.linux.suse
Date: Tue, 18 Jul 2006 16:17:58 -0400
bowman <bowman at montana.com> wrote:

> houghi wrote:
> 
>> Don't like ?the distribution you are working with? Make your own. Not
>> that hard with some dedication to base it on SUSE.
> 
> http://www.eweek.com/article2/0,1895,1982942,00.asp?kc=ewnws062806dtx1k0000599
> 
> The gist of the article is providing the source can be a hassle.

But it really isn't. E.g., you can cut source CDs for the few people who receive copies of your GPLed binaries and request source within three years, charging them in advance for the cost of producing and mailing them. If that's a "hassle", outsource it to one of the cut-rate CD-burning houses such as Cheapbytes; I'm sure they'd appreciate the business, and you'd bear neither expense nor hassle yourself.

> We got into this with Cygwin. We install Cygwin on some customer sites
> solely for some of the popular Unix CLI utilities our support people
> prefer. Other than that, we do not modify, compile with, or otherwise
> touch a thing.  Referencing the current Cygwin source is not
> sufficient; the reasoning is the source may change and no longer match
> the packages we distributed. 

Cygwin is a mixture of GNU GPL and MIT X11 licensing. For the GPLed packages, if your distribution of it was non-commercial, you can meet your source-access obligation by referring people to where you got the software from. Otherwise, you have the above-referenced three-year obligation, for which you may pass along all costs to those requesting source.

Going by experience, the number of people actually willing to order a source CD once you've clarifed that it's not on your dime is almost nil. (I used to take care of this issue at a large Linux hardware firm that maintained and distributed its own full version of Red Hat Linux. Care to guess how many people requested source CD sets? One, over three years. We sent them free, with our compliments.)

The eWeek article? Oh, right. It's mostly notorious whiner Warren Woodford of MEPIS Linux complaining because he didn't bother to read the GNU GPL, massively violated the copyrights of programmers whose terms he failed to obey, and got his hand slapped.

Reporter Steven Vaughan-Nichols, who's usually really good, said:

Woodford recently ran afoul of the GNU GPL (General Public License) requirement that downstream distributors of GPL code are obligated to provide source code to users in an easily accessible format.

[ ... ]

[ Thread continues here (1 message/4.64kB) ]


[ILUG] Porting drivers from Windows (rant)

Rick Moen [rick at linuxmafia.com]
Wed, 6 Sep 2006 11:20:17 -0700

[ boggle ]

----- Forwarded message from ronan at iaa.es -----

Date: Wed, 6 Sep 2006 19:07:10 +0200
To: ilug at linux.ie
From: ronan@iaa.es
To: TAG <tag@lists.linuxgazette.net>
Subject: [ILUG] Porting drivers from Windows (rant)

Hi all, I'm currently writing Linux support for a piece of custom hardware - I have Windows source code for hardware drivers and data conversion algorithms, and I'm porting/re-writing that to Linux and I am beyond unhappy at some of the intrinsically stupid things I am seeing.

Today's little bundle of joy regards writing to device registers. It's not actually so complicated - the I/O regions are set up automagically during boot, your driver basically just has to tell the kernel (a) that it now owns the appropriate region, and (b) how it wants the region to be made visible to it. Then you go and poke the registers that live there, and the hardware goes and does what you said to. Drive carefully.

Now, in the Windows driver, there is a little snippet of code like the following. It's part of the wake-up sequence for the hardware:

    #define CTR_REG 0x4000
    ...
    WRITE_REGISTER_ULONG(CTR_REG,0);
How obvious - it writes the value 0 to a 32-bit register located at 0x4000. This is kindergarten stuff. If you don't believe me, read this page: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k103_af58a3ec-4102-4a89-9c58-e56f99d793d0.xml.asp

which says (the very first line): The WRITE_REGISTER_ULONG macro writes a ULONG value to the specified address.

So, yea, we nod wisely, and write the equivalent under Linux, which happens to be

    iowrite32(0,CTR_REG);
And yea, we would make many attempts to get a response. We would poke and prod. We would reboot into Windows and check that the hardware still worked. Was the hardware sulking because we missed some vanishingly obscure initialisation step? We would examine our documentation again and again - was it possible? We would try and trick the damn thing. We would sacrifice goats. Nada. Not a whisper of response.

Because, of course, the register isn't at 0x4000 at all.

It is (where else?) at 0x10000 (i.e. 0x4000 * 4).

Think about it...... and let the nausea sink in.

For those it hasn't hit yet, some genius in Redmond decided that, when talking about 32-bit quantities, they were going to count 32-bits at a time, like C array notation. ("Hey Bill! I know this really cool way of implementing WRITE_REGISTER_ULONG!"). Of course, they're still going to call them "addresses".

[ ... ]

[ Thread continues here (1 message/4.08kB) ]


[conspire] Compromise of a Debian Project host

Rick Moen [rick at linuxmafia.com]
Mon, 17 Jul 2006 08:28:39 -0700

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 17 Jul 2006 02:50:25 -0700
To: conspire at linuxmafia.com
From: Rick Moen <rick@linuxmafia.com>
To: TAG <tag@lists.linuxgazette.net>
Subject: [conspire] Compromise of a Debian Project host
Early in the morning (European time) of last Wednesday, July 12, the Debian Project figured out that one of its shared Internet hosts, "gluck.debian.org", had been security compromised, and immediately took it down to be studied, rebuilt from trusted program files, and back within a day. It look like, as with last time this sort of thing happened, they detected the compromise pretty much immediately -- probably courtesy of monitoring from the intrusion detetion software "AIDE". As before, the package archives weren't penetrated. ("gluck" currently fills these roles via DNS aliases: "cvs", "ddtp", "lintian", "people", "popcon", "planet", "ports", and "release". The machines where packages are created and cryptographically signed are much more heavily restricted.)

Their quick detection and correction are worth noting. So is the avenue of compromise (detailed below).

Also worth noting is that, if you use your security token on a compromised machine anywhere, it's equally prone to be stolen regardless of whether it's a strong or weak password, or a public SSH keypair, etc.

Debian believes in transparency on security matters, which is why the earlier (2003) compromise of "klecker", "gluck", "master", and "murphy" was immediately and extensively analysed in public, on a set of pages maintained by Wichert Akkerman: http://www.wiggy.net/debian/explanation/

...which I then wrote about, here: http://linuxgazette.net/issue98/moen.html I'm looking forward to a similar disclosure about the 2006 compromise.

Meanwhile, there's this Debian News article: http://www.debian.org/News/2006/20060713

At least one developer account has been compromised a while ago and has been used by an attacker to gain access to the Debian server. A recently discovered local root vulnerability in the Linux kernel has then been used to gain root access to the machine.

At 02:43 UTC on July 12th suspicious mails were received and alarmed the Debian admins. The following investigation turned out that a developer account was compromised and that a local kernel vulnerability has been exploited to gain root access.

[ ... ]

[ Thread continues here (12 messages/35.10kB) ]


Domain report for linuxgazette.net

Rick Moen [rick at linuxmafia.com]
Mon, 15 May 2006 19:17:25 -0700

Just so you know, this few nits for a domain is utterly outstanding.

[ ... ]

[ Thread continues here (1 message/5.00kB) ]


State of the anti-spam regime, July 2006 edition

Rick Moen [rick at linuxmafia.com]
Thu, 20 Jul 2006 18:41:22 -0700

Ben recently called my attention to incoming mail being rejected at my SMTP server because the system SPF daemon could not be reached. More recently, about an hour ago, a flurry of spam snuck through the system because the SpamAssassin daemon had died. And Exim4 (the SMTP daemon) has occasionally entered a fault mode where a queued-up message is processed repeatedly.

All of these epiphenomena turn out to have the same underlying cause: Baby needs new shoes.

Just as a frog put in a pot of cold water and brought slowly to a boil will not jump out and save himself, mail servers reach the brink of failure by... um... degrees. In this case, what's been happening is that my server's meagre 256MB of RAM is being badly overstressed.

The repeat-sending syndrome was an early clue: The queue-handling Exim4 instance would send the queued mail out, and then call a different routine to process final steps including deletion that just happened to require more RAM, which was not available so the Exim4 instance died before cleanup could occur.

At the same time, I've sung the praises of GNU screen so effectively that several other shell users (Hi, Karsten! Hi, Ben! Hi, Thomas![1]) have joined me in leaving it running 24x7 running (sometimes) large jobs -- more RAM gone. And last, the volume of incoming spam continues to increase and find new tricks, while my primary SMTP-layer defence of Exim4 rulesets isn't being updated because the host is a lame-duck installation intended to be retired.

Right behind the primary defence, intended to backstop spam that gets past Exim4's rules, is -- guess what? SpamAssassin, a rather large, slow, and RAM-grabbing Perl script, running in daemon mode and spawning more instances as needed. The busier and slower it gets, the more RAM-grabbing instances.

So, we've been getting weird MTA repeated-mailing behaviour, and mysteriously dying processes: The kernel OOM-killer gets set loose, and starts shooting large and/or busy processes in the head. If I'm lucky, it's one of my mutt instances running under screen and reading one of my carelessly overlarge mbox files. Or screen itself. If I'm unlucky, it's spfd. Or SpamAssassin. Or Exim4. Or Apache httpd. Or BIND9. All of those have happened.

The pattern was obvious, but I've been reluctant to see it, in part because it's a pain to deal with.

The only fix is to debug my problems with the intended replacement box (needs a kernel with ability to load the root FS from software RAID1), configure its daemons for the needed services, sync up all data files, and do a flag day. The new box is better in every way, including its 1.5 GB of system RAM.

I need to do that. You guys really can't. I just need to find the time.

In the meantime, I'm using screen less. (Karsten, if you can help in that area, too, that would be appreciated.)

[1] Latter two names being a guess -- and it's not like there's anything wrong with using screen. It's great stuff.

[ ... ]

[ Thread continues here (5 messages/10.89kB) ]


Barry O'Donovan is being removed

Rick Moen [rick at linuxmafia.com]
Thu, 6 Jul 2006 17:56:55 -0700

I used to wonder what "unroutable address" meant in SMTP Delivery Status Notification messages, as it has always seemed more than a bit vague. It turns out, it is vague. ;-> It's the default Exim return value if a message gets evaluated against all the Exim "router" handling routines to see if it meets any of their criteria for acceptance. If not, it falls through and generates return value text "unrouteable address" by default (http://www.exim.org/exim-html-4.40/doc/html/spec_3.html#SECT3.10). The question then becomes why, in each case. For TAG subscriber Barry O'Donovan <gazette at barryodonovan.com), only a little checking was required to find out:

  $ dig -t mx barryodonovan.com +short
  ;; connection timed out; no servers could be reached
  $ dig -t a barryodonovan.com +short
  ;; connection timed out; no servers could be reached
  $ whois barrydonovan.com | more
 
  Whois Server Version 2.0
 
  Domain names in the .com and .net domains can now be registered
  with many different competing registrars. Go to http://www.internic.net
  for detailed information.
 
  No match for "BARRYDONOVAN.COM".
  >>> Last update of whois database: Thu, 06 Jul 2006 20:35:56 EDT <<<
 
  [...]
Because Barry's domain no longer exists, I've been getting one of the below-cited nastygrams every time anyone posts to TAG. So, I'm setting his subscription to "nomail" in case he fixes his domain. ('Course, he might never figure out why he's ceased to receive TAG mail, but that's the breaks.)

----- Forwarded message from Mail Delivery System <Mailer-Daemon at linuxmafia.com> -----
  
Return-path: <>
Envelope-to: rick at linuxmafia.com
Delivery-date: Thu, 06 Jul 2006 16:58:46 -0700
Received: from Debian-exim   by linuxmafia.com with local   (Exim 4.61 #1 (EximConfig 2.0))
	 id 1Fydk5-0000uS-5f   ; Thu, 06 Jul 2006 16:58:45 -0700
X-Failed-Recipients: gazette at barryodonovan.com
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon@linuxmafia.com>
To: TAG <tag@lists.linuxgazette.net>
To: tag-bounces at lists.linuxgazette.net
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Fydk5-0000uS-5f at linuxmafia.com>
Date: Thu, 06 Jul 2006 16:58:45 -0700
X-SA-Do-Not-Run: Ja X-SA-Exim-Connect-IP: <locally generated> X-SA-Exim-Mail-From: X-SA-Exim-Scanned: No (on linuxmafia.com); SAEximRunCond expanded to false This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: gazette at barryodonovan.com Unrouteable address ------ This is a copy of the message, including all the headers. ------ [ ... ] ----- End forwarded message -----

[ Thread continues here (4 messages/7.53kB) ]


[conspire] Safe NTFS read/write driver for Linux

Rick Moen [rick at linuxmafia.com]
Tue, 18 Jul 2006 15:03:09 -0700

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 18 Jul 2006 14:34:02 -0700
To: conspire at linuxmafia.com
From: Rick Moen <rick@linuxmafia.com>
To: TAG <tag@lists.linuxgazette.net>
Subject: [conspire] Safe NTFS read/write driver for Linux
http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697

(I'm posting that URL for future reference, since I expect to keep hearing people say for years into the future that Linux NTFS support is unsafe.)

The author is the same gentleman who wrote ntfsresize, and helped me extensively with my knowledgebase's article on NTFS resizing.

From: Szakacsits Szabolcs <szaka at sienet.hu> [announcement] ntfs-3g: open source read-write driver 2006-07-14 10:39

As part of the Linux-NTFS project, I'm happy to announce my contribution to ntfsmount and libntfs which resulted ntfs-3g, a read-write ntfs driver, capable for unlimited file creation and deletion. The driver was successfully tested very exhaustively for a longer period of time by many ways and methods, creating and destroying millions of files and directories on newly created images, and on over 40 real, very diverse NTFS images collected over the last four years. The README file is copied below which includes more general, performance and quality information with answers and future plans. Please make a backup of your NTFS volume by ntfsclone and try to reproducible break ntfs-3g, if you can. If you are able to do so then please let us know, preferable providing your NTFS metadata image, if it couln't be reproduced by other ways. The driver can be downloaded from http://mlf.linux.rulez.org/mlf/ezaz/ntfs-3g-20070714-BETA.tgz Please note that I'm leaving for an over 5,000 km long Far North and Arctic Ocean advanture on Sunday morning (European time) and won't be able to read and answer emails for almost a month (no, I'm not escaping, I plan to come back alive ;). Originally I planned to fix all the minor issues listed below but no more time left for me and I think it's better to release now, in case I would get lost somewhere on the road ;) Well, actually I hope that most issues will be resolved when I'm back! Happy testing, problem reporting and coding, -- Szaka

[...]

I expect I'll be needing to Google-search this post quite a lot, in the future, to refute the inevitable claims to the contrary.

----- End forwarded message -----

[ Thread continues here (2 messages/4.49kB) ]


A thread about nobody

Rick Moen [rick at linuxmafia.com]
Fri, 23 Jun 2006 12:42:04 -0700

Being submitted as grist for the TAG-publication mill. Attached.

Date: Fri, 23 Jun 2006 11:14:32 -0700
From: Bill Kendrick <nbs@sonic.net>
To: TAG <tag@lists.linuxgazette.net>
To: LUGOD Tech <vox-tech at lists.lugod.org>
Subject: Re: [vox-tech] Purpose of "nobody" user?
Yesterday, I was helping Melissa add a user account to her laptop. I decided to just point her at KDE's "Kuser" (K->System->"User Manager") GUI tool, mostly because I wanted to see it. ;) ("adduser" is not hard to use, but I figured most non-Unix-types would go hunting a GUI tool, so wanted to familiarize myself with it.)

One thing she noticed was the user "nobody", which sounded supsicious. And it had quite an insane UID (65534), compared to other user accounts. Her first thought was to Google for 'nobody 65534', and found many, many posts where people had obviously dumped their /etc/passwd to a mailing list for help with this-or-that. Based on this, she seemed happy enough to know it's just some "thing" that Linux does/has.

For the life of me, I couldn't really explain what "nobody" is used for. I'm familiar with it in terms of NCSA httpd and Apache, but beyond that... A little help, here? :^D

Thx!

-bill! (PS - Google for '"nobody user" OR "user nobody" purpose linux' wasn't as helpful as I had hoped. :^/ I also tried throwing 'FAQ' in there ;^) )

From: Rod Roark <rod@sunsetsystems.com>
To: TAG <tag@lists.linuxgazette.net>
To: LUGOD Tech <vox-tech at lists.lugod.org>
Date: Fri, 23 Jun 2006 11:50:20 -0700
Subject: Re: [vox-tech] Purpose of "nobody" user?
On Friday 23 June 2006 11:14, Bill Kendrick wrote:

> For the life of me, I couldn't really explain what "nobody" is used for.
> I'm familiar with it in terms of NCSA httpd and Apache, but beyond that...
> A little help, here?  :^D
I'll take a stab at this.

The way I would explain it is that a *nix system has a variety of users that are non-human.

They are users in the sense that they run processes that do not require privileges to other parts of the system, and they maintain resources (e.g. files and directories) to which other parts of the system do not need access. Therefore it is convenient and sensible to isolate them from human users and from each other in the same way that human users are isolated from each other.

The general idea is that your system is more secure if access is not granted where it is not needed. A non-human user may be a security risk if, for example, it runs a program containing a flaw that lets someone break in and run tasks with the privileges of that user.

I suppose someone chose the name "nobody" for one of these users simply to emphasize that it's not human. But there are many other examples of such users, like apache, bind, daemon, mail, mysql and news.

I hope this is not too condescending... I wrote it this way so that newbies may also find it useful.

Rod

[ ... ]

[ Thread continues here (2 messages/8.57kB) ]


SRS development

Rick Moen [rick at linuxmafia.com]
Wed, 30 Aug 2006 19:22:58 -0700

Ben suggested I forward this mailing list post here, as it's relevant to my recent article submission. [http://linuxgazette.net/131/moen.html]

----- Forwarded message from rick -----

Date: Wed, 30 Aug 2006 19:00:21 -0700
To: luv-main at luv.asn.au
Cc: ben at linuxgazette.net
Subject: Re: SRS development
Quoting Daniel Pittman (daniel at rimspace.net):

> I wish you wouldn't.  SPF is great, in theory, but not really so hot in
> practice.  Using it will only encourage others to adopt it.

There's a lot of confusion about this. Let's dissect it into parts:

o  SPF reference records within a domain's DNS:  These allow the domain
   administrator to specify which IPs are those of the domain's 
   (and optionally, various subdomains') sole intended MX hosts -- 
   along with suggestions as to the degree of confidence that the 
   admin feels receiving SMTP hosts should grant to that data.
 
o  SPF-checking routines executed by a receiving SMTP host's MTA 
   during the incoming SMTP session, prior to saying yes or no to
   the delivery attempt.  (It's also possible to check SPF RRs at later
   points, such as during MDA execution, but less useful.)
Speaking from a domain administrator's perspective, one has _no downside_ from publishing SPF RRs for one's domain. It's good and useful data, providing the public with a definitive means of detecting and rejecting mail forged to dishonestly claim your domain as its origin, even mail competently forging the 'envelope From' and Return-Path headers (Joe Jobs). It's categorically useful even to domain admins who favour alternate approaches. I.e., is you think Hadmut Danisch's Reverse-MX (RMX) proposal was better designed, or Yahoo's DomainKeys, or SPF plus Meng/Microsoft's Purported Responsible Address (PRA) header, or S/MIME, or Email Postmarks, or a full gpg web-of-trust architecture, or BATV, or Jim Fenton's Identified Internet Mail -- then nothing stops you from participating in all of them, if you wish.

It would be a Good Thing even if nothing like SRS (Sender Rewriting Scheme) had even been attempted, and every forwarding mechanism on the globe other than mailing lists (which have rewritten 'envelope From' and Return-Path all along) were to instantly and permanently break.

Why? _Because I own domains._ I'm therefore tired of spammers and malware authors being able to Joe Job them believably. Why would I not spend five minutes writing a TXT RR that makes crystal clear that mx4.pinkmeatproducts.com isn't a legitimate source for my domains' mail?

'No so hot', you say? OK, compared to what? The relevant comparison for a domain owner is: extant SPF record versus none. Do you honestly assert that my domains would be better off without them? If so, please do explain.

[ ... ]

[ Thread continues here (17 messages/100.57kB) ]


Kernel 2.6 installation support for fakeraid HBAs

Rick Moen [rick at linuxmafia.com]
Tue, 18 Jul 2006 16:15:16 -0700

From: "magnate" <chrisc@dbass.demon.co.uk>
To: TAG <tag@lists.linuxgazette.net>
Newsgroups: comp.os.linux.setup
Subject: Debian installer does not recognise ataraid array
Date: 18 Jul 2006 03:14:30 -0700
I have two SATA HDs on a Silicon Simage 3112 RAID controller. This is known as "fakeraid" or "ataraid" because it's not a proper hardware RAID controller, it just buggers about with on-the-fly address translations in the controller's BIOS. So it's a bit like software RAID - and indeed inferior to Linux software RAID - but this is a dual-boot box, which is why I'm using it. (Honestly, it makes Windows a lot faster, like 50%+.)

So, I want to install Debian on it. I managed it under 2.4 by manually coaxing the medley.o module into place, to recognise the array and let me install on it. On the way I found and reported several bugs: a conflict between siimage.o and via82cxxx.o (which is still unsolved in kernel-source-2.4.27), the fact that ataraid modules were not loaded by the installer, and the fact that medley.o was missing from the mkinitrd script, which meant that I couldn't boot after the install!

I'm not sure if that second one is solved yet, but it doesn't matter because this time I'm trying to install 2.6 (I am reinstalling rather than upgrading because I made a ton of changes to the partition structure). I know that 2.6 doesn't use the medley module, and that all the fakeraid stuff is dealt with by something called the device mapper, and a user-space tool called dmraid.

Unfortunately I don't know any more than that, like how they work. When I use the latest Debian installer CD, it boots 2.6 and finds all my hardware and offers me sda and sdb as my HDs - it completely fails to notice the fakeraid array.

Yes I have brought this to Debian's attention, but I'm asking here because I really need to just know a few more basics about ataraid handling in 2.6.x and the device mapper - can anyone point me towards a HOWTO or idiot's guide for that?

Grateful also for any other advice on how to diagnose this problem. I presume that the low-level hardware driver (sata_sil.o in this case) is still needed - this is what's finding sda and sdb. But I don't know what to do once that's loaded to find the ataraid array, and therefore I don't know how to find out where the Debian installer is going astray.

Rgds, CC

From: Michael Heiming <michael+USENET@www.heiming.de>
To: TAG <tag@lists.linuxgazette.net>
Newsgroups: comp.os.linux.setup
Subject: Re: Debian installer does not recognise ataraid array
Date: Tue, 18 Jul 2006 22:13:55 +0200
User-Agent: tin/1.9.1-20060409 ("Benmore") (UNIX) (Linux/2.6.17-mh (i686)) tinews.pl/1.1.7
In comp.os.linux.setup magnate <chrisc at dbass.demon.co.uk>:

[ ... ]

[ Thread continues here (2 messages/11.51kB) ]


Talkback: Discuss this article with The Answer Gang

Copyright © 2007, . Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 134 of Linux Gazette, January 2007

<-- prev | next -->
Tux