Re: USB disk shows up late at boot
On Mon, 21 Dec 2009 23:02:53 -0600
Stan Hoeppner <stan@hardwarefreak.com> wrote:
> 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.
I agree that that's ideal, but I'm connected via a SOHO router (that
doesn't support OpenWRT). I suppose that I could add an additional box
to run a proper firewall, but that adds additional cost and
complexity. And on my laptop, it's definitely necessary, since I'm
often connected to insecure networks.
> > 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
I don't much like initrd myself, but I need it for suspend to disk, and
because I use full disk encryption.
> 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.
So this is an argument for a modular vs. monolithic kernel, not for
using stock vs. compling your own, which is what we're discussing here.
> > 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.
And that's a relatively straightforward one - I recently went through
this, which stumped several kernel experts for a while:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
My kernel wouldn't unlock the encrypted disk, apparently due to the
lack of some necessary crypto support - but I *had* built all the
necessary support! The problem turned out to be that the initramfs
hooks from the cryptsetup package failed to load all the required
modules into the initrd, due to an assumption mismatch between the
architects of the kernel crypto subsystem and the cryptsetup devs /
maintainers.
> Every time this kind of thing happens, I learn something valuable about the
> kernel, and a lesson that sticks. ;)
Yep!
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: