Nach stundenlangem Suche und Versuchen probier ich hier einen Rat zu finden.
Hab gestern mal wieder per apt-get upgrade versucht, meinen Cubie auf den aktuellen Stand zu bringen. Er läuft mit Igor's Image und Kernel 3.4.103.
Leider hängt das Update mehrerer Pakete, die Ursache scheint so gut wie immer ein Paket udev zu sein. Dieses läßt sich nicht aktualisieren und auch nicht deinstallieren (ist angeblich gar nicht da)
Nichts hilft:
apt-get install -f
und
apt-get dist-upgrade
Die Meldung sagt mir, der Kernel müsse upgedatet werden. Mit diesem Versuch habe ich nun die halbe Nacht verbracht. Hab immerhin Kernel 3.4.107 installiert bekommen. Allerdings kommt die gleiche Meldung immer noch. Offensichtlich gibt es noch neuer Kernels, Igor bietet etwa 3.19.4. Leider kann ich den nicht so einfach installieren wie bisher (download, entpacken und nach mounten von /dev/nand1 dort uImage ersetzen), da sich offensichtlich mehr geändert hat.
Bi offensichtlich zu dumm, die leider immer recht wortkargen Erläuterungen hierzu zu verstehen. Hat oder kennt jemand eine Schritt-für-Schritt-Lösung? Oder mindestens einen Tipp? So laufen nach dem Teil-Upgrade der Pakete leider viele Dinge nicht mehr. Beispielsweise gibt der Logitechmediaserver keinen Ton mehr von sich, und TTS spricht nicht mehr.
Hier die Meldung beim versuch udev zu aktualisieren/installieren:
Installiere Paket(e) mit Befehl apt-get -y install udev ..
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
udev
Preconfiguring packages ...
1 upgraded, 0 newly installed, 0 to remove and 124 not upgraded.
Need to get 0 B/853 kB of archives.
After this operation, 4981 kB of additional disk space will be used.
(Reading database ...
dpkg: warning: files list file for package 'hddtemp' missing; assuming package has no files currently installed
(Reading database ... 5%
.
.
.
.
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 111661 files and directories currently installed.)
Preparing to unpack .../archives/udev_215-17_armhf.deb ...
Since release 198, udev requires support for the following features in
the running kernel:
- inotify(2) (CONFIG_INOTIFY_USER)
- signalfd(2) (CONFIG_SIGNALFD)
- accept4(2)
- open_by_handle_at(2) (CONFIG_FHANDLE)
- timerfd_create(2) (CONFIG_TIMERFD)
- epoll_create(2) (CONFIG_EPOLL)
Please upgrade your kernel before or while upgrading udev.
AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.
There is always a safer way to upgrade, do not try this unless you
understand what you are doing!
dpkg: error processing archive /var/cache/apt/archives/udev_215-17_armhf.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/udev_215-17_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
.. Installation fehlgeschlagen!
Ich kann Dir zu Lösung direkt nicht helfen, Dir aber die Fehlermeldung erklären:
Since release 198, udev requires support for the following features in
the running kernel:
- inotify(2) (CONFIG_INOTIFY_USER)
- signalfd(2) (CONFIG_SIGNALFD)
- accept4(2)
- open_by_handle_at(2) (CONFIG_FHANDLE)
- timerfd_create(2) (CONFIG_TIMERFD)
- epoll_create(2) (CONFIG_EPOLL)
D.h. Du hast kein "alter" Problem des Kernels, sondern Dein Kernel ist nicht mit features gebaut, welche udev verlangt.
Wenn Du dieses udev haben möchtest, mußt Du Dir einen Kernel mit diesen Funktionen besorgen ...
Aber mal etwas anderes:
Was möchte das System denn (in Summe) updaten?
124 not upgraded.
Ist auch nicht gerade wenig ..
Zitat von: duke-f am 30 April 2015, 01:59:01
...Bi offensichtlich zu dumm, die leider immer recht wortkargen Erläuterungen hierzu zu verstehen...
Wieso wortkarg? Da steht doch eigentlich immer klar und deutlich, wo es hakt. ;)
udev lässt sich nicht upgraden, weil dazu Abhängigkeiten bzw. Features im Kernel fehlen.
Also musst Du erst den Kernel updaten.
Ich kenne mich mit dem Image nicht aus, was wird denn da gemountet und gesetzt?
Normalerweise wird ein Kernel automatisch per apt-get oder manuell (aus welcher Quelle auch immer) mittels dpkg oder so installiert.
Reguläre Reihenfolge ist eigentlich: apt-get update / apt-get upgrade
Bei apt-get dist-upgrade muss man schon wissen was man tut und ob alle Programme auch wirklich mit aktuellen libs etc. laufen.
Besten Dank für Eure Antworten.
Zitat von: Hollo am 30 April 2015, 09:21:55
Wieso wortkarg? Da steht doch eigentlich immer klar und deutlich, wo es hakt. ;)
Ich mache ja ganz bewusst niemand irgendwelche Vorwürfe. Wer bin ich denn? In solchen freiwilligen Foren ist doch jeder Hinweis irgendwie meist hilfreich. Deshalb sage ich auch: "Bin offensichtlich zu dumm...." :P
Dass der Kernel geupdatet werden muss, um udev in der aktuellen Version verwenden zu können, habe ich aus der Meldung herausgelesen, habe ich ja auch geschrieben. Dass der Kernel beim Cubie mittels apt-get udgl. geupgraded wird, stimmt offensichtlich gegenüber dem Raspberry beim Cubietruck nicht.
Zu den durchgeführten Updates: Ja, über 100 updates schien mir auch etwas viel, aber dieübliche Abfolge: apt-update / apt-upgrade kam ich eben genau zu diesem beschriebenen Zustand.
Und weiter: Ich "will" dieses udev gar nicht - kenne es ja nicht mal und weiß auch nicht, wie das update dazu kommt, das nachladen oder installieren zu wollen. Aber ich kann es auch nicht entfernen, weil apt-get remove meldet, es wäre gar nicht da.
An sich würde ich das alles einfach ignorieren, wenn nicht beispielsweise der Logitechmediaplayer und die Textausgabe mittels TTS nicht mehr ginge.
UDEV ist für die Geräteverwaltung wichtig. Ich weiß nicht, wie das Igor-Image es verwaltet .... Du kannst probieren, ohne udev zu fahren, es könte aber sein, das Dein System anschließend Softwaremäßig "geschrottet" ist.
P.S.
Hast Du Backup?
Habe ich gerade nachgelesen - ist wohl keine gute Idee, udev komplett zu entfernen. Ein Backup älteren Datums habe ich schon. Aber wie das Leben so spielt nicht mit allen aktuellen Ergänzungen.
Wird wohl darauf hinauslaufen, da zurückzuspringen. Stellt sich dann wiederum eben die Frage: Dann doch lieber auf die neue Version mit aktuellerem Kernel? Wäre halt schon der neue Kernel ließe sich wieder so einfach wie früher "unterschieben".
Zitat von: duke-f am 30 April 2015, 09:41:21
...Dass der Kernel geupdatet werden muss, um udev in der aktuellen Version verwenden zu können, habe ich aus der Meldung herausgelesen, habe ich ja auch geschrieben. Dass der Kernel beim Cubie mittels apt-get udgl. geupgraded wird, stimmt offensichtlich gegenüber dem Raspberry beim Cubietruck nicht...
War auch nicht bös gemeint von mir.
Kannst Du denn ein "cubian-update" laufen lassen wie beim Raspi?
Dabei würde ja auch Kernel etc. aktualisiert?
Allerdings auch nur der Kernel, der zum aktuellen Image passt/gehört.
Ich habe gerade geguckt...
Du kannst Dir doch den zum Board/Image passenden Kernel runterladen.
In dem tar-File sind normale .deb drin, die Du dann mit einem dpkg -i *deb installieren kannst.
Reboot und gut. Danach sollte auch Dein udev-Upgrade durchlaufen.
Kannst ja momentan nicht viel kaputt machen und vor dem Backup wäre es einen Versuch wert.
Zitat von: Hollo am 30 April 2015, 12:52:12
War auch nicht bös gemeint von mir.
Das weiß ich schon - nichts für ungut.
Zitat
Kannst Du denn ein "cubian-update" laufen lassen wie beim Raspi?
Offensichtlich gibt es da sowas nicht - ist halt wohl schon was sehr spezielles am Igor-Image. Sinnvoll wäre natürlich, dort direkt mal nachzufragen. Ist halt alles auf englisch und setzt für meine bescheidenen Kenntnisse von Linux auch wieder bisschen viel voraus.
Zitat
Kam die Meldung zu udev bereits beim apt-get update oder erst als Du ein dist-upgrade machen wolltest?
Dist-Upgrade musst Du ja nicht, ein "normales" Update ist ungefährlicher.
Hast Du die Paketquellen evtl. editiert oder haben die sich geändert?
Ich habe zur Vereinfachung auf dem Cubie wie auch auf den Raspies Webmin installiert und update gewöhnlich damit. Die dabei ausgeführten Kommandos sind aber wieder genau die üblichen apt-get upgrade/update.
Es war mir schon verdächtig, dass einige hundert dinge aktualisiert werden sollten. Hab' dem aber leider wenig Achtung geschenkt, da ich vor einiger Zeit versuchte mythtv zu installieren. Das war erfolgreich seitens der Installation, nur nicht effektiv für mich zu nutzen. Es mussten für die Compilation damals eben so einiges an Libraries geladen werden. Letztendlich gab es bei den vielen Upgrades eben die verbleibenden ca 125 die nicht aktualisiert werden konnten und soweit ich überblicke dies immer mit dem genannten Verweis auf udev.
Das ganze war schon bei apt-get update. Dist-upgrade hatte ich erst nach den Fehlern (erfolglos) versucht.
Quellen habe ich weder editiert noch geändert
Zitat von: Hollo am 30 April 2015, 12:52:12
Ich habe gerade geguckt...
Du kannst Dir doch den zum Board/Image passenden Kernel runterladen.
In dem tar-File sind normale .deb drin, die Du dann mit einem dpkg -i *deb installieren kannst.
Reboot und gut. Danach sollte auch Dein udev-Upgrade durchlaufen.
Kannst ja momentan nicht viel kaputt machen und vor dem Backup wäre es einen Versuch wert.
Wir überschneiden uns. :D
Danke für die Mühe. Genau so hatte ich mir das gedacht. Problem ist, dass ich bisher vom NAND boote, weil der Cubie nur von da oder der SD-Karte starten kann. Das Root-Verzeichnis liegt aber dann auf der SSD. Gehe ich nun den beschriebenen Weg (die .deb's habe ich schon) - wohin werden diese dann installiert? Laut betateilchen (der uns hier ja verloren ging ...) werden neuere Versionen von Igor-Image anders eingerichtet, per Link auf das /boot-Verzeichnis unter root.
Ensthaft:
Wenn Du etwas lernen willst, verwende anstatt Webmin lieber die Konsole (ssh Zugriff). Webmin ist schon "klickibunti", aber eben auch eine Zusätzliche Abstraktionsschicht, welche dir den Blick aufs System blockieren kann.
Vorallem aber:
Bei Problemen und Größeren Updates würde ich es direkt machen.
Wenn Du sagst, das eventuell durch eine ehemalige Software vil installiert wurde, hast Du mal probiert, Dein System aufzuräumen?
also:
apt-get -s autoremove
Edit:
Will hier keine Grundsatzdiskussion über Webmin beginnen. Ist nur meine persönliche, individuelle Meinung. Und meinen ersten Linuxserver habe ich mir mit Webmin "zerschossen" .... ist aber laaaange her ;o)
Ja, autoremove bringt aber genau die gleiche Meldung zwecks udev.
Und Webmin. Das ist mit solchen Dingen immer in gewissem Rahmen eine Frage der individuellen Situation. Meine Erfahrungen mit Webmin sind recht positiv. Aber im großen und ganzen mache ich vieles auch über ssh. Und in meinem speziellen Fall hier bin ich überzeugt, dass es nicht die Ursache von Webmin ist.
Aber wenn wir schon dabei sind: Vielleicht muss ich mich mal mit aptitude anstelle von apt-get beschäftigen. Da scheint sich doch was zu unterscheiden.
Hab's jetzt mit den aktuellsten bes von Igor's Website probiert. Leider schaffe ich es nicht, dass der Cubie bootet. Weder wenn ich die wie beschrieben erstellte boot.src auf den NAND1 spiele, noch wenn ich eine SD-Karte schreibe und davon versuche zu starten. :'(
War wieder eine vergebliche Nachtschicht...
Zitat von: duke-f am 30 April 2015, 13:13:25
...Genau so hatte ich mir das gedacht. Problem ist, dass ich bisher vom NAND boote, weil der Cubie nur von da oder der SD-Karte starten kann. Das Root-Verzeichnis liegt aber dann auf der SSD. Gehe ich nun den beschriebenen Weg (die .deb's habe ich schon) - wohin werden diese dann installiert? ...
Hast Du das denn jetzt mal probiert?
Die .deb-Dateien unter root in ein Verzeichnis (so was wie /usr/src oder /tmp oder egal) entpacken, in das Verzeichnis wechseln, und dann mit dpkg -i *.deb installieren.
Von wo Deine Karre startet ist doch Wurscht, der wird das schon dahin installieren, wo der alte Kernel auch liegt.
Ja, hab ich genau so gemacht - war aber nicht so.
Eine direkte Frage: Hast Du das schon so gemacht oder ist das Deine Vermutung. Bei mir läuft das beschriebene Verfahren nämlich so:
Debs kopiert, mit genanntem Befehl installiert, neustart und die Karre läuft überhaupt nicht mehr.
Also wieder Backup der Bootpartition von Backup auf NAND1 und die alte Version läuft wieder.
Ich habe keinen Cubie und vermute nur, analog zu anderen Linux-Systemen. :-X
Ist gut, dann bin ich doch nicht ganz falsch.
Auf meinem Cubie zumindest scheint das so nicht zu funktionieren. Ursprünglich war das System auf dem NAND, später habe ich es "umgebogen" auf die SSD, wobei die Boot-Partition m.W. auf NAND bleiben muss (oder alternativ auf der SD-Karte), direkt von SDD kan er nicht starten.
Trotzdem: Besten Dank, ein Versuch war es wert.
So um's abzuschließen:
Hab's geschafft 3.4.107 zu installieren und der Fehler zwecks udev ist verschwunden.
Die Schwierigkeit mit dem Kernel konnte ich mit Igor's Hilfe schnell lösen. Scheinbar ist meine Konfiguration doch nicht so normal wie ich dachte. Für die, die sich auskennen: Aus dem zImage musste ein uImage gebaut werden. ::)
Zitat von: duke-f am 01 Mai 2015, 17:42:44
So um's abzuschließen:
Hab's geschafft 3.4.107 zu installieren und der Fehler zwecks udev ist verschwunden.
Die Schwierigkeit mit dem Kernel konnte ich mit Igor's Hilfe schnell lösen. Scheinbar ist meine Konfiguration doch nicht so normal wie ich dachte. Für die, die sich auskennen: Aus dem zImage musste ein uImage gebaut werden. ::)
kannst Du grob die Lösung hier reinschreiben?
Ich habe heute auch ein Kernelupdate gewagt.
Ich bin nach folgender Anleitung für den Kernel vorgegangen.
Zitat
Here is how I succeeded with the installation of the 3.4.106 kernel:
First step: Installation of the firmware-, headers-, image- and libc-dev-file with dpkg -i.
Second step: Copy the vmlinuz-file to /tmp.
Third step: mkimage -l /boot/uImage to read data from 3.4.105 kernel.
Fourth step (in /tmp): od -A d -t x1 vmlinuz-... | grep '1f 8b 08 00′
(Should be...) 17408+4->17412.
Fifth step: dd if=vmlinuz-... bs=1 skip=17412 | zcat > vmlinux.
Sixth step: gzip -v9 vmlinux -> vmlinux.gz
Seventh step: mkimage -A arm -O linux -T kernel -C gzip -a 0x40008000 -e 0x40008000 -n 'Linux kernel' -d vmlinux.gz uImage.
Eighth step: Copy new generated uImage back from /tmp to /boot.
Nineth step: Reboot, hope and pray ...
root@cubietruck:~# uname -r
3.4.107-cubietruck
Zitat von: Wuppi68 am 01 Mai 2015, 19:03:28
kannst Du grob die Lösung hier reinschreiben?
Kann ich schon, aber wirklich nur grob. Bei mir lautete der Befehl:
mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d vmlinuz-3.4.107-cubietruck uImage > /dev/null 2>&1
Edit: Sehe gerade, das war Seventh Step von stromer-12
vmlinuz-3.4.107-cubietruck uImage kommt aus Igors deb für diesen Kernel
Dann einfach das generierte uImage auf /dev/nand1 kopieren.
BTW: Logitechmediaplayer läuft irgendwie trotzdem nicht mehr. Und TTS läuft jetzt nur noch, wenn mplayer durch mplayer2 ersetzt wurde.
Heute wollte ich es auch ausprobieren ;)
Bin nach der Anleitung von Igors-Seite vorgegangen, lief alles problemlos.
sudo apt-get install u-boot-tools
mkdir ~/tmp
cd ~/tmp
mkdir kernel3.4.107
cd kernel3.4.107
wget http://mirror.igorpecovnik.com/kernel/3.4.107-cubietruck-default.tar
tar xvf 3.4.107-cubietruck-default.tar
sudo dpkg -i *.debDa ich von einem alten Kernel (3.4.98 im uImage-Format) kam, waren noch zusätzliche Schritte nötig:
ZitatAditional step if you update kernel on older image?
If you came from image that doesn't have boot scripts (/boot/boot.scr) you will need to create one – Create /boot/boot.cmd file:
sudo nano /boot/boot.cmdund folgendes einfügen:
setenv bootargs console=tty1 root=/dev/mmcblk0p1 rootwait consoleblank=0
if ext4load mmc 0 0x00000000 /boot/.next
then
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile}
ext4load mmc 0 0x46000000 /boot/zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
else
ext4load mmc 0 0x43000000 /boot/script.bin
ext4load mmc 0 0x48000000 /boot/zImage
bootz 0x48000000
fi
und umwandeln:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scrdas wars, neu booten.
alex@cubie ~ $ uname -a
Linux cubie 3.4.107-cubietruck #14 SMP PREEMPT Wed Apr 29 11:57:42 CEST 2015 armv7l GNU/Linux
Läuft alles (bis jetzt) problemlos.
Zitat von: hexenmeister am 02 Mai 2015, 22:53:14
Da ich von einem alten Kernel (3.4.98 im uImage-Format) kam, waren noch zusätzliche Schritte nötig
welches sind denn die alten Kernel im uImage-Format..?
wenn ich mal schaue sieht das bei mir so aus: 3.4.101-sun7i+
Ich hatte noch 3.4.98. Ich habe die Beschreibung auf der Igors Seite so verstanden, dass mit 'alt' uImage-Format gemeint war. Der neue Kernel liegt als zImage vor. Schaue mal nach, was Du im /boot Verzeichnis vorfindest.
Mein altes Image war im uImage-Format. Deshalb habe ich den oben genannten Befehl ausgeführt und damit aus dem zImage ein uImage gemacht, dieses dann 1:1 auf /dev/nand1 kopiert. Alles andere bleibt in /dev/nand1 wie es ist. Sicherheitshalber aber vorher eine Kopie des alten uImage anlegen. Ich hatte den gesamten Inhalt von /dev/nand1 gesichert auf die SSD. Und mit der Start-SD-Card der allerersten Installation konnte ich dann jederzeit wieder den alten Inhalt zurück kopieren.
Zum Kopieren in /dev/nand1 muss dieses gemountet werden , z.B. auf /mnt mit
mount /dev/nand1 /mnt
Mein "Schlüssel zum Glück" war letztendlich dieser Hinweis:
http://www.igorpecovnik.com/2013/12/24/cubietruck-debian-wheezy-sd-card-image/comment-page-5/#comment-5897 (http://www.igorpecovnik.com/2013/12/24/cubietruck-debian-wheezy-sd-card-image/comment-page-5/#comment-5897)
Was sich unter /boot befindet, hat bei mir absolut nichts zu sagen, wie ich festgestellt habe. Es wird ausschließlich aus der SD-Karte oder von /dev/nand1 gestartet.
ich frage deshalb weil ich ein Update von Fhem gemacht habe und bekomme einige Fehler und mein Fhem startet nicht mehr.
Das blöde ist ich bin nicht zuhause und habe das Update aus der Ferne gemacht und nun sit mein "Fhem not running", ich bekomme es grad nicht mehr zum starten und einige Fehler Anzeigen.
Drauf komme ich noch mit putty und mit dem Filezilla, dass wars aber auch.
Ich dachte mir das ich ein Backup zuück spiele aber momentan klappt auch das nicht, er meckert mir einige Module an.
Stehen bleibt er so und geht nicht weiter, wenn ich den Befehl:
/etc/init.d/fhem start absetze
root@cubie:~# /etc/init.d/fhem start
Starting fhem...
Daemon with PID 2498 started!
Can't bind socket: Address already in use
root@cubie:~# Smartmatch is experimental at ./FHEM/98_RandomTimer.pm line 251, <$fh> line 63.
Smartmatch is experimental at ./FHEM/98_RandomTimer.pm line 255, <$fh> line 63.
given is experimental at ./FHEM/55_GDS.pm line 172, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 173, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 178, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 183, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 195, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 201, <$fh> line 77.
given is experimental at ./FHEM/55_GDS.pm line 247, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 249, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 255, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 261, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 267, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 274, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 279, <$fh> line 77.
given is experimental at ./FHEM/55_GDS.pm line 280, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 281, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 282, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 283, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 289, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 312, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 317, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 322, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 329, <$fh> line 77.
given is experimental at ./FHEM/55_GDS.pm line 354, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 355, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 359, <$fh> line 77.
given is experimental at ./FHEM/55_GDS.pm line 905, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 907, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 914, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 921, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 928, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 938, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 945, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 952, <$fh> line 77.
when is experimental at ./FHEM/55_GDS.pm line 960, <$fh> line 77.
push on reference is experimental at ./FHEM/00_LOGO.pm line 514, <$fh> line 132.
perl: symbol lookup error: /usr/local/lib/snap7p.so: undefined symbol: Perl_gv_init
Da würde ich an Deiner Stelle mal unter /opt/fhem/RestoreDir suchen, ob es von den betreffenden Files vielleicht eine Vorversion gibt. Denke nicht, dass es am Kernel liegt. Gestern hat mein FHEM-Update auch mit einer seltsamen Fehlermeldung abgebrochen. Nach der Odyssee letzte Woche hatte ich aber keine Lust darauf und habe alles beim alten gelassen. Auch das update check hört irgendie einfach so auf:
List of new / modified files since last update:
UPD FHEM/00_SONOS.pm
UPD FHEM/10_ZWave.pm
UPD FHEM/21_OWAD.pm
UPD FHEM/21_OWCOUNT.pm
UPD FHEM/21_OWMULTI.pm
UPD FHEM/21_OWSWITCH.pm
UPD FHEM/46_TRX_SECURITY.pm
UPD FHEM/91_eventTypes.pm
UPD FHEM/98_Heating_Control.pm
UPD FHEM/98_UbiquitiMP.pm
UPD FHEM/98_WeekdayTimer.pm
UPD www/gplot/SM_CPUTemp.gplot
UPD www/gplot/SVG_01_Garden.gplot
UPD www/gplot/SVG_02_Cellar.gplot
UPD www/gplot/SVG_03_Dewpoint.gplot
UPD www/gplot/temp4rain10.gplot
da gibt es einige Module, aber die haben damit nichts zutun.
Ich habe schon ein komplettes Fhem Update eingespielt aber er bleibt immer wieder damit stehen
root@cubie:/# push on reference is experimental at ./FHEM/00_LOGO.pm line 514, <$fh> line 132.
perl: symbol lookup error: /usr/local/lib/snap7p.so: undefined symbol: Perl_gv_init
/etc/init.d/fhem status
fhem is not running
ich würde das ja gerne richten, aber ich weiß nicht wie.
Wichtig ist das mir überhaupt erst einmal Fhem wieder startet, damit heute Abend alles wieder funktioniert, Licht Rollläden.
Aber ich bekomme es nicht zum starten, weiß jemand Rat..?
so damit fhem erst mal wieder läuft habe ich jetzt folgendes gemacht...!
Das 00_Logo.pm gelöscht dann den Server gestartet und das Modul wieder eingefügt, somit ist Fhem erst mal wieder am laufen... Puuh was bin ich mal froh ;)
Das Lodo Modul läuft nicht.
fheminfo:
ZitatFhem info:
Release : 5.6
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.20.2
uniqueID : d2e1c0f2022cddbf7cd6ff8672bbadf7
Hallo Zusammen,
ähnliche Probleme bei mir , habe aber schon 3.4.105 drauf gehabt (war im 3.2 wheezy Image ).
Habe einfach sudo apt-get update && sudo apt-get dist-upgrade gemacht und wohl einige Fragen falsch beantwortet :(
Danach lief nix mehr , kein ssh , kein samba, Apache, und owncloud.
ssh wurde scheinbar disabled ? (keine Ahnung)
im Apache2 gabs dann in der conf (zeile 89) ein Problem .......
Ich vermute mal das hier von Debian 7 auf 8 upgedatet wurde und da ist ja einiges neu (systemctl).
Auch Perl wurde auf v5.20.2 gezogen ?
Momentan läuft das wieder , muß das aber alles nochmal prüfen >:(
klaus
Zitat von: kvo1 am 05 Mai 2015, 00:17:37
...Ich vermute mal das hier von Debian 7 auf 8 upgedatet wurde und da ist ja einiges neu (systemctl)...
Solange Du Deine sources.list nicht änderst (und darin noch wheezy steht), kommst Du auch mit einem dist-upgrade nicht von Debian 7 auf 8.
Zitat von: Hollo am 05 Mai 2015, 20:12:12
Solange Du Deine sources.list nicht änderst (und darin noch wheezy steht), kommst Du auch mit einem dist-upgrade nicht von Debian 7 auf 8.
kleiner Nachtrag aus einem anderem Beitrag (http://forum.fhem.de/index.php/topic,36673.msg289616.html#msg289616):
ZitatSolange Du Deine sources.list nicht änderst (und darin noch wheezy steht), kommst Du auch mit einem dist-upgrade nicht von Debian 7 auf 8.
da habe ich definitiv nix geändert. Aber durch das
sudo apt-get update && sudo apt-get dist-upgrade und die wohl falsche Antworten meinerseits gab es
halt diese Probleme.
Scheint als wäre das hier von "SysVinit" auf "systemd" umgestellt.......
wenn ich z.B. Samba starte
/etc/init.d/samba start[ ok ] Starting nmbd (via systemctl): nmbd.service.
[ ok ] Starting smbd (via systemctl): smbd.service.
[ ok ] Starting samba-ad-dc (via systemctl): samba-ad-dc.service.
Das deutet doch auch systemd hin !?
Was steht denn in Deiner sources.list ?
Zitat von: Hollo am 06 Mai 2015, 09:13:04
Was steht denn in Deiner sources.list ?
deb http://ftp.de.debian.org/debian stable main contrib non-free
deb-src http://ftp.de.debian.org/debian stable main contrib non-free
deb http://ftp.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
deb http://debian.fhem.de/stable ./der letzte Eintrag war für die fhem-(Neu-)Installation (gemäß damaliger Angabe von Betateilchen) , hat auch funktioniert!
Wobei das ab 1.3.15 dann auf https umgestellt wurde !
Deshalb habe ich ja immer geschrieben "und darin noch wheezy steht". ;)
Du hast aber "stable" drin, und das ist neuerdings jessie.
Daher hast Du Dir mit dem dist-upgrade auch schön Dein Debian auf Jessie aktualisiert.
An Deiner Stelle solltest Du nun die restlichen Einträge auch von wheezy auf jessie ändern.
Anschließend zur Sicherheit nochmal apt-get update && apt-get dist-upgrade durchlaufen lassen.
Und dann halt gucken, wo es hakt.
Oder Backup einspielen und im ersten Eintrag statt stable ein wheezy eintragen.
Dann kannst Du Dir in Ruhe die Upgrade-Hinweise ansehen, bevor Du das Upgrade machst.
Ein Misch-Masch mag ich nicht, daher habe ich bei allen Einträgen definiert das Release und nicht den Zweig (stable, testing, ...) drin.
Hallo Hollo,
Danke für die Info und Deine Anteilnahme ;)
ZitatDu hast aber "stable" drin, und das ist neuerdings jessie.
Na ja , ich hab daran nix geändert , kommt wohl mit dem Image so !
ZitatAn Deiner Stelle solltest Du nun die restlichen Einträge auch von wheezy auf jessie ändern
Du meinst so .....
deb http://ftp.de.debian.org/debian stable main contrib non-free
deb-src http://ftp.de.debian.org/debian stable main contrib non-free
deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
deb http://debian.fhem.de/stable ./ZitatOder Backup einspielen und im ersten Eintrag statt stable ein wheezy eintragen.
Fehlanzeige , gab es (leider noch) nicht .... ja ja schon klar ... :'( :'( :'(
ZitatEin Misch-Masch mag ich nicht, daher habe ich bei allen Einträgen definiert das Release und nicht den Zweig (stable, testing, ...) drin.
und das schaut dann wie aus ?
Und anstatt stable auch jessie!
Sonst bekommst Du irgendwann wieder die Probleme ....
Bin ja mittlerweise raus, da mein Problem gelöst ist. Aber:
Zwischenzeitlich geht es nicht mehr um den Cubie (wie der Titel sagt) sondern um den Raspberry Pi, sehe ich das richtig?
Die letzten Beiträger waren eher allgemein, d.h. für viele Debian-Systeme geeignet
Zitat von: duke-f am 06 Mai 2015, 13:08:49
Bin ja mittlerweise raus, da mein Problem gelöst ist. Aber:
Zwischenzeitlich geht es nicht mehr um den Cubie (wie der Titel sagt) sondern um den Raspberry Pi, sehe ich das richtig?
doch , doch es geht mir schon um den cubie (der fehlt nur in meiner Signatur) !
Aber wie Wernieman schon sagt , ist das vl. auch für rpi zutreffend !
Zitat von: Wernieman am 06 Mai 2015, 13:00:49
Und anstatt stable auch jessie!
Sonst bekommst Du irgendwann wieder die Probleme ....
@Wernieman
danke für den Hinweis !
PS:
ich muss mich mit dem apt - Thema mal genauer befassen :-[
Ich häng mich mal dran.
Angefangen hat es harmlos:
apt-get update
apt-get upgrade
=> einige Programme meckerten wegen fehlender locales Einstellungen
apt-get dist-upgrade
Jetzt habe ich Kernel 3.4.104
Debian 8.0
ein laufendes fhem
Und keine Soundausgabe mehr :(
Rince , willkommen in CLub !
bzgl. Sound kann ich leider nichts sagen , habe ich bisher auf dem CUBIE nicht genutzt !
Der Rest war schon mal übel genug , bin froh das es halbwegs wieder läuft !
Zitat von: Rince am 19 Mai 2015, 22:18:55
Und keine Soundausgabe mehr :(
Ich musste nach dem upgrade auf 3.4.107 mplayer durch mplayer2 ersetzen
Du meinst in den perl Modulen von fhem?
Nein, per apt-get install
Cool.
Das funktioniert. Danke :)
Dafür geht der LogitechMediaServer nimmer...
*seufz*
Freut mich, auch mal wieder wo helfen zu können. ;D
Aber genau das Problem mit dem LMS habe ich auch - und noch nicht lösen können.
So wie es aussieht läuft der 7.8.1 nicht mehr mit der neuen Perl-Version.
Ich versuche mal das
http://forums.openmediavault.org/index.php/Thread/4273-Logitechmediaserver-how-to-install/?postID=36624#post36624
mit der nightly von 7.9
http://downloads.slimdevices.com/nightly/?ver=7.9
Zumindest komme ich wieder auf das Webinterface :)
Habe den alten mit apt-get remove logitechmediaserver deinstalliert. Ob das schlau/dumm war, weiß ich nicht.
Jedenfalls:
mkdir ~/scratch/lms -p
cd ~/scratch/lms
wget http://downloads.slimdevices.com/nightly/7.9/sc/50ba429/logitechmediaserver_7.9.0~1431440256_all.deb
dpkg -i logitechmediaserver_7.9.0~1431440256_all.deb
apt-get -f install
cd
rm -r ~/scratch/lms
Scheint zu klappen :)
Bin neugierig, ob das dann geht. Dachte schon ich bin einfach zu blöd. Hab jetzt mein LMS auf das NAS verschoben - da kann ich aber den Default-Skin nicht mehr per iframe in FHEM einbinden.
ZitatAber genau das Problem mit dem LMS habe ich auch - und noch nicht lösen können.
Da habe ich auch und bisher auch noch nicht gelöst, bin ganz gespannt ob Du das hin bekommst !
Also ich behaupte mal, dass es prinzipiell geht.
Meine Einstellungen im LMS blieben erhalten (Pfade und so)
Fhem findet den Server (auch wenn die Readings im Moment merkwürdig sind, da steht nix drin, aber vielleicht gibt sich das noch)
Dann kann ich über das SB_Client Device die Lautstärke verändern und auch die Wiedergabe stoppen. Mehr hab ich noch nicht versucht.
Hast Du sonst irgendwelche lib´s installiert oder sym.links angelegt .... wie hier beschrieben ...
http://allthingspi.webspace.virginmedia.com/lms.php (http://allthingspi.webspace.virginmedia.com/lms.php)
Nö, habe ich nicht. Jedenfalls nicht gestern Nacht.
Wenn der LMS früher schon mal lief, kann ich den obigen Weg empfehlen.
PS:
Deine verlinkte Anleitung ist aus dem Jahr 2012!
ZitatWenn der LMS früher schon mal lief, kann ich den obigen Weg empfehlen.
Nein lief bisher bei mir noch nicht auf dem CUBIE (nur NAS) , soll ja "umziehen"
ZitatPS:
Deine verlinkte Anleitung ist aus dem Jahr 2012
mag sein , aber z.b. für´n RPI klappt das danach immer noch , man muss nur die LMS Version anpassen!
PS:
vielleicht geh ich einfach mal auf dem Cubie wie von Dir beschrieben vor !
Na, mehr wie nicht laufen kann es nicht. Und im Zweifel kannst du ihn auch wieder entfernen ;)
Ich such mal die Anleitung, nach der ich damals das Ding aufgesetzt hatte.
Hui, SqueezeLite am Cubietruck mit Debian 8:
Hier ist das HowTo:
apt-get install sqeezelite
8)
Schon taucht das Teil in fhem unter den SB_Playern auf :)
Noch einfacher geht es nicht. Cool, dass es mittlerweile im Repository ist :)
ZitatNa, mehr wie nicht laufen kann es nicht. Und im Zweifel kannst du ihn auch wieder entfernen ;)
so die Theorie ;)
ZitatIch such mal die Anleitung, nach der ich damals das Ding aufgesetzt hatte
Ja danke ,das wäre nett !
ZitatHui, SqueezLite am Cubietruck mit Debian 8:
die Player selbst wird ich auf div. anderen Geräte installieren , RPI´s , Andriod - Tablet etc !
Danke das Du das hier alles teilst !
ZitatDanke das Du das hier alles teilst !
Nicht nötig. Genau genommen geht der Thread grade furchtbar OT :(
Und ich bin schuld :(
ZitatIch such mal die Anleitung, nach der ich damals das Ding aufgesetzt hatte
Sorry, ich finde es nicht.
Mach einfach mal wie oben beschrieben.
so da ich nun 4 Wochen weg war und nun wieder daheim bin, kann es bei mir auch wieder losgehen.
Der Cubie hatte ja bei mir nach einem Update vollends die Grätsche gemacht und es läuft mein Logo Modul nicht mehr mit der aktuellen Version, es fehlen wohl noch ein paar Pakete die upzudaten sind.
Die letzten 4 Wochen war ich nun erst einmal zufrieden das Fhem überhaupt wieder lief, ich mußte nur das Logo Modul raus nehmen und danach lief fhem wieder, vorher immer nur "not running". Liegt wohl auch etwas an der Perl Version die mit dem Update kam.
Ich denke ich muss jetzt nach einem vernünftigen Schema vorgehen das Ding zu einem gut laufenden Jessie zu bewegen.
EDITH://
Als erstes frage ich mich warum Jessie, weil es der neue Standard Kernel ist..?
Das wheezy hat Igor doch auch noch auf seiner Seite..!
Ich habe zumindest erst einmal ein Update mittels
Zitatapt-get update && apt-get dist-upgrade
gemacht.
Fhem läuft bisher.
Da ich zwei Systeme habe hatte ich das vorher auf meinem Testsystem probiert, was mich nun wundert mein Testsystem
Cubietruck sieht so aus:
ZitatKernel version: 3.4.105-sunxi #2 SMP PREEMPT Tue Dec 23 07:55:25 CET 2014
und mein Produktivsystem sieht so aus:
ZitatKernel version: 3.4.101-sun7i+ #1 SMP PREEMPT Fri Aug 1 21:58:48 CEST 2014
Beide habe ich heute aktualisiert, kann mir jemand was dazu sagen..? :-\
Bist Du Dir sicher, das apt-get nach "apt-get update" nicht "gemeckert" hat?
Ich gweiß momentan die Fehlermeldung nicht auswendig, aber irgendetwas mit "fehlenden Zertifikaten" ...
Zitat von: Wernieman am 29 Mai 2015, 07:59:25
Bist Du Dir sicher, das apt-get nach "apt-get update" nicht "gemeckert" hat?
mmh, sicher nicht ;)
ich habe noch soviel gebastelt gestern und habe mal mein Testsystem komplett neu aufgesetzt, ich weiß jetzt leider nicht mehr genau was ich alles probiert habe.
Ich habe aber diese Anzeigen wie hier im Betrag im 1. Post bekommen.
Preparing to unpack .../archives/udev_215-17_armhf.deb ...
Since release 198, udev requires support for the following features in
the running kernel:
- inotify(2) (CONFIG_INOTIFY_USER)
- signalfd(2) (CONFIG_SIGNALFD)
- accept4(2)
- open_by_handle_at(2) (CONFIG_FHANDLE)
- timerfd_create(2) (CONFIG_TIMERFD)
- epoll_create(2) (CONFIG_EPOLL)
Please upgrade your kernel before or while upgrading udev.
AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.
There is always a safer way to upgrade, do not try this unless you
understand what you are doing!
dpkg: error processing archive /var/cache/apt/archives/udev_215-17_armhf.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Errors were encountered while processing:
/var/cache/apt/archives/udev_215-17_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@cubie:~#ich habe dann auf meinem Testsystem ein wheezy installiert in dieser Version "Cubietruck_Debian_3.0_wheezy_3.4.105"
weil ich hier noch die vorgehensweise kenne wie ich es ins Nand installiere und anschl. alles auf die SSD schiebe.
Das geht mit einer neueren Version irgendwie nicht so einfach, habe aber auch nur ein Versuch gemacht und es nicht hinbekommen, dazu hier der Beitrag (http://forum.fhem.de/index.php/topic,37606.msg298806.html#msg298806)
OK, ich habe aber nach der Beschreibung auf der Seite von Igor versucht dieses neue System auf jessie upzudaten aber auch das hat nicht geklappt, obwohl ich es nach dieser Beschreibung gemacht habe.
ZitatHow to upgrade from Debian Wheezy to Debian Jessie?
dpkg -r ramlog
cp /etc/apt/sources.list{,.bak}
sed -i -e 's/ \(stable\|wheezy\)/ jessie/ig' /etc/apt/sources.list
apt-get update
apt-get --download-only dist-upgrade
apt-get dist-upgrade
mit uname -r bekomme ich danach immer noch die "3.4.105-sunxi" Version angezeigt.
Eigentlich sollte es aber die neue Jessie sein..! :-\
Ich bin jetzt nicht so der Linuxfreak und halte mich da nur an die Installationsempfehlungen, aber das macht wohl nicht was es soll ;)
Ich habe jetzt nichts weiter mit Fhem und Perl gemacht solange ich auf der Linux Ebene nicht weiter komme.
Wechseln wollte ich weil ich mit meinem Logo Modul Probleme hatte mit der wheezy/Perl Version und der Modulersteller leider nicht weiter helfen konnte.
Es gibt ja die neue Perl Version v5.20.2 die wohl etwas Probleme macht mit einigen Modulen, zumindest mit meinem 00_Logo.pm und er zeigt mit auch noch Fehler bei dem RSS- an und bei dem GDS Modul
Nachtrag:
so da ich nun nochmal ein Update mit "apt-get update && apt-get dist-upgrade" gestartet habe bekomme ich folgende Meldungen...
Ich soll also wohl erst einmal den Kernel updaten...!
The following NEW packages will be installed:
acl cpp-4.9 g++-4.9 gcc-4.9 init iproute2 libasan1 libasound2-data libatomic1 libboost-iostreams1.55.0
libcap2-bin libcloog-isl4 libcryptsetup4 libdebconfclient0 libdns-export100 libestr0 libgcc-4.9-dev
libgnutls-deb0-28 libgnutls-openssl27 libgraphite2-3 libharfbuzz0b libhogweed2 libicu52 libio-html-perl
libirs-export91 libisc-export95 libisccfg-export90 libisl10 libjson-c2 liblogging-stdlog0 liblognorm1
libmpc3 libmspack0 libnettle4 libnl-route-3-200 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0
libpangox-1.0-0 libpangoxft-1.0-0 libparted2 libpsl0 librtmp1 libsasl2-modules-db libstdc++-4.9-dev
libtasn1-6 libubsan0 libxext6 libxtables10 openssh-sftp-server systemd systemd-sysv
The following packages will be upgraded:
alsa-utils apt apt-utils aptitude aptitude-common base-passwd build-essential cabextract cpp cron curl
dmsetup g++ gcc hostapd iproute iptables iputils-ping isc-dhcp-client isc-dhcp-common libapt-pkg4.12
libasound2 libbluetooth-dev libbluetooth3 libcairo2 libcurl3 libcurl3-gnutls libcwidget3
libdevmapper1.02.1 libept1.4.12 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libhttp-message-perl
libldap-2.4-2 libp11-kit0 libpam-modules libpam-modules-bin libpango1.0-0 librsvg2-2 librsvg2-common
libsasl2-2 libsemanage-common libsemanage1 libssh2-1 libusb-1.0-0 libusb-1.0-0-dev libxapian22 login
mount ntfs-3g openssh-client openssh-server parted passwd rsyslog sudo sysvinit udev wget
59 upgraded, 52 newly installed, 0 to remove and 0 not upgraded.
14 not fully installed or removed.
Need to get 0 B/55,6 MB of archives.
After this operation, 107 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Extracting templates from packages: 100%
Preconfiguring packages ...
Setting up libpam0g:armhf (1.1.8-3.1) ...
Processing triggers for libc-bin (2.19-18) ...
(Reading database ... 22626 files and directories currently installed.)
Preparing to unpack .../archives/udev_215-17_armhf.deb ...
Since release 198, udev requires support for the following features in
the running kernel:
- inotify(2) (CONFIG_INOTIFY_USER)
- signalfd(2) (CONFIG_SIGNALFD)
- accept4(2)
- open_by_handle_at(2) (CONFIG_FHANDLE)
- timerfd_create(2) (CONFIG_TIMERFD)
- epoll_create(2) (CONFIG_EPOLL)
Please upgrade your kernel before or while upgrading udev.
AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.
There is always a safer way to upgrade, do not try this unless you
understand what you are doing!
dpkg: error processing archive /var/cache/apt/archives/udev_215-17_armhf.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Errors were encountered while processing:
/var/cache/apt/archives/udev_215-17_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@cubie:~#
frage mich bitte nicht, wie man auf einem Cubie den Kerne upgradet. Das ist kein Linux, sondern ein Cubie "Problem" :-\
Zitat von: Wernieman am 29 Mai 2015, 13:26:17
frage mich bitte nicht, wie man auf einem Cubie den Kerne upgradet. Das ist kein Linux, sondern ein Cubie "Problem" :-\
;) :D
is schon OK..
gibt es ja auf der Igorseite auch, aber ich weiß nicht auf welchen Kernel ich da updaten soll, denn der Kernel scheint mir etwas komisch der dort angegeben wird...! :-\ ich arbeite das erst einmal auf meinem Testsystem ab mal sehen ob ich da zum Erfolg komme... :-\
Ich bin ja nicht der einzige der ein Cubie hat ;)
Das sieht bei Igor so aus:
ZitatHow to update kernel?
First you need to download a proper kernel tar pack located at the end of board download section (Kernel, U-boot, DTB). This example is for Cubietruck but it's the same for all other boards – just grab a kernel pack for board of your choice.
mkdir 3.19.6
cd 3.19.6
wget http://mirror.igorpecovnik.com/kernel/3.19.6-cubietruck-next.tar
tar xvf 3.19.6-cubietruck-next.tar
dpkg -i linux-image*.deb
Optional:
dpkg -i linux-headers*.deb
Create some temporary directory
Go into it
Grab a kernel pack
Install at least linux-image
If pack refuses to install, uninstall it and try again.
Reboot.
aber das mache ich erst mal nicht, weil ich damit keinerlei Erfahrung habe
Es doch "praktisch" nur ein für den Cubie angepasstes Kernelimage?
Obwohl .. die Version wundert mich auch. mein Ubuntu (15.04) hat aktuell 3.19.0-18
Ein Tipp meinerseits: Gehe diesen Thread nochmal ganz von vorne durch. Genau Deine beschriebene Fehlermeldung war nämlich für mich der Anlass, diesen zu beginnen. Auch ich hatte nach einem apt-get upgrade die Meldung, dass "udev" nicht installiert werden könne und dass der Kernel geupdatet werden soll. Und genau das hat mir Probleme gemacht, da mein Kernel nicht mehr in dieser Form war, wie er jetzt auf Igor's Seite vorausgesetzt wurde.
Zitat von: duke-f am 29 Mai 2015, 14:35:48
Ein Tipp meinerseits: Gehe diesen Thread nochmal ganz von vorne durch.
ich habe das schon alles probiert und habe heute auf meinem Testsystem begonnen ein reines sauberes jessie zu installieren, mit dem Script von Igor.
Das hat heute nun geklappt und ich werde mich nun an die weitere Einrichtung machen. Danke ;)
Alles klar, ist sicher der beste Weg. Wollte auch nur zum Ausdruck bringen, dass das mit dem neuen Kernel eigentlich auch kein Hexenwerk ist.
Zitat von: duke-f am 29 Mai 2015, 18:52:19
Wollte auch nur zum Ausdruck bringen, dass das mit dem neuen Kernel eigentlich auch kein Hexenwerk ist.
;) super
Hallo,
habe ein Problem mit meinem cubi nach apt-get Upgrade! brauche eure Hilfe
Errors were encountered while processing:
/var/cache/apt/archives/udev_215-17_armhf.deb
bin nach der Anleitung von @hexenmeister vorgegangen um einen neuen Kernel zu Installieren
sudo apt-get install u-boot-tools
mkdir ~/tmp
cd ~/tmp
mkdir kernel3.4.107
cd kernel3.4.107
wget http://mirror.igorpecovnik.com/kernel/3.4.107-cubietruck-default.tar
tar xvf 3.4.107-cubietruck-default.tar
sudo dpkg -i *.deb
vmlinuz-3.4.107-cubietruck ist im boot Verzeichnis, nach einem Neustart ist noch immer der alte Kernel installiert!
Zitat
Aditional step if you update kernel on older image?
If you came from image that doesn't have boot scripts (/boot/boot.scr) you will need to create one – Create /boot/boot.cmd file:
sudo nano /boot/boot.cmd
und folgendes einfügen:
Code: [Auswählen]
setenv bootargs console=tty1 root=/dev/mmcblk0p1 rootwait consoleblank=0
if ext4load mmc 0 0x00000000 /boot/.next
then
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile}
ext4load mmc 0 0x46000000 /boot/zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
else
ext4load mmc 0 0x43000000 /boot/script.bin
ext4load mmc 0 0x48000000 /boot/zImage
bootz 0x48000000
fi
was muss ich in der config änderen?! mein cubi ist auf der festplatte installiert nicht sd
Danke im voraus
gruß
john36
du hast genau das Problem was alle hier hatten mit dem udev...
Dazu mußt du dieses erst einmal bereinigen, ob du dir das antun möchtest, weiß ich nicht, es könnte durchaus sein das du dir dein Cubie schrottest...!
Ich habe mir ein sauberes Jessie auf meinem Testsystem installiert und fange grad an alles rüber zu ziehen...
Mir war dies zu heikel da ich nicht unbedingt ein Linux As bin, komme aber mit diversen Anleitungen gut zurecht.
Zu sagen wäre noch, dass du auch ein Kernel Update machen mußt... wenn du das alles gut beherrschst mach es...!
Sonst lass es so laufen
Zitat von: moonsorrox am 30 Mai 2015, 11:25:18
Dazu mußt du dieses erst einmal bereinigen, ob du dir das antun möchtest, weiß ich nicht, es könnte durchaus sein das du dir dein Cubie schrottest...!
Naja ;) Höchstend die Installatkion. Wenn man die Liste der Installierten Packages hat und die Backup von FHEM und sonstigen Konfigurationen / persönlichen Daten... Dann verliert auch eine komplette Neuinstallation ihren Schrecken. ;)
Mit dem udev-Problem kenne ich mich leide auch nicht aus. Reicht da nicht das Aktivieren des neuen Kernel?
Ansonsten fehlt doch genau die Aktivierung:
Zitat//and convert it to boot.scr with this command:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
mkimage muss man ggf. vorher installieren.
@hexenmeister
danke für die schnelle Antwort
nach dem
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
Created: Sat May 30 16:31:17 2015
Image Type: ARM Linux Script (uncompressed)
Data Size: 372 Bytes = 0.36 kB = 0.00 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 364 Bytes = 0.36 kB = 0.00 MB
In cd /boot
root@cubieez /boot > ls
System.map-3.4.107-cubietruck config-3.4.107-cubietruck
boot.cmd vmlinuz-3.4.107-cubietruck
boot.scr zImage
kernel ist trotzdem nicht installiert nach neustart
/mnt/uEnv.txt
console=tty0
extraargs=console=ttyS0,115200 hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:$
nand_root=/dev/sda1
was mache ich falsch!?
gruß
john36
Sieht alles doch recht gut aus. Was funkioniert nicht?
Was ist /mnt/uEnv.txt ?
Was liefert uname -r ?
@hexenmeister
uname -r
3.4.61+
/mnt/uEnv.txt
ist der boot.txt damit cubi von der festplatte startet und nicht sd karte
gruß
john36
Hm... OK. Dann bin ich leider überfragt.
Sieht irgendwie danach, dass /boot Verzeichnis nicht das Richtige wäre, wenn die entscheidende Scripte in /mnt liegen (ist mnt eine gute Wahl dafür?)... Evtl. müssten auch die boot.scr uws. auch dahin.
Fragen an die Linux-Profis: wie geht man hier am besten vor?
Es muss noch ein uImage für das alte System erstellen, da es mit uBoot startet.
... und bei mir musste ich das uImage nach nand1 kopieren, da von dort gebootet wird. Der Link auf /boot hat nicht so funktioniert wie ich dachte.
siehe hier:
http://forum.fhem.de/index.php/topic,36760.msg290967.html#msg290967 (http://forum.fhem.de/index.php/topic,36760.msg290967.html#msg290967)
@hexenmeister
ja ich hatte mich an das Kernelupdate nicht getraut...! und habe auch ewig mit uname -r die gleiche Anzeige 3.4.101-sun7i+
Dein supermodul sysmon ;) zeigt mir auch immer noch 26 Pakete an die ich aktualisieren soll, aber das geht eben nur über Kernelupdate...
Deshalb habe ich also mein Testsystem total neu aufgesetzt und dieses wird in Kürze mein Produktivsystem, alles andere ist mir zu viel mit Problemen verbunden die ich nicht lösen kann....! :-\
Zitat von: moonsorrox am 30 Mai 2015, 19:26:26
ja ich hatte mich an das Kernelupdate nicht getraut...!
Ich hatte ein 12 Stunden altes Image. Ein Mislingen wäre also nicht so wild. ;)
ZitatDeshalb habe ich also mein Testsystem total neu aufgesetzt und dieses wird in Kürze mein Produktivsystem, alles andere ist mir zu viel mit Problemen verbunden die ich nicht lösen kann....! :-\
Das ist immer eine gute Lösung. :)