USB disk shows up late at boot
in [Debian]
|
From: Celejar on 21 Dec 2009 21:30 On Mon, 21 Dec 2009 21:07:08 -0500 Paul Cartwright <ale(a)pcartwright.com> wrote: > On Mon December 21 2009, Stan Hoeppner wrote: > > I do: stick with your homegrown kernel. > > > > (From the guy who only uses custom kernels) > > what would I gain from using a custom kernel, what would it take to > make/install one, ( a how-to?). > for a "regular" desktop user, web, email... what advantage is there?? Many argue, not much, but I can see the following: 1) Faster booting, since irrelevant drivers aren't loaded and won't spend time probing. 2) Security - one of these null pointer dereferences that they keep discovering can't hurt you if it's in code that hasn't been included. 3) Education - it's an unbeatable way to get a deeper knowledge of your system. 4) Flexibility and control Note that I'm not expert, and these are just my opinions, and may even be factually incorrect. 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 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stan Hoeppner on 21 Dec 2009 22:00 Celejar put forth on 12/21/2009 8:22 PM: > 1) Faster booting, since irrelevant drivers aren't loaded and won't > spend time probing. Correct. And not just drivers. Prebuilt kernels usually include netfilter support (for iptables), which increases the size of the kernel substantially, along with mdraid support, and some other capabilities most desktop users don't need. Using a custom kernel allows you to eliminate the need for an initrd, speeds up the boot process by compiling all the drivers your hardware needs directly into the kernel, and cuts down the kernel's memory footprint. On current systems with multiple gigs of ram and large CPU L2/L3 caches, admittedly, the size of the kernel isn't a big issue for most desktop and server class systems these days. It most certainly is critical for embedded applications, where processors have relatively low performance, with tiny caches, and small system memories. > 2) Security - one of these null pointer dereferences that they keep > discovering can't hurt you if it's in code that hasn't been included. This is a valid point, though others would argue the opposite, that pre compiled kernels lacking modules can't easily have the driver code updated with a security fix, without compiling a new kernel. I personally will take my chances with my precompiled kernel. > 3) Education - it's an unbeatable way to get a deeper knowledge of > your system. In the big picture, this is probably the single greatest advantage to doing one's own custom kernel. > 4) Flexibility and control Yes and no WRT flexibility. Yes because you an choose exactly what does and does not go into your kernel. No, because once it's built, if you want to add a new hardware device later, you might have to build a new kernel. With the modular prebuilt kernels, you can plug in just about anything and it'll likely be recognized. Then again, there's nothing keeping one from building his/her own kernel and including drivers in anticipation of future needs. The downside to this is kernel bloat for hardware you're not using "right now". I obviously agree that you have more control doing your own kernel. > Note that I'm not expert, and these are just my opinions, and may even > be factually incorrect. >From one non-expert to another, I agree with most of what you state. I've been running only custom kernels for 5+ years now (servers only) with great success and satisfaction. -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Celejar on 21 Dec 2009 22:20 On Mon, 21 Dec 2009 20:50:15 -0600 Stan Hoeppner <stan(a)hardwarefreak.com> wrote: > Celejar put forth on 12/21/2009 8:22 PM: > > > 1) Faster booting, since irrelevant drivers aren't loaded and won't > > spend time probing. > > Correct. And not just drivers. Prebuilt kernels usually include netfilter > support (for iptables), which increases the size of the kernel substantially, > along with mdraid support, and some other capabilities most desktop users don't > need. Using a custom kernel allows you to eliminate the need for an initrd, I run desktops / laptops, and I always build netfilter - I run shorewall on all my boxes. > speeds up the boot process by compiling all the drivers your hardware needs > directly into the kernel, and cuts down the kernel's memory footprint. On 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? > current systems with multiple gigs of ram and large CPU L2/L3 caches, > admittedly, the size of the kernel isn't a big issue for most desktop and server > class systems these days. It most certainly is critical for embedded > applications, where processors have relatively low performance, with tiny > caches, and small system memories. > > > 2) Security - one of these null pointer dereferences that they keep > > discovering can't hurt you if it's in code that hasn't been included. > > This is a valid point, though others would argue the opposite, that pre compiled > kernels lacking modules can't easily have the driver code updated with a > security fix, without compiling a new kernel. I personally will take my chances > with my precompiled kernel. 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.] ... > > 4) Flexibility and control > > Yes and no WRT flexibility. Yes because you an choose exactly what does and > does not go into your kernel. No, because once it's built, if you want to add a > new hardware device later, you might have to build a new kernel. With the > modular prebuilt kernels, you can plug in just about anything and it'll likely > be recognized. Then again, there's nothing keeping one from building his/her > own kernel and including drivers in anticipation of future needs. The downside > to this is kernel bloat for hardware you're not using "right now". I obviously > agree that you have more control doing your own kernel. 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 :/ 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 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stan Hoeppner on 22 Dec 2009 00:10 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 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Paul Cartwright on 22 Dec 2009 05:40
On Mon December 21 2009, Celejar wrote: > 2) Â From the appropriate directory, run make menuconfig (or xconfig or > whatever you prefer) and configure appropriately I think I have done this before, I think I tried it for a 64bit kernel, for my Duo-Core processor, but it didn't turn out well. Seems to me the "configure' part takes 2 days, or way too many options. I seem to remember it asked whether i wanted support for every known piece of hardware out there, and I don't know when to say Y or N.. -- Paul Cartwright Registered Linux user # 367800 Registered Ubuntu User #12459 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org |