squeeze update

[guennid]

Ich habe von lenny auf squeeze upgedatet. Der Kern ist ein vanilla-Eigenbaukern 2.6.36.2 ohne initrd, der schon unter lenny verwendet wurde. bootloader ist lilo und udev wird benutzt.

Damit bootet das System durch, ohne dass ich Fehler bemerkte.

In /etc/fstab und in lilo.conf stehen für die IDE-Platte nach wie hd*-Angaben (hda und /=hda1). Diese finden sich auch in /dev wieder.

Ist das in Ordnung so? Irgendwo habe ich aufgeschnappt, udev organisiere jetzt alles über sd*

Stutzig macht mich auch, dass unter /dev/disk nur by-id existiert und darin nur einer dieser udev-spezifischen links, und zwar für's CD-Laufwerk (ata-CD-224E --> /dev/hdc) auftaucht, nicht jedoch einer für die Systempartition /dev/hda1, wie das bei meinen lenny-Systemen bei IDE-Platten der Fall ist.

Ist das ebenfalls so in Ordnung?

Der Standard-Kern 2.6.32-5-486 bootet nicht fertig. (Ist der [wegen der initrd] zu groß für lilo? In der kryptischen englischsprachigen Info unter /usr/share/doc/lilo, datiert auf anno tobak, steht was, das ich mir so zu interpretieren vorstellen könnte) Dieses Problem möchte ich aber erst später angehen.

Grüße Günther

[towo]

Ob /dev/hdX oder /dev/sdX verwendet wird, hängt einzig von der Kernel-Konfiguration ab, udev hat damit absolut nix zu tun.

[guennid]

Meine Hauptfrage ist: Ist das so in Ordnung?

Weiterhin wage ich zu fragen, wie hängt das von der Kernel-Konfiguration ab?

Grüße, Günther

[cosmac]

udev hat insofern etwas damit zu tun, als es normalerweise die Gerätedateien in /dev passend erstellen muss. udev hat nichts mit der Wahl zwischen hdx und sdx zu tun, die trifft man in der Kernel-Config unter "Device Drivers":

hdx: [_] ATA/ATAPI/MFM/RLL support (DEPRECATED)
sdx: [_] Serial ATA and Parallel ATA drivers

Im entsprechenden Untermenü müssen die Treiber passend zum Chipsatz gewählt werden, das Prinzip ist bei beiden gleich. Wie man am DEPRECATED sieht, meinen die Kernel-Entwickler, dass man schön langsam auf sdx umstellen sollte. Deswegen könnte ich mir vorstellen, dass udev hdx nicht mehr vollständig unterstützt.

Bei mir gibt's nicht einmal das Verzeichnis /dev/disk, geschweige denn irgendwas unten drunter, und ich hab's noch nie vermisst. Das heißt natürlich nicht, dass das in Ordnung ist -- kommt ja immer drauf an, wer die Regeln für die Ordnung macht

Ungereimtheiten unter /dev kann man komplett vermeiden, wenn der Kernel die Gerätedateien selbst erstellt und bei Bedarf wieder löscht. Mit CONFIG_DEVTMPFS=y und CONFIG_DEVTMPFS_MOUNT=y gehört /dev vom Start weg dem Kernel und udev passt nur noch die Rechte an. Mein Debian-Kernel 2.6.32-5-686 hat nur CONFIG_DEVTMPFS=y, das dürfte nur mit initrd funktionieren.

[tarrasch]

"-- kommt ja immer drauf an, wer die Regeln für die Ordnung macht"

Das ist wirklich gut und hat mich sehr zum nachdenken gebracht.

MFG
tarrasch

[guennid]

@cosmac
Danke für deine hilfreichen Hinweise!

Wie man am DEPRECATED sieht, meinen die Kernel-Entwickler, dass man schön langsam auf sdx umstellen sollte

Verstehe ich das so richtig, dass ich den Kern neu bauen und ATA/ATAPI/MFM/RLL support (DEPRECATED) einfach durch Serial ATA and Parallel ATA drivers ersetzen könnte (unter Beachtung weiterer Änderungen in den genannten Untermenüs, versteht sich), ohne die IDE-Platte auszutauschen?

Bei mir gibt's nicht einmal das Verzeichnis /dev/disk

Das wundert mich nun allerdings sehr. Das habe ich auf allen Systemen mit udev. (Aber deren Regeln habe ich ja auch in Folge mangelnder Kompetenzen nicht gemacht ).

CONFIG_DEVTMPFS=y und CONFIG_DEVTMPFS_MOUNT=y

Das hast du ja schon öfter angesprochen und ich bin noch nie darauf eingegangen, wie ich zu meiner Schande gestehen muss.
Aber ein wenig nachgegangen bin ich dem schon. Auf meinem meistbenutzten Schleppi sind diese Module einkompiliert (ob ich's selbst gemacht habe, oder ob's irgendwann beim kernel-updaten via oldconfig defaultmäßig gesetzt wurde, weiß ich nicht mehr). Beim hier angesprochenen Druckserver sollte zumindest CONFIG_DEVTMPFS=y gesetzt sein. Ich denke, das habe ich geprüft. Kann ich leider erst heute nachmittag nach der Arbeit verifizieren.

Grüße, Günther

PS:
Es tut manchmal richtig gut, die Erfahrung zu machen, dass sich jemand auf die eigenen dummen Fragen so richtig einlässt. Insofern ist dem hier nichts mehr hinzuzufügen:

Das ist wirklich gut

[cosmac]

Verstehe ich das so richtig, dass ich den Kern neu bauen und ATA/ATAPI/MFM/RLL support (DEPRECATED) einfach durch Serial ATA and Parallel ATA drivers ersetzen könnte (unter Beachtung weiterer Änderungen in den genannten Untermenüs, versteht sich), ohne die IDE-Platte auszutauschen?

ja, so einfach ist der Plan, jedenfalls für IDE-Platten. Für richtig alte Platten (die noch keinen 40-poligen Stecker haben) sind die alten hdx-Treiber wahrscheinlich die bessere Wahl. Aber ich schätze mal, so alte laufen nicht einmal bei dir

Bei mir gibt's nicht einmal das Verzeichnis /dev/disk

Das wundert mich nun allerdings sehr. Das habe ich auf allen Systemen mit udev.

naja, nur weil udev jetzt unbedingt installiert sein will, muss ich ihn ja nicht starten. Ohne initrd läuft er ja erstmal nicht, und ein Script in /etc/init.d ist gleich deaktiviert.

CONFIG_DEVTMPFS=y und CONFIG_DEVTMPFS_MOUNT=y

Das hast du ja schon öfter angesprochen und ich bin noch nie darauf eingegangen, wie ich zu meiner Schande gestehen muss.

Schande? Doch nicht deine, wenn ich immer wieder den selben Schmarrn erzähle. Aber ich finde diese Technik so ultimativ oberaffengeil, dass das einfach raus muss. Die Frage ist nur, liest man so wenig darüber, weil es keiner haben will oder weil es perfekt funktioniert? Wir haben eigentlich schon lange keine Umfrage mehr gehabt

[guennid]

Tja, ganz so einfach wird's dann wohl doch nicht werden.
lspci -nn sagt:

Code: Alles auswählen

00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) [8086:7192] (rev 03)
00:04.0 VGA compatible controller [0300]: Neomagic Corporation NM2200 [MagicGraph 256AV] [10c8:0005] (rev 12)
00:05.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02)
00:05.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01)
00:05.2 USB Controller [0c03]: Intel Corporation 82371AB/EB/MB PIIX4 USB [8086:7112] (rev 01)
00:05.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 02)
00:06.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 05)
00:07.0 Communication controller [0780]: Agere Systems 56k WinModem [11c1:0440] (rev 01)
00:09.0 Communication controller [0780]: Toshiba America Info Systems FIR Port Type-O [1179:0701] (rev 23)
00:0b.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 05)
00:0b.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 05)
00:0c.0 Multimedia audio controller [0401]: ESS Technology ES1978 Maestro 2E [125d:1978] (rev 10)
00:0d.0 Multimedia controller [0480]: C-Cube Microsystems Cinemaster C 3.0 DVD Decoder [123f:8888] (rev 02)

ATA/ATAPI/MFM/RLL support (DEPRECATED) habe ich jetzt ersetzt durch
Serial ATA and Parallel ATA drivers
Im Untermenü habe ich ausgewählt:

Code: Alles auswählen

<*>       Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support

Ich konnte den Kern in /etc/lilo.conf eintragen und auch lilo ausführen, aber beim Boot-Versuch wurde dann prompt sda, sda1 angemeckert, und der Versuch, lilo.conf entsprechend zu korrigieren, also auch hda und hda1 zu ersetzen, wurde dann beim Ausführen von lilo nicht akzeptiert (der laufende Kern ist natürlich mit hda/hda1 konfiguriert).

Henne/Ei-Problem?

Hätte es geholfen, auch die fstab zu korrigieren? Da habe ich auch noch hda drinstehen.
Grüße, Günther

[cosmac]

Tja, ganz so einfach wird's dann wohl doch nicht werden.

das war ja klar

beim Boot-Versuch wurde dann prompt sda, sda1 angemeckert

wann genau? Von lilo, vom Kernel (findet kein root device) oder von einem init-Script?

der Versuch, lilo.conf entsprechend zu korrigieren, also auch hda und hda1 zu ersetzen, wurde dann beim Ausführen von lilo nicht akzeptiert (der laufende Kern ist natürlich mit hda/hda1 konfiguriert).

gilt "hda" evt. für den "lilo"-Befehl und "hda1" für den Kernel? Dann sollte "hda/sda1" doch eigentlich passen?

Hätte es geholfen, auch die fstab zu korrigieren? Da habe ich auch noch hda drinstehen.

das würde ich erstmal nicht machen, mit hda läuft wenigstens mit dem alte Kernel alles. Wenn der neue erstmal so weit kommt, landest du wahrscheinlich in einer busybox und kannst den Rest manuell mounten.

[guennid]

Also, was genau er beim Booten gemeldet, kann ich nicht sagen, ich habe in den logs (syslog und kern.log) nichts gefunden. Sinngemäß ging's so: Ich habe lilo gestartet, dann hat er losgerödelt, und nach einer Weile gemeint, ich solle gefällgigst ein passendes root device anhängen ("append") und ich hätte sda und sda1 dafür zur Auswahl. Dann hat er sich aufgehängt.

Aber ------------------------------

HEUREKA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ich hab' ihn ausgetrickst

Ich habe mich über eine live-CD per chroot ins System gemogelt, lilo.conf geändert, lilo ausgeführt und neu gestartet. Und was soll ich sagen: Ich bin drihin!

(mit 2.6.36.2, Eigenbau, ohne initrd)

Krieg ich auch einen 2.6.26 er auf sda umgestellt, denn den brauch ich noch dringend, weil ich mit dem Netzwerkmodul e100 bisher auf der Kiste kein wakeonlan realisieren konnte? Das funktioniert hier nur mit dem alten eepro100 und der ist beim 2.6.29er rausgeflogen.

Hier mal der relevante Auszug aus der lilo.conf, kennt ja heutzutage niemand mehr.

Code: Alles auswählen

boot=/dev/sda

# Specifies the device that should be mounted as root. (`/')
#
root=/dev/sda1

# Specifies the location of the map file
#
map=/boot/map

# Boot up Linux by default.
#
default=6263

image=/boot/vmlinuz26263drk.5
	label=6263
	read-only

image=/boot/vmlinuz-2.6.36.2
	label=636
	read-only

Grüße, Günther

[guennid]

Merkwürden, Merkwürden????

Krieg ich auch einen 2.6.26 er auf sda umgestellt

Ich habe analog zum letztgenannten Kern einen 26er mit eepro100 gebaut, er bootet durch, wol funktioniert. Nur - was bootet der denn jetzt eigentlich???

In der messages finde ich das hier:

Code: Alles auswählen

Feb  5 09:38:31 drucker kernel: brd: module loaded
Feb  5 09:38:31 drucker kernel: loop: module loaded
Feb  5 09:38:31 drucker kernel: Driver 'sd' needs updating - please use bus_type methods
Feb  5 09:38:31 drucker kernel: scsi0 : ata_piix
Feb  5 09:38:31 drucker kernel: scsi1 : ata_piix
Feb  5 09:38:31 drucker kernel: ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xfe60 irq 14
Feb  5 09:38:31 drucker kernel: ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xfe68 irq 15
Feb  5 09:38:31 drucker kernel: Marking TSC unstable due to: possible TSC halt in C2.
Feb  5 09:38:31 drucker kernel: ata1.00: ATA-4: TOSHIBA MK6411MAT, J0.07 H, max UDMA/33
Feb  5 09:38:31 drucker kernel: ata1.00: 12685680 sectors, multi 16: LBA 
Feb  5 09:38:31 drucker kernel: ata1.00: configured for UDMA/33
Feb  5 09:38:31 drucker kernel: ata2.00: ATAPI: CD-224E, 7.5B, max MWDMA2
Feb  5 09:38:31 drucker kernel: ata2.00: configured for MWDMA2
Feb  5 09:38:31 drucker kernel: scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA MK6411MA J0.0 PQ: 0 ANSI: 5
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] 12685680 512-byte hardware sectors (6495 MB)
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] 12685680 512-byte hardware sectors (6495 MB)
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb  5 09:38:31 drucker kernel: sda: sda1 sda2
Feb  5 09:38:31 drucker kernel: sd 0:0:0:0: [sda] Attached SCSI disk

aber unter /dev gibt es weder hda, noch sda. (devtmpfs ist einkompiliert)

Grüße, Günther

[cosmac]

Mit CONFIG_DEVTMPFS=y und CONFIG_DEVTMPFS_MOUNT=y?

Was sagt denn "mount" dazu? Hier schaut es so aus:

Code: Alles auswählen

devtmpfs on /dev type devtmpfs (rw,relatime,size=252120k,nr_inodes=63030,mode=755)

[guennid]

mount sagt dazu:

Code: Alles auswählen

/dev/hda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

mount holt sich seine Angaben, zumindest das Wurzelsystem betreffend, wohl aus der fstab. Nachdem ich die jetzt auf sda umgestellt habe, liefert auch mount sda1 für's Wurzelsystem.

Was devtmpfs angeht, hab ich Müll erzählt: Ist beim 26er nicht einkompiliert. Die Option habe ich da gar nicht in der config. Beim 36er sind aber CONFIG_DEVTMPFS=y und CONFIG_DEVTMPFS_MOUNT=y gesetzt

/dev/devtmpfs gibt's hier nicht. , auch nicht beim 36er

Grüße, Günther

[cosmac]

Der 2.6.26er ist wohl doch schon ziemlich alt, aber dafür hat er ja andere Qualitäten, also was soll's.

mount holt sich seine Angaben, zumindest das Wurzelsystem betreffend, wohl aus der fstab.

das will ich nicht hoffen, ich find's schon schlimm genug, dass mount /etc/mtab benutzt. Im Zweifelsfall ist die mtab veraltet und es gilt die "amtliche" Info direkt vom Kernel:

Code: Alles auswählen

cat /proc/mounts

devtmpfs braucht noch CONFIG_HOTPLUG=y und funktioniert nicht in einer initrd, aber keine Ahnung, wovon genau das abhängt. Sicherheitshalber würde ich alles, was nach initrd/initramfs aussieht, abschalten. CONFIG_TMPFS=y kann auch nicht schaden.

[guennid]

Vergessen wir einstweilen mal den 26er. An dem hängt mein Herz nicht. Und wol ist nicht unbedingt nötig.

Ich will's jetzt wissen: Wie krieg ich dieses devtmpfs? Alle von dir genannten Module sind in dem 36er Kern fest einkompiliert.

Was initrd betrifft: CONFIG_BLK_DEV_INITRD=Y ist gesetzt. Und wenn ich aus woody-Zeiten recht erinnere, hieß es damals, das sei zur Umgehung der initrd erforderlich. Gilt das nicht mehr? Habe ich schon damals was falsch verstanden? Immerhin fahre ich seitdem meistens ohne initrd.img

Grüße, Günther

[cosmac]

CONFIG_BLK_DEV_INITRD=Y ist gesetzt. Und wenn ich aus woody-Zeiten recht erinnere, hieß es damals, das sei zur Umgehung der initrd erforderlich. Gilt das nicht mehr? Habe ich schon damals was falsch verstanden?

naja, ich verstehe es genau umgekehrt: "=Y" wie: "ja, ich will eine initrd". Also ist es bei mir nicht =Y.

Auch wenn der Kernel das devtmpfs schon gemountet hat, könnte evt. ein Init-Script nachträglich ein neues /dev "drüber" mounten. Das würde dann von udev verwaltet; so sah jedenfalls deine Ausgabe von "mount" aus. Aber, wie gesagt, ich habe es schon erlebt, dass mount nicht den aktuellen Stand angezeigt hat, deshalb bevorzuge ich "cat /proc/mounts".

[guennid]

Naja, dann will ich mal einen mit CONFIG_BLK_DEV_INITRD IS NOT SET bauen. Das verspricht lustig zu werden. Unter dem 26er kann ich sqeeze-lilo nicht ausführen, also müsste ich den 36er im laufenden Betrieb löschen. Was aber, wenn wir dann daneben liegen, sprich, der neue 36er nicht funktioniert? Muss mir wohl noch andere sourcen downloaden. 36 is' ja eh vieeel zu alt!

Grüße, Günther

[cosmac]

warum willst du den funktionieren 36er löschen? Du kannst doch mehrere 36er gleichzeitig haben, wozu gibt es CONFIG_LOCALVERSION (gleich am Anfang vom General Setup)?

[guennid]

CONFIG_LOCALVERSION (gleich am Anfang vom General Setup)?

Das ist dann wahrscheinlich das, womit ich diesen Krampf hier umgehen könnte. Habe ich aber noch nie gemacht.

Grüße, Günther

[cosmac]

zumindest müsstest du vmlinuz nicht mehr umbenennen. Das /lib/modules-Verzeichnis hat ja auch die Versionsnummer im Namen, also verlässt sich apt wohl auch darauf. Den Zusammenhang mit hplip sehe ich aber überhaupt nicht.

[guennid]

Den Zusammenhang mit hplip sehe ich aber überhaupt nicht.

Da geht's dir wie mir.

Das sind zwei völlig verschiedene Paar Schuh, die apt da zusammenbringt: Ich will irgendwas installieren/deinstallieren (statt hplip ist irgendwas anderes vorstellbar), dann kommt apt auf den Trichter: Moment, irgendwas stimmt mit den kernels nicht, lass ich doch mal eben lilo laufen, das geht dann schief und schon liegt das gute apt auf der Nase und vergisst, was es eigentlich machen sollte. Hoffe, das hat dich etwas erleuchtet.

PS: Aber lass das mal, das ist wirklich ne andere Baustelle.

[edit] Kern wie vorgeschlagen gebaut und läuft. Wieder was gelernt! Aber /dev/devtmpfs ist nach wie vor Fehlanzeige. Mal 'ne dumme Frage: Besitzt eigentlich außer cosmac jemand sowas?