debian @ 1und1 L64

[microhome]

// edit: das fertige Howto zum Thema gibts online auf


http://www.debiandox.de


Liebe Grüße
Rene

[timeless2]

da gab es doch schon Diskussionen, benutze einfach mal die Forensuche

[microhome]

Ist mir klar dass es schon ein Thema bzgl. "L64 Server" gibt. Bevor ich was poste benutze ich nämlich _immer_ die Suche. Nur schweift das Thread irgendwann vom Thema ab und dann gehts nur noch um Gentoo aber es wird nicht geklärt, wie man nun Step-by-Step Debian und RAID1 auf den *64 Kisten zum laufen kriegt!

Für weitere Hilfe wär ich dankbar,
der Rene

[microhome]

Sooo, werd das ganze jetzt mal selbst in die Hand nehmen und abschließend ein Howto für all diejenigen erstellen, die selbes vorhaben.
Da ich Debian über debootstrap installieren möchte gebe ich folgenden Befehl ein um die base-archive zu ziehen:

Code: Select all

debootstrap --arch amd64 sarge /mnt/ http://amd64.debian.net/debian-amd64/

Jedoch erhalte ich folgenden Fehler und hab absolut keinen Plan wie das passieren kann:

Code: Select all

I: Validating debootstrap.invalid_dists_sarge_Release
I: Validating debootstrap.invalid_dists_sarge_main_binary-amd64_Packages
/sbin/debootstrap: line 1: /usr/lib/debootstrap/pkgdetails: No such file or directory

Datei vorhanden?

Code: Select all

ls -al /usr/lib/debootstrap/
total 84
drwxr-xr-x   3 root root  1024 Mar  5  2005 .
drwxr-xr-x  28 root root  5120 Dec 30 14:19 ..
-rw-r--r--   1 root root     5 Feb 26  2005 arch
-rw-r--r--   1 root root 53183 Feb 26  2005 devices.tar.gz
-rw-r--r--   1 root root 16630 Feb 26  2005 functions
-rwxr-xr-x   1 root root  5072 Feb 26  2005 pkgdetails
drwxr-xr-x   2 root root  1024 Mar  5  2005 scripts

Was mache ich falsch? Die beiden Platten laufen bereits im RAID1 Betrieb.


Grüße, Rene

[nimer]

Hi,

evtl. hilft diese Anleitung:
http://www.hotzeltopf.de/anleitungen/de ... stallation

dadrin steht auch, wenn das Rescue System 32 Bit ist, kann man kein 64 Bit OS per rescue installieren! Vermute mal das ist dein Fehler oder?

Wie kann man rausfinden ob das rescue System 64 oder 32 Bit hat?

[Roger Wilco]

dadrin steht auch, wenn das Rescue System 32 Bit ist, kann man kein 64 Bit OS per rescue installieren! Vermute mal das ist dein Fehler oder?

Jein, man kann dann zumindest nicht in das System wechseln (etwa mit chroot). Es kann dich aber niemand daran hindern, die Festplatte zu partitionieren und Dateien darauf zu kopieren.

Wie kann man rausfinden ob das rescue System 64 oder 32 Bit hat?

Code: Select all

uname -m

[nimer]

ok, dafür müsste ich dann aber schon sehr genau wissen was ich tue um Debian zu installieren...

[microhome]

Hallöle,
naja ich boote ja das 64 Bit rescue System und hab dann die Anleitung von Hotzltopf entsprechend angepasst..
Wie auch immer. Ich möchte ganz einfach erstmal debian auf /dev/sda installieren, das heißt ohne Raid. Ganz schlicht nur auf /dev/sda.. nur genau das scheint schon nicht zu funktionieren.
Beim booten bekomme ich nen Kernel panic. Ich glaube ja, dass das daran liegt, dass er die Festplatte beim booten nicht findet. Habt ihr ne Idee wie ich das rausfinden kann? Hab ja über serielle Konsole sogar den LILO promt, aber das bringt mir auch nix.. egal was ich als root angebe, er findet einfach nix und bringt /dev/console not found und eben Kernel panic.
Hab ich vergessen irgendwas zu /etc/modules hinzuzufügen? Der 1und1 Support meint die Platten laufen über das Modul sata_sis?!?!

Wär echt super wenn ihr mir helfen könnten!


Grüße
Rene

[juergen]

Hallöle,
Hab ich vergessen irgendwas zu /etc/modules hinzuzufügen? Der 1und1 Support meint die Platten laufen über das Modul sata_sis?!?!
Rene

Ich habe auf einem L64 ArchLinux mit Software Raid am laufen. sata_sis ist korrekt. Das Modul muss im Kernel oder der initialen Ramdisk sein. Allerdings läuft mein System nur mit dem Kernelparameter "noapic" stabil. Sonst:

Jan 1 22:45:38 p15200770 ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Jan 1 22:45:38 p15200770 ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Jan 1 22:45:38 p15200770 ata1: command 0x25 timeout, stat 0x50 host_stat 0x24
Jan 1 22:45:38 p15200770 ata2: command 0x25 timeout, stat 0x50 host_stat 0x24
Jan 1 22:45:38 p15200770 ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Jan 1 22:45:38 p15200770 ata2: command 0x25 timeout, stat 0x50 host_stat 0x24


Grüße Jürgen

[microhome]

Hallo Jürgen,
reicht es nicht wenn ich einfach "sata_sis" in /etc/modules eintrage?
Ich bekomme bei der seriellen Konsole folgendes angezeigt, wenn ich booten möchte:

[..]
fb0: VESA VGA frame buffer device
Console: switching to colour frame buffer device 128x48
NET: Registered protocol family 1
SCSI subsystem initialized
NTFS driver 2.1.15 [Flags: R/O MODULE].
udf: registering filesystem
SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
pivot_root: No sKernel panic: Attempted to kill init!
uch file or dire ctory
/sbin/ini<0>Rebooting in 5 seconds..t: 432: cannot open dev/console: No such file

Was ist da los? Kann doch nur sein, dass er die Festplatte sda nicht findet, oder? Und das muss am Treiber liegen?! Hab den Kernel per apt-get installiert:

apt-get install kernel-image-2.6.8-11-amd64-k8

Habt ihr noch ne Idee? Hab append="noapic" hinzugefügt, aber das bringt auch nix, selber Fehler. Also ich weiß nicht wie, aber wie gesagt, irgendwie muss ich da was mit den Treibern vergessen haben. Kann man das irgendwie über den LILO Prompt am Anfang prüfen, welche Platten er findet?


Gute Nacht jetzt erstmal
Rene

[juergen]

Hallo Jürgen,
reicht es nicht wenn ich einfach "sata_sis" in /etc/modules eintrage?

In

Code: Select all

/etc/modules

ist es zu spät. Der sata_sys muss spätestens in der initialen Ramdisk geladen werden, bevor die Root-Partition gemounted wird. Bei dir ist offensichtlich der Treiber weder im Kernel vorhanden, noch wird er von der initialen Ramdisk geladen. Ansonsten hättest du folgende Ausgabe auf deiner Konsole:

Code: Select all

myhost sata_sis: Detected SiS 182 chipset
Jan  1 22:35:30 myhost ata1: SATA max UDMA/133 cmd 0x1CB0 ctl 0x1CA6 bmdma 0x1C90 irq 9
Jan  1 22:35:30 myhost ata2: SATA max UDMA/133 cmd 0x1CA8 ctl 0x1CA2 bmdma 0x1C98 irq 9

Du musst einen Kernel oder eine initiale Ramdisk mit dem Treiber installieren. Auf jeden Fall einen kernel >= 2.6.14 verwenden.

Viel Erfolg.

[ren]

Hallo,

ich habe selbes Problem, Debian ist installiert per debootstrap und im chroot läuft auch alles, aber die Kiste bootet nicht:
http://zyx.pastebin.com/465590 (Kernel Panic weil er mit dem RAID auf dem die /boot liegt nicht klarkommt)

Ich hab einen fertigen kernel installiert, aber schnell gesehen dass es wohl besser ist einen von Hand zu bauen mit den richtigen Treibern gleich drin (Module sind nicht so mein Fall)

Falls jemand einen aktuellen Kernel gebaut hat der für einen 1und1 XL64 die richtigen Optionen hat, wäre es möglich mal das Kernel Config file z.b. bei pastebin.com abzulegen? Das wär sicher für viele sehr hilfreich!


Gruss,
Eike

[microhome]

Siehste, genau das Problem hatte ich auch mit RAID. Darum teste ich das erstmal nur normal auf /dev/sda..
Nagut, werd das jetzt mal machen wie juergen sagte. Den Kernel komplett selbst kompilieren aber eben mit sata_sis, ne?
Ich werd den dann auch uploaden, wenn es funktioniert, damit ihr euch den ziehen könnt.


Grüße
Rene

[microhome]

Selber Fehler, nachdem ich folgendes gemacht hab:

1. Module in /etc/mkinitrd/modules geschrieben

rescue:/etc/mkinitrd# cat modules
# /etc/modules: kernel modules to load at boot time.
#
# This file should contain the names of kernel modules that are
# to be loaded at boot time, one per line. Comments begin with
# a "#", and everything on the line after them are ignored.
sata_sis
ext3
scsi_mod
sg
sd_mod

2. initrd erstellt

rescue:/etc/mkinitrd# mkinitrd -o /boot/initrd.img-2.6.8-11-amd64-k8 2.6.8-11-amd64-k8
dpkg: warning, architecture `amd64' not in remapping table
cat: /proc/modules: No such file or directory
dpkg: warning, architecture `amd64' not in remapping table
cat: /proc/modules: No such file or directory
dpkg: warning, architecture `amd64' not in remapping table
dpkg: warning, architecture `amd64' not in remapping table

3. /etc/lilo.conf angepasst und lilo ausgeführt

rescue:/etc/mkinitrd# cat /etc/lilo.conf
boot=/dev/sda
root=/dev/sda1
vga=791
timeout=50
prompt
compact
install=/boot/boot.b
map=/boot/map
serial=0,57600n8
append="console=ttyS0,57600 console=tty0 panic=5"
image=/vmlinuz
label = debian
append="console=tty0 console=ttyS0,57600 panic=5"
initrd=/boot/initrd.img-2.6.8-11-amd64-k8

Dabei bekomme ich, wie immer, folgenden Fehler:

VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 124k freed
initrd-tools: 0.1.81.1
SCSI subsystem initialized
vesafb: framebuffer at 0xf0000000, mapped to 0xffffff0010017000, size 3072k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Console: switching to colour frame buffer device 128x48
NET: Registered protocol family 1
NTFS driver 2.1.15 [Flags: R/O MODULE].
udf: registering filesystem
SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
pivot_root: No sKernel panic: Attempted to kill init!
uch file or dire ctory
/sbin/ini<0>Rebooting in 5 seconds..t: 432: cannot open dev/console: No such file

Ich meine irgendwie ist das doch auch logisch, oder? Der möchte beim Boot den initrd.img von der Platte laden - tja nur wie, wenn er die Platte gar nicht initialisiert?

Was mache / denke ich falsch?

[juergen]

Ich meine irgendwie ist das doch auch logisch, oder? Der möchte beim Boot den initrd.img von der Platte laden - tja nur wie, wenn er die Platte gar nicht initialisiert?
Was mache / denke ich falsch?

Für das Laden der initrd ist der bootloader (grub) verantwortlich, nicht der Kernel. Offentsichtlich wird die initrd ausgeführt. Nur läuft etwas beim mounten der root-Partition schief. Jetzt stellt sich die Frage warum du überhaupt eine initrd verwendest, wenn du den sata Teiber im Kernel hast und die root-Partition somit direkt mounten kannst?

Ich verwende die initrd um den sata/md Treiber zu laden und das Software-Raid zu aktivierten. Der relevante Abschnitt in meiner initrd sieht so aus (ArchLinux):

Code: Select all

/bin/mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2
ROOT_DEV=/dev/root
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
mount -t `/bin/fsck -NT $ROOT_DEV | awk -Ffsck. '{print $2}' | awk '{print $1}'` -n -o ro $ROOT_DEV /new_root
pivot_root /new_root /new_root/initrd
umount /initrd/sys
umount /initrd/proc
echo "Initial RAMDISK Loading Completed..."

Meine grub-konfiguration:

Code: Select all

title  Arch Linux  [/boot/vmlinuz]
root   (hd0,0)
kernel /vmlinuz26 root=/dev/md0 ro devfs=nomount acpi=off apm=off noapic
initrd /initrd26.img

Aber (wie gesagt) ,wenn du deine Root-Partition nicht auf einem Software-Raid hast, brauchst du keine initrd.

Grüße Jürgen

[Joe User]

Code: Select all

acpi=off apm=off noapic

Warum kompilierst Du ACPI, APM und APIC in den Kernel, wenn Du sie eh deaktivierst?

[juergen]

Code: Select all

acpi=off apm=off noapic

Warum kompilierst Du ACPI, APM und APIC in den Kernel, wenn Du sie eh deaktivierst?

Ich hab den Kernel nicht selbst kompiliert. Ansonsten: berechtigte Frage :-D

[microhome]

Hi Juergen,
naja in der kernelconfig stehen die treiber als module, also auf "m".
Wenn ich nun aber sata_sis in /etc/modules hinzufüge ändert das nichts. Hab auch ne initrd gebaut, um das SCSI Device zu initialisieren aber das bringt auch nix.. Ich weiß bald echt nicht mehr weiter!

[juergen]

Hi Juergen,
naja in der kernelconfig stehen die treiber als module, also auf "m".
Wenn ich nun aber sata_sis in /etc/modules hinzufüge ändert das nichts. Hab auch ne initrd gebaut, um das SCSI Device zu initialisieren aber das bringt auch nix.. Ich weiß bald echt nicht mehr weiter!

Warum kompilierst du die benötigten treiber nicht fest in den Kernel, dann brauchst du die initrd nicht und ersparst dir diese zusätzliche Fehlerquelle. Wie gesagt, die Treiber müssen vor dem Mounten der Root-Partition initialisiert werden. sata_sis in /etc/modules bringt dir also nichts.

Grüße Jürgen

[microhome]

Okay alles klar, dann versuch ich das nochmal.
Wenns dann irgendwann klappt gibts auch nen ausführliches Howto zu diesem Thema!

Danke euch erstmal, ich melde mich (sicher) :-D

[hotzi]

Du musst einen Kernel oder eine initiale Ramdisk mit dem Treiber installieren. Auf jeden Fall einen kernel >= 2.6.14 verwenden.

Viel Erfolg.

Hi Jurgen, mal na kurze Frage: Warum erst ab .14er? Das Modul ist ja schon in älteren Kernel Distributionen vorhanden, zumindest bei Debian.

Gruß

Hotzi

[Roger Wilco]

mal na kurze Frage: Warum erst ab .14er? Das Modul ist ja schon in älteren Kernel Distributionen vorhanden, zumindest bei Debian.

Wegen der übrigen Hardware, die erst mit dieser Version vom Vanilla-Kernel unterstützt wird.

[hotzi]

Ok danke, tolle "Leistung" von 1und1. Gut dass ich diesen "Schund" nicht gemietet habe.

[Roger Wilco]

Ok danke, tolle "Leistung" von 1und1. Gut dass ich diesen "Schund" nicht gemietet habe.

Ich verstehe deine Reaktion ehrlich gesagt nicht so ganz. Die Hardware wird unterstützt und aufgrund eines Bugs in älteren Versionen sollte der paranoide Admin eh keinen Kernel <2.6.15 (oder entsprechend gepatched) verwenden.

[hotzi]

Ist doch klar, so ein "Mist" wie SIS Chips würde ich persönlich nirgends einsetzen. Dass ich nen superneuen Kernel, keinen Debian Stable, benutuen soll, ist das Allerletzte. Für Sicherheitsthemen gibts Backports.

Wer weiss, vielleicht findet sich ja eine andere Lösung.