USB disk shows up late at boot
in [Debian]
|
From: Paul Cartwright on 22 Dec 2009 05:50 On Mon December 21 2009, Celejar wrote: > > 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 :/ how do you know what to enable/disable? Do I need a full-list of all my existing hardware in front of me? how do you know what the dependencies are? -- 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
From: Chris Jackson on 22 Dec 2009 06:10 Paul Cartwright wrote: > 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.. > I think you may have done "make config" rather than "make menuconfig". Menuconfig - at least should - provide a menu-based interface you can select packages from. It can still take a while, but much faster than being asked for each one which is... somewhat unwieldy these days. Similarly, "make xconfig" provides an X-windows interface; I've never used this. One way of getting a list of modules you might need is to start with a stock kernel based on using modules, perhaps from a live CD. Start anything you want up, then do "lsmod" which will get you a list of all the modules it's loaded. Mapping between the module name and the exact option needed is not always as easy as it might be, but we'll call that "learning experience" ;) Apart from that, you have to anticipate: for example if you think you might need USB printing, but don't have one right now, perhaps include it. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Hugo Vanwoerkom on 22 Dec 2009 07:50 Andrew Reid wrote: > On Monday 21 December 2009 15:52:29 Hugo Vanwoerkom wrote: >> Hi, >> >> I have 2 internal ATA HDD's and 2 disks in external USB enclosures. >> >> When you boot (this is Sid) the 2 USB disks report their presence >> between the messages: >> >> 'Loading, please wait...' >> and >> 'Init 2.86 booting' >> in the very beginning of the boot process. >> >> Now the funny part: in my homegrown kernel both show up together. But >> with recent Debian kernel images only one shows up. I have a delay of 10 >> secs. in initramfs-tools but that makes no difference. >> >> The 2nd USB disk shows up eventually, but after 'Init 2.86 booting' when >> it is too late to be of use by fstab. >> >> This isn't the first time I've asked this, but nobody seems to have an >> answer. > > It's likely the devices aren't being recognized in the initramfs -- > possibly they require kernel modules which are not present by default. But I would think that to be the case of the custom kernel, not the Debian kernel. The small custom kernel recognizes both USB drives, the Debian kernel recognizes only one of them. > > If you know which modules drive these devices, add them by name > to /etc/initramfs-tools/modules (one module per line, I think), and > re-generate your initramfs with update-initramfs. This should allow > the udev scan in the initramfs to see the devices, and set them > up earlier. I have no idea, except to compare both initrd images. > > "Init 2.86 booting" is a very important milestone in the boot > process, it marks the transition from initramfs activity to > root file-system activity. Anything you want to do *before* that > has to be in the initramfs. > > Or, as the other responder mentioned, you can just stick with > a custom kernel. I used to do that, but I like getting security > updates. > > -- A. > -- 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 22 Dec 2009 09:20 On Mon, 21 Dec 2009 23:02:53 -0600 Stan Hoeppner <stan(a)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 -- 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 22 Dec 2009 15:30
On Tue, 22 Dec 2009 05:41:22 -0500 Paul Cartwright <ale(a)pcartwright.com> wrote: > On Mon December 21 2009, Celejar wrote: > > 1) Faster booting, since irrelevant drivers aren't loaded and won't > > spend time probing. > just faster booting, or doesn't it also run faster, since it isn't loaded with > a bunch of PORK? My understanding is that most modules, such as drivers, won't cause any ongoing performance penalty if they aren't in use. There are some kernel options that do. and they're sometimes (though not, alas, consistently, like much of the kernel documentation) noted as such in the kernel docs. > > 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. > > > not sure I understand. Are you saying if there is a reference to hardware that > doesn't exist on your platform? No. A NPD is a very serious type of coding error with potentially catastrophic security consequences: http://en.wikipedia.org/wiki/Pointer_%28computing%29#Null_pointer If the code in which the bug occurs isn't being build, though, you're quite safe ;) 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 |