HDMU_13999_AzboxHD_OE_1989_Flash.zip vom 16-Apr-2015 00:49

[SpaceRat]

dann ist es klar,
da bonkel den Kernel für das neue ipv6 Image verändert hat spiesst sich das mit den anderen Images...

Das kann aber eher nicht am zugefügten IPv6 liegen, sondern eher an irgendwas, was er dafür rausgenommen hat.
Der Kernel sah mir schon sehr geschrumpft aus ...

Ich würde ja vorschlagen, methodisch vorzugehen:
Kernel zurück auf Anfang und dann Schritt für Schritt Optionen rausnehmen.

[morly]

kann wer ipv6 testen?

- - - Aktualisiert - - -

ein log vom nicht-bootendem Image wäre sehr hilfreich!

[santa]

Bonkel hat wenig am Kernel deaktiviert, nur auf Module umgestellt...

[SpaceRat]

Bonkel hat wenig am Kernel deaktiviert, nur auf Module umgestellt...

Das reicht schon, wenn er z.B. ein für den Boot notwendiges Dateisystem modularisiert hat, das Boot-FS muß im Kernel sein.

Soweit ich weiß sind die ext-Dateisysteme nicht nur abwärts- sondern auch begrenzt aufwärtskompatibel, d.h. es kann auch Konstrukte geben wie das ein File-System zuerst mit ext2 gemountet und später erst mit ext3/ext4 remounted wird.
ext2/ext3/ext4 sollte man also nur im Ausnahmefall als Modul bauen, vor allem auf so einem komplizierten Multiboot-Konstrukt.

[morly]

Bonkel hat wenig am Kernel deaktiviert, nur auf Module umgestellt...

das genügt ja - die Module sind dann im Image und nicht im Kernel - fehlen somit bei Images die den geschrumpften HDMU Kernel verwenden

[santa]

Naja, ganz ehrlich. Multiboot mit einem Kernel ist Banane und der der das erfunden hat sollte erschlagen werden.
Das ist einfach nur pfusch und gehört auf keine anständige Box, entweder ich kann die bootargs verdrehen oder ich lass es sein.
Es ist doch praktisch unmöglich in der heutigen Zeit in der die Teams weiter auseinander gehen die Kernel gleich zu halten.

[SpaceRat]

kann wer ipv6 testen?

Als Trockentest ist besagtes

netstat -tulpen

oder

netstat -tupen

schon sehr aussagekräftig.

Man kann nämlich durchaus auch mit einem IPv4-only-Kernel in der inetd.conf "tcp6" verwenden (Man braucht also keine unterschiedlichen Versionen zu pflegen).

Das Ergebnis sieht auf einer IPv4-only-Kiste dann natürlich trotzdem so aus:

root@dm800se:~# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8001            0.0.0.0:*               LISTEN      635/enigma2
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      635/enigma2
tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN      481/oscam
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      598/inetd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      576/dropbear
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      598/inetd
netstat: /proc/net/tcp6: No such file or directory
udp        0      0 0.0.0.0:33804           0.0.0.0:*                           613/avahi-daemon: r
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           613/avahi-daemon: r
netstat: /proc/net/udp6: No such file or directory

D.h. man erhält trotzdem IPv4-only-listener (Erkennbar am 0.0.0.0) und - weil netstat IPv6 kann, aber der Kernel nicht - auch noch die Fehlermeldungen
netstat: /proc/net/tcp6: No such file or directory
und
netstat: /proc/net/udp6: No such file or directory


So sähe es dann bei vorhandenem IPv6 aus:

root@vuduo2:~# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      635/dropbear
tcp        0      0 :::12000                :::*                    LISTEN      314/oscam
tcp        0      0 :::8001                 :::*                    LISTEN      705/inetd
tcp        0      0 :::80                   :::*                    LISTEN      748/enigma2
tcp        0      0 :::81                   :::*                    LISTEN      314/oscam
tcp        0      0 :::21                   :::*                    LISTEN      705/inetd
tcp        0      0 :::22                   :::*                    LISTEN      635/dropbear
tcp        0      0 :::23                   :::*                    LISTEN      705/inetd

... es wurden also wirklich Dual-Stack-Listener (Erkennbar am "::") angelegt, nur dropbear fällt aus der Reihe, der verwendet zwei getrennte Socken für IPv4 und IPv6.

[morly]

Naja, ganz ehrlich. Multiboot mit einem Kernel ist Banane und der der das erfunden hat sollte erschlagen werden.

geb ich dir absolut recht - unsere Linux haben auch unterschiedliche Kernel
also entweder kleinerer Kernel mit ipv6 Support oder MB... bin für ersteres

- - - Aktualisiert - - -

@SpaceRat: nun gut oder schlecht?

[santa]

Spacerat hat keine az, das musst du oder jemand anderes mal bei sich eingeben.

[SpaceRat]

Naja, ganz ehrlich. Multiboot mit einem Kernel ist Banane und der der das erfunden hat sollte erschlagen werden.

Da stimme ich Dir zwar zu, aber so ungewöhnlich ist das gar nicht.

Bei Virtualisierungslösungen gibt es das auch, daß alle VMs denselben Kernel (Entsprechend in derselben Konfiguration) verwenden (müssen).
Das merkst Du spätestens, wenn Du auf so realisierten vServern mal den Kernel mit sit-Modul selber bauen willst.

- - - Aktualisiert - - -

also entweder kleinerer Kernel mit ipv6 Support oder MB... bin für ersteres

Ich bin für beides

IPv6 alleine, das auch noch als Modul, das vergrößert den Kernel wirklich nur minimal.
Der Extremschrumpf ist also unnötig und damit sollte auch wiederum beides hinzukriegen sein.

Entweder/oder-Lösungen haben immer den Nachteil, daß am Ende "in-the-wild" irgendwelcher Kram gehaxx0red wird und der User guckt blöd aus der Wäsche, wenn der "Multiboot mit HDMU"-Hack dann doch das IPv6 kaputtmacht.