Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Technotrend S2-6400 geht nicht
#1
Hallo,
ich habe mich mal an die Installation der Pre-Alpha 008 gewagt.
Bin kein Spezialist für Linux aber ich konnte es immerhin installieren.

Habe das UEFI-Image ea5-prealpha-008-uefi.iso[url=http://ftp.gwdg.de/pub/linux/easyvdr/5.0/alpha/ea5-prealpha-008-uefi.iso][/url] heruntergeladen und mit Win32DiskImager auf einen USB-Stick übertragen.
Booten von Stick war möglich auf meinem BIOS-Mainboard, ich habe Unstable ausgewählt. Das habe ich so irgendwo im Forum gelesen: Unstable wählen.
Anschliessend auf Konsole 2 das Install-Script ausgeführt.
Zum Schluss kam die HW-Erkennung.

Bei der TV-Karte wurde korrekt Technotrend S2-6400 erkannt.
aber wenn ich den Treiber Linux-Experimental oder Linux-Original auswähle kommt bei beiden:
Paket nicht gefunden.

Habe dann das Setup weitegemacht und allles abgeschlossen.
Aber es kommt wie zu erwarten kein TV-Bild.
Dann habe ich den PChanger aktiviert und wollte Kodi starten, aber es passierte nichts.
Dann habe ich über den PChanger Firefox gewählt, aber es passierte nichts.
Dann habe ich auf dem Hintergrund im Desktop einen Rechtsklick gemacht und ein Terminal aufgemacht.
Befehl kodi startet dann Kodi, auch der Befehl firefox macht den Browser auf.

Hintergrund des Versuchs ist aber Amazon Prime:
Habe dann das PlugIn Amazon von Sandmann installiert und schon gefreut dass ich mich nun anmelden konnte, das war unter easyVDR 3.5 nicht möglich.
Aber die aktuelle Videoliste unter Amazon stimmt nicht, die Watchliste zeigt was anderes an als ich im Browser hinzugefügt habe.
Auch Suche ich nach Picard wegen der Serie "StarTrek - Picard" aber es taucht nicht auf obwohl es im Browser zu finden ist.

Frage: kann man die S2-6400 bereits verwenden in der PreAlpha?
Zitieren
#2
Hallo,

(14.03.2020, 09:58)momit schrieb: ...ich habe Unstable ausgewählt. Das habe ich so irgendwo im Forum gelesen: Unstable wählen.
Bitte Testing verwenden hatte ich nun schon öfters erwähnt.Das PPA heisst ja nicht umsonst unstable!

(14.03.2020, 09:58)momit schrieb: Bei der TV-Karte wurde korrekt Technotrend S2-6400 erkannt.
aber wenn ich den Treiber Linux-Experimental oder Linux-Original auswähle kommt bei beiden:
Paket nicht gefunden.
Die "S2-6400" wird erkannt es gibt aber keine Treiber.Paket media-experimental wird nicht mehr
vom Kernel unterstützt.Auch andere Pakete funktionieren nicht mit Kernel-5.x.x

(14.03.2020, 09:58)momit schrieb: Aber die aktuelle Videoliste unter Amazon stimmt nicht, die Watchliste zeigt was anderes an als ich im Browser hinzugefügt habe.
Bist du sicher das Addon "Amazon" noch funktioniert? ...was ist denn bei Kodi-Nerds darüber
zu lesen?

(14.03.2020, 09:58)momit schrieb: Frage: kann man die S2-6400 bereits verwenden in der PreAlpha?
Ja,wenn man sich die Kernel-Module(Treiber) selbst compiled.Leider wurde die Aufname des Treibers
in den Kernel abgelehnt.

Gruss
Wolfgang

Zitieren
#3
Hi, 
Der Treiber dafür ist nicht im offiziellen Kernel enthalten, daher muss der manuell hinzugefügt werden. Bisher gibt es wichtigere Baustellen als die zusätzlichen DVB Treiber. Den experimental gibt es nicht mehr. 
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1     -   v3.5-64
VDR2 in Rente
VDR3 in Rente
VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh.       -   v3.5-64
VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6"  t6963c gLCD, mod. Digitainergeh.          -   v3.5-64
VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200    -    v2.5-64
Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
Zitieren
#4
Hi
(14.03.2020, 12:46)mango schrieb: Bist du sicher das Addon "Amazon" noch funktioniert? ...was ist denn bei Kodi-Nerds darüber
zu lesen?
In der Richtung herrscht dort eine rege Diskussion. Bei dem was ich dort lese bin ich mir gerade auch unschlüssig ob das Addon noch geht. Was zuverlässig tut, ist das Netflix addon, bringt dir nur Richtung Picard nix Big Grin

Grüße Aaron
Mediacenter
easyVDR4.Alpha(Lubuntu18.04 64-Bit) Gigabyte, Ltd. H97-HD3 mit Intel® G3260 @ 3.30GHz 4GB DDRx,Intelgrafik,MATSHITA BD-MLT UJ265 Bluray LW, 2TB Festplatte,LCD+IRTrans-Empfänger,2x SkystarS2 PCI

Zitieren
#5
Hallo,

[OT]
Hab mich dagegen entschlossen Kodi auf 18.6 zu aktualisieren.Grund dafür ist das
damit Sky-Go nicht mehr funktioniert und es zu Problemen mit python3 kommen kann.
Hinzu kommt,ich musste/muss alle Pakte für Kodi-18.5/18.6 selbst übersetzen.
Seit kurzem bietet auch Ubuntu Kodi-18.5 für Focal an.
Also Achtung wenn man Addons von Kodi installiert die aus den Quellen von Ubuntu stammen.
...muss nicht zu Problemen führen,kann aber!
[/OT]

Gruss
Wolfgang

Zitieren
#6
Danke an alle für die vielen Hnweise und Tipps.
Ich probiere es nochmal mit der Installation Testing.

Den Treiber für die S2-6400 selber kompilieren würde ich mir zutrauen.
Dann könnte ich die Installation auch mal längere Zeit testen wenn ich TV schauen könnte.

Habe gegoogelt und einiges gefunden, aber ich denke die Quelle muss zum Kernel passen.

Z.B. hier:
https://bitbucket.org/powARman/v4l-dvb-s...c/default/
oder
http://www.vdr-wiki.de/wiki/index.php/Ub...VB_Treiber
oder
https://www.vdr-portal.de/forum/index.ph.../&pageNo=2

Vielleicht macht das in der PreAlpha keinen Sinn, bin wohl zu früh.
Falls es aber doch schon passende Treiber für den Kernel 5 irgendwo gibt die ich selbser kompilieren könnte dann würde ich es versuchen.
Vielleicht kann mir jemand einen Link nennen. Wo bekomme ich den Treiber den SurfaceCleanerZ erwähnte?

Ansonsten bleibe ich erstmal bei easyVDR 3.5 und warte bis es soweit ist und die zusätzlichen DVB Treiber getestet werden können.

Danke
Zitieren
#7
Hi, 
Dein letzter Link führt zu Sören, der den src wartet:
https://github.com/s-moch/linux-saa716x/branches
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1     -   v3.5-64
VDR2 in Rente
VDR3 in Rente
VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh.       -   v3.5-64
VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6"  t6963c gLCD, mod. Digitainergeh.          -   v3.5-64
VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200    -    v2.5-64
Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
Zitieren
#8
Hallo,

Github:
auf Seite Releases > https://github.com/s-moch/linux-saa716x/releases
Sources:
Kernel 5.3 > https://github.com/s-moch/linux-saa716x/...5.3.tar.gz

P.S
Im VDR-Portal gibt es ein HowTo wie man nur die benötigten Module auswählt und nur
diese compiled.Dies geht schneller als den Kernel komplett zu bauen.

P.S
Du solltes jedoch den Kernel-Sources von Ubuntu nehmen und den Kernel patchen.
Hier das diff gegen den Kernel-Sources
Code:
wget https://github.com/s-moch/linux-saa716x/compare/v5.3...saa716x-5.3.diff

Gruss
Wolfgang

Zitieren
#9
Hallo Mango,

danke für die Links.
Ich habe nun erst mal alles vorbereitet:
- eine zweite Festplatte in meinen Wohnzimmer PC eingebaut, damit muss ich nicht mehr mein laufendes 3.5er platt machen. Habe das PreAlpha8 drauf gemacht mit Testing und abschliessend ein apt-get update, apt-get upgrade. War hoffentlich OK
- Zum Kompilieren: weil das sehr lange dauern kann habe ich dafür auf meinem PC eine VMWare mit der PreAlpha8 installiert. Genau wie am WohnzimmerPC
- apt-get install open-vm-tools
- Dann mit WinSCP auf die VM eingeloggt OK, Putty als easyvdr OK
- Dann habe ich nachgeschaut: /boot/vmlinuz verlinkt auf einen 5.4.0.18 kernel

Fragen:
sollte ich dann eher den Link nehmen:
https://github.com/s-moch/linux-saa716x/...5.4.tar.gz
Scheinbar handelt es sich inzwischen um einen Kernel 5.4 oder war das apt-get upgrade falsch von mir?

Du erwähntst den patch für 5.3, falls 5.4 richtig wäre: gibt es den Patch auch für 5.4 ?
Hab mal das versucht:
wget https://github.com/s-moch/linux-saa716x/...x-5.4.diff
Hab einfach aus 5.3 -> 5.4 geändert im Link und es hat etwas heruntergeladen, wäre das so richtig zum weiteren patchen?

Das erwähnte HowTo konnte ich nicht finden, es gibt sehr viele Beiträge, konnte keines finden was zu meinem vorhaben passt.
Vor 20-25J habe ich mal kernel und module kompiliert, ist lange her.
Damals gab es ein der konsole ein Textbasierter Konfigurator bevor man den kernel kompilierte.
make modules kompiliert die Module.
Meinst du das im Prinzip? Oder schick mir bitte den Link zum Howto was du meinst damit ich nicht umsonst was falsches kompiliere.

Hab auch das hier gefunden, das könnte zum vorhaben passen:
https://www.heise.de/ct/artikel/Linux-Ke...02386.html
Zitieren
#10
OK,
hab jetzt zwei Module mit source 5.4.0.18 und dem patch kompiliert:
saa716x_core.ko
saa716x_ff.ko

Bei modprobe kommt:
Exec format error

Scheint was nicht mit der Kernelversion zu stimmen, oder?

/boot/vmlinuz verweist auf 5.4.0.18-generic an
Den Source hatte ich mit apt-get install linux-source geholt, danach ausgepackt. Es ist 5.4.0.18.22
Die Header waren schon vorhanden mit 5.4.0.18-generic
Die Kernelconfig habe ich aus /boot in die entpackte Source als .config kopiert.
patch ~5.4.diff brachte keine Fehler.
make localyesconfig
make menuconfig
Treiber als Modul aktiviert:
Device drivers ->
<M> Multimediasupport
[*] digital TV support
[*] Media PCI support ->
[*] Support for SAA7160/1/2 family from Philips ->
<M> SAA7160/1/2 based full featured PCIe cards
Das müsste doch passen zur TT-S2-6400 ?
make -j6 modules
danach wurden die Module kompiliert was auch nicht so sehr lange gedauert hat.
Aber es kommt halt der Fehler Exec format error.
Zitieren
#11
Hallo,

(21.03.2020, 22:14)momit schrieb: saa716x_core.ko
saa716x_ff.ko
hast du die Module auch in die richtigen Verzeichnisse kopiert?
Code:
sudo cp drivers/media/common/saa716x/saa716x_core.ko /lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/
sudo cp drivers/media/common/saa716x/saa716x_ff.ko /lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/
sudo depmod 5.4.0-18-generic


(21.03.2020, 22:14)momit schrieb: danach wurden die Module kompiliert was auch nicht so sehr lange gedauert hat.
sind ja nur 2 Module das geht ratz fatz Wink

Gruss
Wolfgang

Zitieren
#12
Hi mango,

hab nochmal nachgeschaut:
root@easyVDR:/lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/saa716x# ls -All
insgesamt 6300
-rw-r--r-- 1 root root 4324272 Mär 21 22:23 saa716x_core.ko
-rw-r--r-- 1 root root 2124544 Mär 21 22:23 saa716x_ff.ko
root@easyVDR:/lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/saa716x#

Habe dafür einen eigenen Ordner saa716x angelegt entsprechend den vorhandenen:
es gab bereits einen Ordner saa7164 und in diesem ist eine saa7164.ko.
Also habe ich das so ähnlich für die neuen files gemacht.
Mir fällt noch auf dass die neuen Treiber sehr viel größer als die vorhandene saa7164.ko ist.


Nach dem kompilieren hatte ich auch depmod -a gemacht und dann versucht:
root@easyVDR:/# modprobe saa716x_ff
modprobe: ERROR: could not insert 'saa716x_ff': Exec format error
root@easyVDR:/# modprobe saa716x_core
modprobe: ERROR: could not insert 'saa716x_core': Exec format error


Ausserdem hatte ich gestern nochmal die /boot/config~ mit der geänderten in der kernel-souce angeschaut:
original der PreAlpha:
CONFIG_VERSION_SIGNATURE="Ubuntu 5.4.0-18.22-generic 5.4.24"
Nach make menuconfig in der Source/.config findet man:
CONFIG_VERSION_SIGNATURE="Ubuntu 5.4.0-18.22-generic 5.4.24"

Scheint also alles richtig zu sein, oder?
Zitieren
#13
Sehr fragwürdig, ob diese merkwürdige Vorgehensweise überhaupt zum Ziel führt.

Generell gilt, dass kernel und kernel module mit dem gleichen compiler, den gleichen sourcen und der gleichen konfig gebaut werden sollten.
Der kernel prüft (wenn nicht explizit die config Option gesetzt ist, das NICHT zu tun), ob Kernel build Version zu den Modulen passt.

Ebenso fraglich ist, ob die .config in /boot wirklich zum Bauen des Kernels verwendet wurde.

Besser nimmt man - ebenso wieder falls diese config Option aktiviert wurde - die für den Kernel wirklich verwendete .config aus dem /proc Verzeichnis: /proc/config.gz. Natürlich nach einem make clean  make && distclean sowie einem make oldconfig.

Und neue Ordner im Kernel module tree anzulegen halte ich erst recht für bemerkenswert.
Du brauchst Hilfe? Wir brauchen Daten!
while (! asleep()) sheep++;
Zitieren
#14
Hallo Wirbel,

nicht so sehr wundern, ich habe oben schon geschrieben dass mein letzter Kernel compilieren ca. 20J her ist.
Wenn was merkwürdig ist dann schreibe ruhig was du meinst. Bin nicht up-to-date.
Natürlich habe ich die "/boot/config-5.4.0.18-generic" schon manuell in den Source kopiert. Nach dem make localyesconfig war sie als Kopie .config auch im Source zu finden.
Nach make menuconfig war .config sehr viel kleiner aber das halte ich für normal, oder?
Die "/proc/config.gz" exitiert in der easyVDR 5 PreAlpha 008 nicht. Hab im ganzen System nach "config.gz" gesucht, exisitiert nicht.
Bin ziemlich sicher dass die /boot/config~ verwendet wurde.

Zuert hatte ich die zwei neuen Module in ein vorhandene kernel module tree Verzeichnis kopiert, erst später mal zum Test ein neues angelegt. Mango schrieb es soll direkt unter ../media/pci kopier werden. Das habe ich auch getan, danach depmod -a trotzdem "Exec format error"

make clean make && distclean make oldconfig probiere ich noch aus. Danke für den Hinweis.

Ich werde auch mal die bereits (nicht von mir) vorhandenen Sourcen/Header etc. und auch den kernel 5.4.0.9 löschen.
Aktiv ist ja 5.4.0.18 (so hab ich es vorgefunden)
Nur um sicher zu sein.
Mal schauen was dann raus kommt.

Wenn das alles scheitert warte ich halt ab bis die Profis das richtig machen. Es schrieb ja oben schon einer dass anderes wichtiger wäre.
Zitieren
#15
Hab es nochmal wie es Wirbel schreibt probiert, es kommt wieder Exec format error.
Alles neu installiert und nochmal angefangen bringt auch nichts, wieder das gleiche.
Habe noch eine .config unter /usr/src/linux-headers-5.4.0-18-generic gedunden und diese verwendet.
Die Module werden deutlich kleiner aber es kommt wieder Exec format error beim Versuch die Module zu laden.
Nun fiel mir aber was auf:
in VMWare wird im admin terminal direkt beim laden mit modprobe saa716x_ff das angezeigt:
saa716x_core: version magic '5.4.24 SMP mod_unload ' should be '5.4.0-18-generic SMP mod_unload '

Das ist unter putty nicht zu sehen wenn ich modprobe ausführe, aber mit dmesg | grep saa kommt auch:
saa716x_core: version magic '5.4.24 SMP mod_unload ' should be '5.4.0-18-generic SMP mod_unload '

Komisch putty terminal verhält sich anders als das terminal direkt in der Maschine.
Also stimmt vermutlich doch was nicht mit den Versionen, die Header waren ja bereits vorinstalliert und die linux-source noch nicht.
Passen die zusammen, oder was stimmt hier nicht?
In den makefiles der Header wie auch Source findet man stets:
VERSION = 5
PATCHLEVEL = 4
SUBLEVEL = 24
Zitieren
#16
Tja, schwer hier echte Tipps zu geben, wenn das Pferd von hinten aufgezäumt werden soll.




>> Hab es nochmal wie es Wirbel schreibt probiert, es kommt wieder Exec format error.

Äh, nee. Hast du nicht, sonst gäbs ja den Fehler nicht.

Du hast irgendwas vom dem nicht umgesetzt:
Zitat:Generell gilt, dass kernel und kernel module mit dem gleichen compiler, den gleichen sourcen und der gleichen konfig gebaut werden sollten.

Du hast ..

1. nicht die .config des Kernels verwendet. Hattest du ja wohl gar nicht. Wenn du die nicht hast, musst du einen neuen Kernel plus neue module bauen und installieren. Eben damit alles zusammen passt.

2. nachdem du eine x-beliebige config in die Kernel sourcen kopiert hast (hoffentlich wenigstens als .config), mit einem mutigen "make localyesconfig" eine völlig neue .config erzeugt, die absolut nichts mehr mit der vorher .config des bereits installierten Kernels zu tun hat.

3. danach diese .config ein zweites mal mit einem "make menuconfig" verändert. Zumindest wenn du gespeichert hast; ansonsten hättest du dir den Befehl aber komplett sparen können.


Außerdem werden kernel module mit
"make modules" gebaut und mit
"make modules_install" danach installiert.

Insofern ist auch der Tipp mit dem händischen Kopieren der Module IMO nicht ganz sauber.




Sehr wahrscheinlich fehlt noch ein
"make EXTRAVERSION=<WHATEVER> modules_prepare" vor dem Bau der Module.

Braucht man sonst *nie*, wenn man einen Kernel korrekt von Anfang bis Ende baut. Was übrigens auch die Frage aufwirft, ob eine initrd benutz wurde für diesen Kernel.


"make modules_install" ruft depmod mit den korrekten Parametern auf. Nur so kannst du die Module später mit modprobe laden. Es gibt zwar noch den Weg via insmod, aber da werden keine Abhängigkeiten und keine Reihenfolgen der Module berücksichtigt. Man kann nat. auch in genau diesen Kernel booten und dort 'depmod -a' aufrufen.


Übrigens hat sich nichts davon in den letzten 20 Jahren *grundlegend* verändert - auch wenn sich die tool chains moderat verändert haben und das /sys Dateisystem plus udev dazu (anstelle devfs oder statischen device nodes) kamen.  Also zumindest seit Kernel 2.0.16 nicht..

Und solange der Kernel nicht sauber mit den neuen Modulen läuft, solltest du von virtuellen Maschinen in denen das System läuft die Finger lassen.
Du brauchst Hilfe? Wir brauchen Daten!
while (! asleep()) sheep++;
Zitieren
#17
Hallo,

Wirbel hat natürlich recht, es muss alles zusammenpassen. Das ist klar.

Hab es aber schon selber zum laufen bekommen. Halt auf meine merkwürdige Methode, das Pferd von hinten aufzäumen oder wie man es nennen will.
War ja schon oben meine Vermutung dass etwas nicht zusammenpasst wenn "Exec format error" erscheint.
Hab aber auch nichts gefunden welche config+Source+Header etc verwendet wurden, ist ja auch eine PreAlpha 008. Vermutlich nicht ausgelegt dass man passende Treiber selbst kompiliert.
Wie gesagt: jetzt geht es und ich kann nun auch im Wohnzimmer an der echten Maschine das tun was ich in der VM gemacht habe (VM ist OK wenn man nicht stundenlang das Wohnzimmer blockieren will, nur zum üben bequem)
Das TV Bild meiner TT-S2-6400 ist nun da. Ohne den Kernel neu kompilieren. Nur die Module saa716x_ff und saa716x_core hinzugefügt. War ganz einfach, qucik&dirty.
Es ist mir klar dass es nicht "sauber" ist, aber was solls: es ist doch nur eine Alpha die schon bald platt gemacht wird.
(fragt bloss nicht wie ich es gemacht habe, ein Profi würde die Hände über dem Kopf schlafen. Aber für mich als Laie ist es OK in einer Alphavariante den einfachen Weg zu gehen. Denn schon morgen könnte es ein neues iso geben. Hatte keine Lust zum Kernel kompilieren)
Die Fernbedienung der TT-S2-6400 geht übrigens auch.

Hauptziel für meinen Testanlauf habe ich auch nicht vergessen:
die PreAlpha008 antesten, mit einem Glas Rotwein abends etwas TV schauen und auch mal mit Amazon Prime unter Kodi StarTrek Picard schauen.
Das habe ich gerade auch gemacht und zu meiner Freude ist das Bild flüssig und ohne Streifen. Es gab keine Probleme.

Unter easyVDR 3.5 musste ich das im Chromebrowser schauen, aber da ruckelt das Video bei Vollbild, sowohl in YouTube wie auch Amazon Prime etc.
Unter Kodi gab es nie Video-Bildfehler, nur ging halt Amazon Prime bisher nicht: Python3 muss sein.

Das geht jetzt in easyVDR 5 PreAlpha008 wunderbar.
Die Tipps von Mango und SurfaceCleanerZ waren am hilfreichsten
Danke aber an alle.
Als nächstes schaue ich mir den PChanger an, der startet keine der Programme aus dem Menü. Aktuell muss man kodi oder firefox aus dem Terminal starten. Nicht so schön mit einem Glas Rotwein in der Hand...

Thema TT-S2-6400 kann man nun abschliessen.
Zitieren
#18
Hallo,

(29.03.2020, 19:37)momit schrieb: Das TV Bild meiner TT-S2-6400 ist nun da. Ohne den Kernel neu kompilieren. Nur die Module saa716x_ff und saa716x_core hinzugefügt. War ganz einfach, qucik&dirty.
Es ist mir klar dass es nicht "sauber" ist, aber was solls: es ist doch nur eine Alpha die schon bald platt gemacht wird.
(fragt bloss nicht wie ich es gemacht habe, ein Profi würde die Hände über dem Kopf schlafen. Aber für mich als Laie ist es OK in einer Alphavariante den einfachen Weg zu gehen. Denn schon morgen könnte es ein neues iso geben. Hatte keine Lust zum Kernel kompilieren)
hast du nach der Anleitung von S:oren VDR-Portal die Module gebaut?
...schade das du die Schritte nicht dokumentiert hast!

Gruss
Wolfgang

Zitieren
#19
Hallo Mango,

danke für den Link, habe das vorher nicht gelesen, aber es sieht so aus dass S:oren genau die gleichen Problembilder hatte.
Wenn ich das durchlese habe ich im Prinzip auch alles versucht wie S:oren.

Da sich zu meinem Fall niemand mit konkreten Angaben geäussert hatte welche config+Source+Headers etc in der PreAlpha008 verwendet wurden und wo man die Downloaden könnte und die üblichen Routinen nicht zum Erfolg führten (wie bei S:oren auch, der meinte Ubuntu würde sich gruselig verhalten was die Versionskennungen betrifft)
musste ich halt das tun was Wirbel ganz bestimmt als merkwürdig und falsch beschreiben würde, ist ja auch so.

Aber es funzt und das ist mir ausreichend, also gut hier meine schreckliche Vorgehensweise:
1. easyVDR PreAlpha008 iso mittels Win32DiskImager auf USB-Stick, BIOS-Mainboard bootet
2. Testing ausgewählt und installiert
3. nach der Installation EasyVDR Setup abgeschlossen
4. nun in eine Adminkonsole: apt-get update
5. normalerweise hätte ich nun auch apt-get upgrade gemacht, aber zu dem Zeitpunkt wollte ich das noch nicht. Nachdem ich später die Module erfolgreich kompiliert und laden konnte habe ich es dann doch gemacht, ich würde im nachhinein sagen: apt-get upgrade schon bei 5. ausführen, hatte keinen Einfluss zum Problem Exec format error
6. apt-get install linux-source sowie auch: libssl-dev, libelf-dev, libncurses5-dev, flex, bison
(ich hatte auch wie bei S:oren apt-get source linux versucht, natürlich vorher die source.list geändert. Es wurde aber der gleiche Source geladen:
5.4.0-18.22-generic. Aktiver kernel ist aber 5.4.0-18-generic. Ich fand im Internet nichts zum downloaden was nur diese Versionskennung hätte. Also habe ich es mit apt-get install linux-source belassen)
7. cd /usr/src
8. tar -xjf linux-source-5.4.0.tar.bz2 das packt die Source aus
(in dem Makefile steht als Versionskennung 5.4.24)
9. cd linux-source-5.4.0
10. wget https://github.com/s-moch/linux-saa716x/...x-5.3.diff
11. patch -p1 < v5.3...saa716x-5.3.diff, ohne Fehler durchlaufen
12. cp /boot/config-'uname -r' .config -> das holt die config in die sourcen, aber nach dem kompilieren waren die Module sehr groß (das hatte S:oren auch)
in der /boot/config~ findet man im Kopf:
# Linux/x86 5.4.0-18-generic Kernel Configuration
# Compiler: gcc (Ubuntu 9.2.1-31ubuntu3) 9.2.1 20200306
diese config ist vom 7.3.2020 17:23 mit 237651 Bytes
Die einzige config die man noch im System findet ist unter:
/usr/src/linux-headers-5.4.0-18-generic -> diese hat den gleichen Kopfzeilen:
# Linux/x86 5.4.0-18-generic Kernel Configuration
# Compiler: gcc (Ubuntu 9.2.1-31ubuntu3) 9.2.1 20200306
diese config ist auch vom 7.3.2020 17:23 aber mit 237662 Bytes
13. cp /usr/src/linux-headers-5.4.0-18-generic/.config .config -> kopierte diese config in die source, Exec format error tritt damit auch auf.
14. Meine Schlussfolgerung: ich habe nicht die sourcen die verwendet wurde oder die Versionskennung wurde geändert, keine Ahnung wer der kernel Entwickler bei easyVDR ist der das sagen kann.
15. habe im ubuntu launchpad danach gesucht, .22 scheint ein patchlevel zu sein (vor 20j hatte ich nur SUSE und RedHat zu tun, mit Ubuntu kenne ich mich nicht aus)
5.4.24 scheint aber eine Kennung für ein Ubuntu focal update zu sein, nicht die Kernelversion weiss nicht wie das Konzept da bei Ubuntu aussieht.
Möglicherweise wäre das der richtige Source für easyVDR:
https://launchpad.net/ubuntu/+archive/pr...rig.tar.gz
hab dann noch in der diff dazu nachgeschaut was sich so geändert hatte. Habs aber nicht probiert, kenne mich mit dem Ubuntu
Keine Ahnug wie die das pflegen.
16. hab einfach in der mit apt-get install linux-source geholten sourcen (und mit tar entpackten) makefile das eingetragen:
VERSION = 5
PATCHLEVEL = 4
SUBLEVEL = 0
EXTRAVERSION = -18-generic
17. make localyesconfig
18. neue config zeigt im Kopf nun die neue Kennung, ebenso
CONFIG_VERSION_SIGNATURE="Ubuntu 5.4.0-18-generic 5.4.24"
ICH WEISS: GANZ ARG QUICK&DIRTY, aber ist doch egal bei einer Alpha.
19. make -j6 modules
20. cp drivers/media/common/saa716x/saa716x_core.ko /lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/
cp drivers/media/common/saa716x/saa716x_ff.ko /lib/modules/5.4.0-18-generic/kernel/drivers/media/pci/
das kopiert die neuen module
21. depmod -A
22. modinfo saa716x_ff zeigt nun die richtige Versionskennung an:
vermagic: 5.4.0-18-generic SMP mod_unload
23. modprobe saa716x_ff meldet keine Fehler mehr, kein Exec format error
24. lsmod | grep saa zeigt:
saa716x_ff 40960 0
saa716x_core 49152 1 saa716x_ff
dvb_core 139264 2 saa716x_ff,saa716x_core
Scheint geladen zu sein.
25. weil ich diese Übung nicht nochmal an der echten Hardware im Wohnzimmer ausführen wollte:
kopieren der neuen Module mit WinSCP von der VM-Maschine in den Wohnzimmer PC, depmod -A
26. die Module wurden wie in VM ohne Fehler geladen, Systemneustart, TV Bild war sofort da (hat mich etwas überrascht gebe es zu, aber der Rotwein hat dann super geschmeckt.)
Mal sehen was Wirbel sagt. Mir wäre es lieber er würde wissen welche config source und header in der PreAlpha 008 verwendet wurde und wo man sie her bekommt.
Das wäre eine konkrete Hilfe.

S:oren schrieb übrigens am Ende:
Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...

Das was von dir "mango" kommt ist bisher viel hilfreicher gewesen. Bei dir steht "Entwickler-Kern". Bist du das bei easyVDR?
Vielleicht weisst du was ich falsch mache beim download der sourcen mit apt-get.
Bei den easyVDR war ich schon hier:
https://launchpad.net/~easyvdr-team
und
https://git.easy-vdr.de/easyvdr
finde aber nichs zu focal was verwendet wurde
Gruss
Timo
Zitieren
#20
Hi, 
Wir bauen bei der v5 keine Kernel, die kommen von Ubuntu Focal Server. 
Warum das Mischmasch entsteht kann ich nicht sagen... 
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1     -   v3.5-64
VDR2 in Rente
VDR3 in Rente
VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh.       -   v3.5-64
VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6"  t6963c gLCD, mod. Digitainergeh.          -   v3.5-64
VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200    -    v2.5-64
Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
Zitieren
#21
Sinnvoll wäre, sich die .config aus /boot mal anzusehen. Als unveränderte Datei.
Eigentlich legt man beim Bauen die passende config neben der System.map des Kernels dort ab.

Man könnte mal auf die Zeilen in General Setup schauen, zu welchem Kernel (Version 5.4.x und extra Version) diese config gehört.
Ebenso würde man herausfinden, ob CONFIG_IKCONFIG oder CONFIG_IKCONFIG_PROC gesetzt sind.
Du brauchst Hilfe? Wir brauchen Daten!
while (! asleep()) sheep++;
Zitieren
#22
Hallo Wirbel,

nach Installation der easyVDR 5 PreAlpha 008 war es so und ist es aktuell auch noch:
/boot/config-5.4.0-18-generic:
unter general setup erscheint:
CONFIG_VERSION_SIGNATURE="Ubuntu 5.4.0-18-generic 5.4.24"
sowie
CONFIG_IKCONFIG ist nicht gesetzt

das gleiche unter:
/usr/src/linux-headers-5.4.0-18-generic:
unter general setup erscheint:
CONFIG_VERSION_SIGNATURE="Ubuntu 5.4.0-18-generic 5.4.24"
sowie
CONFIG_IKCONFIG ist nicht gesetzt

Die sourcen die mit apt source linux oder apt-get install linux-source geholt werden sind stets:
5.4.0-18.22-generic 5.4.24

Auf dem Launchpad von Ubuntu finde ich nur diese neueren Source
Habe inzwischen auch mal bei Ubuntu KernelTeam geschaut, da steht was:

https://wiki.ubuntu.com/Kernel/FAQ
->
Given an Ubuntu kernel package version how do we find the release it is from?
The kernel package version is of the following form 2.6.35-6.9. The numbers before the - represent the base upstream version from which this kernel was forked, the first number following the - represents the ABI number, the final number is an upload number. Taking the package version first remove the upload number, then round the ABI number down to the nearest hundred (which can include 0), for example:

2.6.35-6.9 => 2.6.35-6 => 2.6.35-0

Look up the final version in the Kernel/Dev/TopicBranches mapping tables (see Current Branches). Once you have the release and branch you can obtain the source.

und auch hier:

https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
->
By default you will have the latest version of the kernel tree, the master tree. You can switch to any previously released kernel version using the release tags. To obtain a full list of the tagged versions in the release as below:

Das scheint wohl das Konzept bei Ubuntu zu sein, man bekommt immer den letzten Stand der sourcen der dann aber zum bereits kompilierten Kernel nicht unbedingt passt.
Hab ich das so richtig verstanden? (Hab mir bei Debian, SUSE, RedHat, LinVDR etc noch nie den Kopf zerbrechen müssen wie ich an die passenden Sourcen komme. Das laden aus der Repository hat da immer passenden Source geliefert, kann mir nicht vorstellen dass das nur Zufall war. Komisch das Ubuntukonzept)
Zitieren
#23
OK hab jetzt noch was gemerkt:
bei apt-get upgrade werden einige Pakete zurückgehalten:
linux-generic linux-headers-generic linux-image-generic.
Wenn man die trotzdem installiert mit apt-get install linux-generic linux-headers-generic linux-image-generic
dann wird der kernel vmlinuz-5.4.0-21-generic mit den Headern 5.4.0.21.25 geholt. Dann werden mit apt-get install linux-source auch die passenden Sourcen 5.4.0.21.25 installiert. Dann ist die Welt ja wieder in Ordnung.
War also nur blockiert beim upgrade. Hätte nur den neuesten kernel installieren müssen. Aber das mach ich jetzt nicht mehr.
Zitieren
#24
Hi,

(31.03.2020, 21:33)momit schrieb: bei apt-get upgrade werden einige Pakete zurückgehalten:
das ist so gewollt.Man kann aber mit einem
Code:
sudo apt-mark unhold linux-generic linux-headers-generic linux-image-generic
den Hold lösen.Mit "sudo apt-mark showhold" werden Pakete die auf Hold gesetzt sind angezeigt.

(31.03.2020, 21:33)momit schrieb: Möglicherweise wäre das der richtige Source für easyVDR:
https://launchpad.net/ubuntu/+archive/pr...rig.tar.gz
Normalerweise sind Sources die mit .orig.tar.* enden Sources die nur den Orginal-Sources enthalten.
Da der Kernel anpassungen vom Distributor(Ubuntu) enthält,sind diese nie in den .orig.tar.* Tarballs

Gruss
Wolfgang

Zitieren
#25
@mango: das mit den sourcen ist ziemlich sicher so.

Andererseits wäre es wohl gut möglich einen eigenen Kernel (mit frischeren originalen Quellen von kernel.org) für easy-vdr zu haben, wenn man mal annimmt, dass die .config in /boot die richtige sein sollte.

Dort könnten dann die fehlenden Module gleich rein gepatcht werden, um eine Odyssee wie die von momit zu vermeiden.

Man hätte halt den Aufwand von Zeit zu Zeit einen neuen Kernel zu backen.
Mach ich seit Ewigkeiten so - wobei ich ja eh keine fertige Linux Distribution verwende.
Du brauchst Hilfe? Wir brauchen Daten!
while (! asleep()) sheep++;
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste