Hmm, die methode zou ik toch niet aanraden om Debian te installeren. Zeker in het geval van Ubuntu 7.10 -> Debian 4.0 bevat Ubuntu voor de meeste packages nieuwere versies, dus van de Ubuntu naar de Debian versie van een package is dan een downgrade, en dat doet apt-get
upgrade niet
Als je Debian wil installeren vanuit Ubuntu, dan zou ik dat doen met debootstrap (zoals benoni al voorstelde) of met een virtualisator/emulator (zoals qemu). Je kunt dan Ubuntu installeren op een kleine partitie (een paar gig) en vanuit die install de rest van de harddisk onder handen nemen met debootstrap/qemu. Het is ook mogelijk dit alles vanuit de Ubuntu livecd te doen, alleen als Debian dan alsnog niet boot dan moet je weer Ubuntu booten en opnieuw qemu installeren, etc.
Als je op deze manier Debian installeert, dan heb je waarschijnlijk trouwens snoeihard hetzelfde probleem, aangezien de geinstalleerde Etch dan nog steeds je ICH9 niet snapt

Wel is het via deze route natuurlijk mogelijk om vanuit Ubuntu je Debian install te runnen en aan te passen.
Zie ook
dit topic voor een vergelijkbaar verhaal.
Hoezo is debootstrap niet uitgekristalliseerd?
Waarschijnlijk niet. Die drivers zijn vrij gevoelig voor welke kernelversie er precies gebruikt wordt, en die verschilt waarschijnlijk teveel tussen Ubuntu en Debian.
benoni schreef op woensdag 24 oktober 2007 @ 20:53:
Umh... alles kan, maar zoiets zit er niet klik-en-klaar in. Je kunt de drivers erbij zetten op de CD of zo... en/of tijdens het installatieproces een terminal openen en daarmee proberen wat te modprobe'n en zo... maar ik weet uit mijn hoofd niet of dat dit commando beschikbaar is in de beperkte omgeving die de installer biedt.
De Debian installer heeft modprobe, dus dat is het probleem niet (maar: zie boven).
Ik raad af het in een productie-omgeving te gebruiken. Testing heeft een veel minder rigoreuze testprocedure doorlopen dan stable, en security updates voor testing hebben bij mijn weten ook een lagere prioriteit.
Wat in de praktijk ook een probleem is van testing: er zijn continue updates van zo'n beetje alles, dus er kunnen daardoor dingen veranderen (dat merk je vooral op desktops soms erg goed).
In mijn ervaring komt er bij een machine die "gewoon werkt" de slof in het doen van die updates, waardoor je op een gegeven moment een snapshot draait van hoe testing op dat moment was. Als je dan later wel weer eens update (en dat kan nodig zijn als je dan een bepaald package wil installeren), dan is er ineens heel veel te updaten, met alle bijkomende problemen van dien.
"Voor de pruts" is testing prima, voor productie (als je wil dat het werkt zonder teveel omkijken) niet
Wat trouwens ook nog een optie is: in je sources.list aangeven dat je niet
testing wil gebruiken, maar
lenny. Dat is op dit moment hetzelfde, maar als Lenny stable wordt, dan blijf je bij Lenny (die dan stable is) in plaats van dat je testing blijft volgen.
Ik wil het OS straks in Raid 1 gaan draaien op 2x 500GB, en hier een Highpoint Rocketraid 16ch SATA controller aanhangen.
Het
lijkt erop dat dat fakeraid controllers zijn, dus het is de vraag of je die wil. (
hier een topic met meer discussie daarover. Daar staat trouwens ook de reden dat ik dacht dat Etch ICH9 ondersteunde

)
(heb ik het goed als Lenny de opvolger van Etch word?)
Jep, dat klopt.