debian @ 1und1 L64
Posted: 2005-12-29 17:46
Resources for System-Administrators
https://www.rootforum.org/forum/
Code: Select all
debootstrap --arch amd64 sarge /mnt/ http://amd64.debian.net/debian-amd64/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 directoryCode: 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 scriptsJein, 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.nimer wrote: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?
nimer wrote:Wie kann man rausfinden ob das rescue System 64 oder 32 Bit hat?
Code: Select all
uname -mIch 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:microhome wrote:Hallöle,
Hab ich vergessen irgendwas zu /etc/modules hinzuzufügen? Der 1und1 Support meint die Platten laufen über das Modul sata_sis?!?!
Rene
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:[..]
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
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?apt-get install kernel-image-2.6.8-11-amd64-k8
Inmicrohome wrote:Hallo Jürgen,
reicht es nicht wenn ich einfach "sata_sis" in /etc/modules eintrage?
Code: Select all
/etc/modulesCode: 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 92. initrd erstelltrescue:/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
3. /etc/lilo.conf angepasst und lilo ausgeführtrescue:/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
Dabei bekomme ich, wie immer, folgenden Fehler: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
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?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
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?microhome wrote: 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?
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..."
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
Warum kompilierst Du ACPI, APM und APIC in den Kernel, wenn Du sie eh deaktivierst?juergen wrote:Code: Select all
acpi=off apm=off noapic
Ich hab den Kernel nicht selbst kompiliert. Ansonsten: berechtigte Frage :-DJoe User wrote:Warum kompilierst Du ACPI, APM und APIC in den Kernel, wenn Du sie eh deaktivierst?juergen wrote:Code: Select all
acpi=off apm=off noapic
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.microhome wrote: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!
Hi Jurgen, mal na kurze Frage: Warum erst ab .14er? Das Modul ist ja schon in älteren Kernel Distributionen vorhanden, zumindest bei Debian.juergen wrote:
Du musst einen Kernel oder eine initiale Ramdisk mit dem Treiber installieren. Auf jeden Fall einen kernel >= 2.6.14 verwenden.
Viel Erfolg.
Wegen der übrigen Hardware, die erst mit dieser Version vom Vanilla-Kernel unterstützt wird.Hotzi wrote:mal na kurze Frage: Warum erst ab .14er? Das Modul ist ja schon in älteren Kernel Distributionen vorhanden, zumindest bei Debian.
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 wrote:Ok danke, tolle "Leistung" von 1und1. Gut dass ich diesen "Schund" nicht gemietet habe.