Re: USB disk shows up late at boot
Celejar put forth on 12/21/2009 9:13 PM:
> I run desktops / laptops, and I always build netfilter - I run
> shorewall on all my boxes.
For me, the firewall is always going to be upstream of desktops in a properly
configured infrastructure. WRT laptops, I guess it couldn't hurt to run a local
packet filter, dropping junk destined for listening daemons.
> Hm, I tend to build everything that I possibly can (that I'm building
> at all, that I plan to actually use) as modules. Perhaps I should try
> building them into the kernel to see if there's a performance gain, but
> one reason that I like modules is that it makes for easy resetting of a
> driver - 'modprobe -r somemodule && modprobe somemodule'. Is there
> generally a way to do this with built-in modules?
That's one reason most people like modules, and they make sense, driver modules
that is, for laptops and desktops where folks will be plugging and chugging
various hardware regularly, such as USB sticks, printers, cameras, eSATA drives,
PCMCIA cards, cardbus, etc. Drivers can be loaded and unloaded automatically as
needed. I build all drivers I'm likely going to need directly into my kernels.
I include module support strictly for iptables, not drivers. I hate initrd
kernels. I prefer LILO not grub. Running recent kernels with initrd and
modules can cause problems with LILO due to the initrd size. The Lenny release
notes strongly recommend against using LILO because of this.
> I'm not sure that I understand this - how is it easier to provide a
> security fix for a standard kernel than for a custom built one? In
> both cases, one needs to obtain fixed code, build it, and replace the
> bad code with the good. [I'm not arguing with you, just expressing my
> confusion.] ...
Assuming the flaw is in driver code, not core kernel code, if I have all my
drivers built into the kernel at compile time, I have to rebuild everything from
source files to get the security patch included in my new kernel. With a
prebuilt kernel or a custom kernel that uses driver modules, one should be able
to merely grab a binary only copy of the fixed driver module code, unload the
old driver module, and load the new one. As I said, I don't run such systems,
so maybe I'm wrong here, but it seems logical that one should be able to do this.
> Agreed, and I get bitten by this all the time. Worse, often I disable
> some feature that I actually need, and then spend much time and
> aggravation figuring out why something is suddenly broken ... Well, I
> guess that's part of the valuable learning process that we discussed
> earlier :/
I recently went through this on an old IDE only server that didn't have libata
or sata_sil in the kernel. So, I compiled a new kernel with libata and
sata_sil, but didn't read the help notes thoroughly for libata. Those notes
state that while libata enables the SCSI layer, one still needs to enable "SCSI
Disk Support" and/or "SCSI CD-ROM Support" for SATA devices to work. I
overlooked this. Long story short, I was very upset after installing the SATA
PCI card and new disk, the kernel enumerating them, but not assigning /dev/sdX.
Much troubleshooting later, I found the help notes for libata in the menu,
enabled SCSI Disk, recompiled, rebooted, and voilla, I had /dev/sda.
Every time this kind of thing happens, I learn something valuable about the
kernel, and a lesson that sticks. ;)
--
Stan
Reply to: