[TAG] Debian Installation

[Kapil Hari Paranjape]

Hello,

On Sun, 01 Oct 2006, Neil Youngman wrote:
> Well I've had enough of the creeping bit rot in my Mepis installation and I 
> want to be rid of Mepis. I'm trying to go back to a plain vanilla Debian 
> installation. I've also recently upgraded my system with a SATA conroller and 
> a 200GB hard disk, onto which I tried to install Debian with the Debian 3.1 
> net installer.

You missed a golden opportunity to upgrade your Mepis without
installing again :) In principle, any of the following would
have worked:
	(a) apt with the appropriate new sources.list
	(b) (c)debootstrap.
Both of these would have been "fun" ... the
I-spent-a-week-doing-the-upgrade-but-I-learned-something
kind of fun.

> The default install hung, so I went for the "expert" install and got an 
> installation on the SATA disk. It's definitely there, I can see it, but I 
> can't boot from it. 

You need to install a 2.6 kernel. Use expert26 to boot the install
again (or use rescue26) and get it to install the 2.6 kernel image. 

> Is there a way to check what modules are built into this kernel? 

Debian "stock" kernels rarely have *any* modules built in nowadays.
All hardware support is loaded using modules that sit in the initrd.img.

> Is it best just to build my own kernel to replace the one that has been 
> installed? 

I would say "No". Given the modular nature of the current Debian
kernel package it is usually not necessary to re-build it. However, in
the interests of seeing both sides here is the list of pros and cons.

Pros:
	1. You get to make your computer do some hard work as soon
	   as it is set up.
	2. You can build in exactly the drivers you need and skip
	   all the business of auto-loading modules.
	3. Disabling module loading in the kernel (as opposed to 
	   via the proc interface) *may* be stronger security.
	4. You can work without "udev". (The new kernels in Debian
	   depend on "initramfs-tools" which in turn depends on
	   "udev").
	5. If you have *really* unusual hardware this may be necessary.

Cons:
	1. You tie your kernel down to your specific system (think
	   hardware upgrades).
	2. You might not be able to use a number of external module
	   packages like "unionfs", "squashfs", "reiserfs4",.... You
	   will have to build these for your kernel yourself.
	3. Some of the settings for kernel related packages like
	   "uswsusp", "acpid", "hibernate" assume that you have
	   certain features compiled in. You may not know in advance
	   which features you want.
	4. It kind of goes at 45 degrees to Debian philosophy.

Some explanation of (4). The angle is the metaphoric distance between
Debian and Gentoo. (Note that it is not 90 just 45 :))

In Debian you *can* re-build any package you want. You can even setup
your own "buildd" to re-build the system the way it is done for the
Debian archive packages (use the "sbuild" package). However, you don't
actually do this unless it is necessary.

The reasons are many but an important one is "community". Part of
being a community supported distribution is that you trust your
co-developers to:
	(a) have built a good package if they have affixed their
	signature to it.
	(b) have made decisions regarding that build that would be
	useful to everyone.
	(c) have given you just the right amount of configurability
	so that you can fine tune.
Having said that there are of course "edge cases" when recompiling
with alternate configurations may be necessary. The packages
"kernel-package", "module-assistant", "debnest", "pbuilder",
"sbuild" and so on are there to help you in this case.

Hope this helps,

Kapil.
--