Buildumgebung: freetz-linux

[PeterPawn]

Das fiel auch niemand auf, da scheinbar alle x86 nutzen.

Wieso das? Das wurde von mir von der ersten Version an so klargestellt: https://github.com/PeterPawn/YourFr...793ee93ec73f199d5d6bfa253ee1b382bdb0b67208R46 (Zeile 46 im Makefile) - sofern die passenden Compatibility-Files installiert sind, funktioniert die Übersetzung eines 32-Bit-Binaries ja auch unter einer 64-Bit-Umgebung.

Auf dem RasPi gibt es ja erst seit kurzem (wenn man's mit der Erdgeschichte vergleicht) ein 64-Bit-System - und das ist auch noch Beta: https://www.raspberrypi.org/forums/viewtopic.php?t=275370 - außer man wollte selbst eine andere Distribution (z.B. Fedora) an den RasPi anpassen. Dann ist man natürlich gekniffen, wenn Fedora den 32-Bit-Support komplett kippt - für einen "kleineren" RasPi (bis 4 GB RAM) braucht man eigentlich kein 64-Bit-System (und für 8 GB dank "Mapping" eigentlich auch nicht). Die Berichte, daß 64-Bit-Software dann tatsächlich schneller laufen würde als 32-Bit-Software, sind (solange es keine anderen plausiblen Gründe gibt) sicherlich erst mal sehr subjektiv geprägt - solange da keine 32-Bit-Programme auf einem 64-Bit-System ablaufen, braucht 64-Bit in allererster Linie mehr RAM (weil auch die Programme größer werden) und bringt (außer größerer Genauigkeit bei Berechnungen, die man aber auch "brauchen" muß, damit das etwas nutzt) nicht wirklich viel.

Ich übersetze üblicherweise auch nicht wirklich auf einem RasPi (das ist eben doch nur ein Einplatinenrechner und vergleichsweise lahm, daher kann man da nur etwas anwerfen und laufen lassen, dem man nicht zusehen will und wo man nicht mit den Füßen trampelt, wann das endlich fertig ist), den nehme ich nur gerne für "nachvollziehbare Builds" und für "Demonstrationen" - auch weil der eben einen Debian-Abkömmling benutzt (bei der Fixierung von Freetz auf Ubuntu und Co. - so ist das zumindest "ähnlich") und ich auf "richtigen Maschinen" doch überwiegend openSuse (oder wie das momentan auch gerade wieder heißen mag bzw. geschrieben wird - das ändert sich ja auch alle Nase lang) verwende.

So ein RasPi ist eben ein (zusätzlicher) Rechenknecht, den sich jeder (für 1/5 des UVP einer "großen" FRITZ!Box oder preiswerter als einen aktuellen FRITZ!WLAN-Repeater) anschaffen kann, auch wenn er sonst keine weiteren Ambitionen in dieser Richtung hat. Das ist (für manchen) sogar einfacher, als das in einer VM auf einem Windows-PC zu betreiben - oder auch in der WSL unter Windows (weil's den passenden Prozessor und eine passende Windows 10-Version braucht, damit die WSL überhaupt genutzt werden kann).

Für meinen RasPi 4 (ich habe noch ein, zwei ältere 3er hier am Laufen, manchmal auch mit Kodi (bzw. LibreElec) als Media-Center zur Wiedergabe von meinem Enigma2-Device) verwende ich für das Kompilieren/Testen von Freetz-Builds sogar ein gesondertes Image auf der SD-Card - das basiert auf Raspbian Full vom 26.09.2019. Dabei landen aber alle "Arbeitsdaten" auf einer per USB3 angebundenen (drehenden) 3,5"-HDD - das ist schneller (und dauerhaft sicherer) als irgendeine Speicherkarte. Aber ich käme (derzeit) nicht auf die Idee (auch weil der gar nicht so viel RAM hat), den mit einem 64-Bit-OS zu betreiben.

 

[fda89]

Ich fand die 16-Bit ISA Steckkarten auch blöd, das 5,25" Laufwerk war viel zu lang ^^

Architectures/ARM/Raspberry Pi - Fedora Project Wiki

fedoraproject.org

The Raspberry Pi 2/3 is now supported in in all stable Fedora releases. The new Raspberry Pi 3 B+ has initial support only in Fedora 28+

Aktuell ist Fedora 32 (2x im Jahr ne neue Version), das lief schon lange auf dem Pi3 (Minimum für aarch64). Beim 4er passt irgendwas mit den erweiterten Grafik-Features noch nicht optimal, ich hab da eh keinen Videoutput dran bzw Xserver drauf (Bootlog geht).
Ein komplettes Image würde ich damit auch nicht compileren, aber die host-"tools" zum flashen, was aber leider dies dtc mitbaut. Sinnvoll wenn man zB sonst keinen nativen Linux PC hat

 

[PeterPawn]

aber die host-"tools" zum flashen, was aber leider dies dtc mitbaut.

Das liegt nun wieder nur daran, wie das von @er13 mal eingebaut wurde in Freetz.

Insgesamt ist das mit dem "make tools" etwas unglücklich gelöst - bis hin zu den fehlenden Abhängigkeiten, wenn sich irgendwelche Quelltext-Pakete für diese Tools geändert haben und man eigentlich nicht "von vorne" bauen will. Zumindest in meinen Augen - aber hinterher ist man auch immer klüger, das will ich hier gar nicht unterschlagen/vergessen, wobei das "yourfritz-akc-host" da auch ausdrücklich ausgenommen sei, weil ich das von Beginn an anders gehandhabt hätte, denn da waren die entstehenden "Probleme" schon deutlich genug zu erkennen.

Weil mir das auch auf die Ketten ging, daß ich immer die kompletten Tools (inkl. irgendeiner BusyBox, die kein Mensch wirklich braucht) bauen sollte, wenn ich nur die beiden Programme aus den "squashfs-tools" brauchte, habe ich das letztens dann endlich mal umgestellt und etwas vereinfacht, so daß es besser (für meine Zwecke zumindest) paßt: https://github.com/PeterPawn/YourFreetz/tree/host-tools

==============================================================================

Wenn Dich hier das Bauen von "yourfritz-akc-host" stört, lasse doch im zugehörigen Makefile (https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yourfritz-akc-host/src/Makefile) die "$BINS" als Ziel weg bzw. ersetze sie einfach durch passende Shell-Skripte (die brauchen ja nichts weiter als ein "echo" und/oder passende Dummy-Files ausgeben), anstatt sie durch den Compiler erzeugen zu lassen - am besten noch in Abhängigkeit davon, ob da REPLACE_KERNEL gesetzt ist oder nicht.

Ist es das nicht, wird das ganze Zeug gar nicht gebraucht - und keiner merkt, daß die Shell-Skripte nur "Dummies" sind. Voraussetzung wäre natürlich auch, daß man den Teil in "make/linux/kernel.mk", der die damit zusammenhängenden Ziele auf Kernel > 3.10 (oder so ähnlich) reduziert, auch noch von "REPLACE_KERNEL" abhängig macht - ohne diese Einstellung braucht's diese Ziele auch nicht und ohne diese Ziele, wird das "extract" und/oder das "bin2asm" gar nicht erst aufgerufen.

So würde ich das zumindest als Erstes mal versuchen - ggf. muß man noch den Patch für das Kernel-Makefile anpassen (entsprechende Bedingungen ergänzen) bzw. auch einfach weglassen (https://github.com/Freetz-NG/freetz...3.10.73/170-avm_kernel_config.PeterPawn.patch) oder das ASM-File als Dummy ohne echten Inhalt erzeugen, so daß das aber doch gelinkt werden kann, falls aus irgendwelchen kruden Gründen das Target "$(obj)/vmlinux.lds" zum Build auserkoren wird.

Ist REPLACE_KERNEL tatsächlich gesetzt, kann/muß man halt ohnehin die richtigen Binaries bauen - das kann man aber sogar so machen, daß an die Stelle von "bin2asm" und "extract" (jeweils mit dem Präfix) zunächst mal auch nur ein Shell-Skript gesetzt wird, das aber keinen Fehlercode zurückgibt und auch keine Dummy-Files erstellt, sondern anhand der Freetz-Variablen erst mal entscheidet, ob die "richtigen" Versionen gebraucht werden und diese dann (quasi erst "bei Bedarf" - siehe der Thread zum "avm_kernel_config" irgendwo hier im IPPF) über den passenden Aufruf von "make" erstellen läßt - letztlich so ähnlich, wie sich "libtool" als Wrapper für den Linker verhält. Da spielt es dann - wenn man sie erst mal gebaut hat, weil man es mußte - auch keine Rolle mehr, wenn diese Binaries die als Wrapper genutzten Shell-Skripte von diesem Zeitpunkt an komplett ersetzen.

Ist aber alles "untested" und damit nur diverse Ideen/Optionen, wie man auf den Build dieser Teile verzichten kann, ohne das komplett über den Haufen zu werfen, was da bisher existiert. Diese Gedanken habe ich mir auch schon ein paar Mal gemacht - es hat mich bisher nur nicht dazu gebracht (einfach weil ich so selten solche Builds machen muß), das auch für meinen Fork entsprechend anzupassen - letztlich brauche ich für den Build meiner Binaries eigentlich gar keinen eigenen Kernel und das könnte (auch für meinen speziellen "use case") alles wieder raus.

 

[fda89]

@gismotro: Man kann keine 32bit Toolchain mit Freetz-Linux bauen, da

configure: error: cannot compute sizeof (long long)

Bitte in die nächste Version aufnehmen:

sudo apt-get install gcc-multilib g++-multilib

@PeterPawn:
host-tools branch: Ich kann nicht beurteilen ob das aufgenommen werden sollte, da ich davon zu wenig Ahnung hab. Sieht zumindest gut aus Eventuelle Folgeprobleme dadurch würden mich viel Zeit kosten. Der Vorteil von selbstgebauten Tools ist dass die Parameter klar sind, beim Host kann das wechselns, zb "tar" als binary oder aus der Busybox
Das ganze Problem von "make tools" ist nur meine Faulheit, ich hab mir nur das gemerkt und nicht die Namen der einzelnen Packages die benötigt werden. Daher steht das auch in manchen readmes so. Dazu beigetragen hat, dass bei manchen Tools das target auf "-host" endet, bei anderen nicht. Das System dahinter hab ich nicht verstanden, falls es eins gibt

Übrigens, für den Raspberry gibt es Fedora sogar noch als 32bit, da erst ab Pi3 64 bit unterstützt werden. Da ich erst vor kurzem meine VM neuaufsetzen musste, hab ich aufm Rasberry auch gleich aarch64 genommen, bevor die 32er wieder abgesägt wird. mir ist es eigentlich egal was da genau läuft, solang es läuft...
Ne mono-Soundkarte hat mich auch gereicht, wodurch das 2. Diskettenlaufwerk ganz reinpasste

HOST_CFLAGS_FORCE_32BIT_CODE=-m32 wird scheinbar von dtc-host, yourfritz-akc-host und fakeroot, wodruch man aarch wohl vergessen kann zum kompletten Bauen. Der Raspberry wurde von manchen sogar dazu genutzt, wie man ab und an in Foren lesen kann

 

[fda89]

Ich hab mir das alte Ubuntu 2014 genauer angeschaut.

freetz@freetz-linux:~/freetz-ng$ tools/freetz-version
fatal: unknown date format format:%Y%m%d
master--5d61c07

freetz@freetz-linux:~/freetz-ng$ tools/freetz-revision
fatal: unknown date format format:%Y-%m-%d
freetz-ng 17387M-5d61c07 devel

Im Freetz-Webif wird somit auch die Version nicht korrekt angezeigt

Dann hab ich versucht den 7490 7.2x kernel zu bauen, das geht auch nicht
In der Datei source/kernel/ref-vr9-7490_07.21/linux-3.10/avm/make/generated/genhdr-stub.make das Target $(__avm_uapi_install_targets)

$(__avm_uapi_install_targets): __uapi_install/%/: % %/Kbuild FORCE
       $(MAKE) $(hdr-inst)=./$(<:$(srctree)/%=%) \
               dst=./$(<:$(srctree)/$(src)/%=%) \
               gen=./$(<:$(srctree)/$(src)/include/%=include/generated/%)

Ich hab einfach das MAKE herausgelöscht und der kernel kann gebaut werden. $srctree sollte wohl nicht leer sein

 

[PeterPawn]

Das Datumsformat wird an "strftime()" übergeben (lt. Man-Page für "git-log") ... das ist üblicherweise eine Funktion in der C-Library. Welche das hier genau ist, hängt davon ab, ob statisch oder dynamisch gelinkt wurde ("git-log" ist üblicherweise ein Symlink auf "git" und steht in "/usr/libexec/git/...") und welche C-Library hier zum Einsatz kommt. Wer dann ein Format verwendet, was dermaßen von "externen Umständen" abhängig ist, der ist am Ende selbst schuld.

Warum jetzt bei Deiner Installation von Ubuntu 14.04 (?) die (eigentlich üblichen) Formatangaben nicht erkannt werden, müßte man halt ermitteln (https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html) - aber wenn man bei jedem Fehler desselben Kalibers immer gleich auf die nächste OS-Version wechseln wollte (mit dem Kernel hat das meist nur wenig zu tun, weil "strftime()" kein Syscall ist: https://www.kernel.org/doc/man-pages/), dann käme man nie zu Potte.

Wenn Du ermitteln willst, welche Formate das "strftime()" erkennt, kannst Du - sofern "git" und "vi" (bzw. "vim") dieselbe Library benutzen - das auch einfach mit einem "vi"-Aufruf testen. Dort kann man mittels

:put =strftime('<format>')

direkt die Ausgabe von "strftime()" in das gerade editierte File einfügen lassen (praktisch, wenn man in einer Datei automatische Zeitstempel verwenden will). Alles das, was da nicht geht, wird auch beim "git" nicht klappen - wobei die Meldung schon an sich erstaunlich ist, weil üblicherweise alle nicht erkannten "Variablen" beim "strftime()" einfach 1:1 in die Ausgabe kopiert werden.

Das läßt es schon wieder wahrscheinlicher erscheinen, daß da ein "git" zum Einsatz kommt/kam, was ein Problem hat - das kann von "alte Version" bis zu "behobener Bug" gehen ... normal ist es jedenfalls nicht.

Allerdings wurde die "--date=format:..."-Option tatsächlich auch erst mit Git 2.6.0 eingeführt: https://github.com/git/git/blob/53f...5e24978c/Documentation/RelNotes/2.6.0.txt#L16 ... wenn da also plötzlich ein Git < 2.6.0 eingesetzt wird (das erschien auch erst 2015), dann wäre das "Problem" schon geklärt. Aber alles das sollte - solange man nicht darauf abstellt, daß ggf. das "Standard-Repository" für diese Distribution dann nur eine alte und fehlerbehaftete "git"-Version bereithält - nichts direkt mit der Frage zu tun haben, ob man heute noch eine 14.04 LTS für einen Freetz-Build verwenden könne.

Wenn da irgendwelche neueren Dinge nicht funktionieren (weil selbst der POSIX.1-2017-Standard eben erst drei Jahre nach dem "Erscheinen" dieser OS-Version "verabschiedet" wurde), dann ist das allerdings nicht unerwartet ... nur ist man halt selbst schuld daran, wenn man so etwas (zumindest dann, wenn das unbewußt geschieht und man die Inkompatibilität nicht bewußt in Kauf nimmt oder gar provoziert) auch benutzt. Daß mein Röhrenradio keinen USB-Slot für die MP3-Wiedergabe vom Stick hat, wundert mich ja auch nicht wirklich - aber auch da bin ich schuld, wenn ich das von ihm (dem Röhrenradio) erwarten würde. Wenn es allerdings auch keinen MW-Sender mehr empfängt (gibt's da heute überhaupt noch Ausstrahlungen?), dann (und nur dann) mache ich selbstverständlich auch das Gerät dafür verantwortlich.

Wenn Du mit dem (originalen) Repo für 14.04 installiert hast: https://ubuntu.pkgs.org/14.04/ubuntu-main-i386/git-core_1.9.1-1_all.deb.html - dann hast Du wohl eine 1.9.1 von "git" erhalten. Da muß man sich dann eben ein passendes PPA suchen (es gibt eines) und dieses benutzen, um sich eine aktuelle Git-Version (oder zumindest eine halbwegs aktuelle) zu installieren.

EDIT:
Schon wegen: https://github.com/Freetz/freetz/commit/818f6ed5e1cb6f392939ed176e5eddba7334a5dd braucht es für Freetz eine Git-Version ab 2.15.0.

 

[fda89]

Das "neueste" Freetz-Linux von cinereos/silenttears, das von vielen wohl noch genutzt wurde: sourceforge.net/projects/freetz-linux/
Aber wie gesagt, nicht nur git macht Probleme. Wobei das nur "optisch" ist
Das mit dem Compilieren des Kernel ist schon schwieriger

 

[PeterPawn]

@fda89:
Gut, meine Aussage, daß man auch mit 14.04 noch Freetz benutzen können müßte, bezog sich natürlich auch auf eine Version, die regelmäßige Updates (aber eben kein "dist-upgrade") erhält - wenn jemand ein sechs Jahre altes Image benutzt, ohne das zunächst mal "auf Vordermann" zu bringen, ist demjenigen kaum zu helfen. Das ist in etwa so, wie den Windows 8.1-PC einzuschalten nach sechs Jahren und ohne Updates mit dem IE 8 im Internet spazieren zu gehen (oder meinetwegen auch "die Wellen des Internets zu reiten").

Ausgangspunkt war ja eigentlich die Frage, wie lange man eine VM mit Ubuntu benutzen kann, OHNE das System komplett neu aufsetzen zu müssen und da stehen die Chancen bei einer 20.04 LTS eben doch deutlich besser, als bei der 20.10 - auch wenn die im Moment erst einmal "aktueller" ist. Sie wird Mitte des nächsten Jahres in Rente gehen und dann gibt es noch keine neue LTS-Version. Zwar kann man meistens auch ein Update auf die nächste OS-Version machen (eben mit dem "apt-get dist-upgrade"), aber das macht tatsächlich nur dann Sinn, wenn man irgendwelche neuen Features aus der neuen "Distribution" auch benutzen will/muß.

Solange man seinen Freetz-Build nur anwerfen will, macht es auch ein (deutlich weniger aufwändiges) "apt-get upgrade", wobei beiden Varianten jeweils ein "apt-get update" vorausgehen sollte, um die Liste der Pakete für die Repositories zu aktualisieren. Und solange man nur "apt-get upgrade" machen WILL, fährt man mit einer LTS-Version i.d.R. deutlich günstiger - wenn man das Einrichten einer neuen VM nicht als Sport begreift, dem man regelmäßig frönen möchte.

 

[gismotro]

[....]
Solange man seinen Freetz-Build nur anwerfen will, macht es auch ein (deutlich weniger aufwändiges) "apt-get upgrade", wobei beiden Varianten jeweils ein "apt-get update" vorausgehen sollte, um die Liste der Pakete für die Repositories zu aktualisieren. Und solange man nur "apt-get upgrade" machen WILL, fährt man mit einer LTS-Version i.d.R. deutlich günstiger - wenn man das Einrichten einer neuen VM nicht als Sport begreift, dem man regelmäßig frönen möchte.

Also reicht Freetz-1.5.8 jetzt die nächsten Jahre ?

[...]
Bitte in die nächste Version aufnehmen:

sudo apt-get install gcc-multilib g++-multilib

gcc-multilib : Ist schon drin
g++-multilib : Bau ich mit ein wenn ich in 5 Jahren eine neue Version baue (Grins)

 

[PeterPawn]

Also reicht Freetz-1.5.8 jetzt die nächsten Jahre ?

Wenn das die Version ist, die auf 20.04 LTS basiert und sich Freetz keine neuen Abhängigkeiten einfallen läßt, die mit diesem System nicht mehr zu realisieren sind: (Deutliches) JA.

Und natürlich nur dann, wenn die Benutzer dieses Images immer selbst ihre Updates machen, bevor sie das nächste Image bauen, nachdem sie die VM längere Zeit nicht genutzt haben.

Wenn Du das übernehmen willst, sobald neue Versionen (von Paketen für die 20.04) erscheinen, dann müßtest/könntest Du eben dieses Image nehmen, die Updates machen lassen, es danach (Wartungsmodus) "verdichten" (sprich: die alten Sektoren, die keine aktuell genutzten Daten enthalten, erst "ausnullen" und dann entfernen lassen - nennt sich (iirc) "shrink" bei VMware) und dann wieder (ggf. komprimiert, ich habe keine Ahnung, wie/was Du da im Moment genau anbietest) bereitstellen.

 

[fda89]

Das UrFreetzLinux ist 14.04.4, nach updaten 14.04.6, und hat noch immer ein sehr altes git.
Für Freetz ist die aktuelle oder aktuelle LTS okay. Da wurde ja nicht viel konfiguriert was nachher Probleme beim Updaten machen könnte. Aber nur wenn man ab und an mal aktualisiert. Das werden wohl nur wenige machen. Wenn man sich Problemberichte in Foren anschaut, sind da sehr oft Screenshots der VM zu sehen. Dh es wird nicht mal eine Verbindung mit Putty ausgebaut um überhaupt etwas richtig zu sehen. Da kann man kein updaten erwarten
Daher find ich es ganz gut wenn Gismotro alle 6 Monate eine "neue Version" veröffentlicht die alle Updates hat

---

Ubuntu 14.04 mit dem aktuellsten make-3.81 aus dem Jahr 2006 kann 4 Kernel für FOS 7.2x nicht mehr bauen.

/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10/avm/make/generated/genhdr-stub.make:109: Target »__uapi_install//home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10/drivers/isdn/capi_oslib/include/uapi/avm/capi_oslib« passt nicht zum Target-Muster
make -rR -f /home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10/scripts/Makefile.headersinst obj= \
                dst= \
                gen=
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:35: Warnung: Die Befehle für das Ziel »kernel/bounds.s« werden überschrieben
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:35: Warnung: Alte Befehle für das Ziel »kernel/bounds.s« werden ignoriert
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:39: Warnung: Die Befehle für das Ziel »/include/generated/bounds.h« werden überschrieben
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:39: Warnung: Alte Befehle für das Ziel »/include/generated/bounds.h« werden ignoriert
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:81: Warnung: Die Befehle für das Ziel »arch/mips/kernel/asm-offsets.s« werden überschrieben
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:81: Warnung: Alte Befehle für das Ziel »arch/mips/kernel/asm-offsets.s« werden ignoriert
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:85: Warnung: Die Befehle für das Ziel »/include/generated/asm-offsets.h« werden überschrieben
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:85: Warnung: Alte Befehle für das Ziel »/include/generated/asm-offsets.h« werden ignoriert
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:98: Warnung: Die Befehle für das Ziel »missing-syscalls« werden überschrieben
/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10//Kbuild:98: Warnung: Alte Befehle für das Ziel »missing-syscalls« werden ignoriert
mkdir -p kernel/
/bin/sh: 1: Syntax error: ";" unexpected
make[4]: *** [kernel/bounds.s] Fehler 2
make[3]: *** [__uapi_install//home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10/drivers/isdn/capi_oslib/include/uapi/avm/capi_oslib] Fehler 2
make[2]: *** [__install_headers/drivers/isdn/capi_oslib] Fehler 2
make[2]: Verzeichnis »/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10« wird verlassen
make[1]: *** [headers_install] Fehler 2
make[1]: Verzeichnis »/home/freetz/freetz-ng/source/kernel/ref-vr9-7490_07.21/linux-3.10« wird verlassen

ERROR: Build failed.
make: *** [/home/freetz/freetz-ng/source/toolchain-mips_gcc-5.5.0_uClibc-1.0.15-nptl_kernel-3.10/linux-dev/3.10/include/linux/version.h] Fehler 1

Mit aus den Sourcen installiertem make-3.82 von 2010 gibts bei diesem Kernel der 7490 7.2x keine Probleme

 

[FischersFreetz]

Hallo,...
ich nutze Freetz-Linux-1.5.8-Ubuntu 20.04.01 LTS und habe etwas für mich "Seltsames" festgestellt:
Wenn ich mich direkt in der virtuellen Maschine anmelde, ist das Verzeichnis "/usr/sbin" nicht im $PATH enthalten.
Melde ich via putty an, dann finde ich das Verzeichnis "/usr/sbin" im $PATH.
(In den Einstellungen von putty konnte ich nichts Entsprechendes finden:
Category>Connections>Data>Environment variables enthält z.B. keinen Eintrag.)

• Wie lässt sich das erklären?
• Hat jemand einen Tipp, wie ich diese verwirrende Situation abstellen kann?

 

[blackstar]

Tip von
berndy2001

ldconfig siehe auch https://debianforum.de/forum/viewtopic.php?t=170288
brachte zumindest bei mirr denerwünschten Erfolg

 

[berndy2001]

Hintergrund ist wohl, dass binarys in sbin grundsätzlich für Administratoren vorgesehen sind. Siehe https://unix.stackexchange.com/ques...add-usr-local-sbin-usr-sbin-sbin-to-my-path-o
Will man nun als normaler User auf binarys (ohne direkte Pfadangabe) in sbin zugreifen, muss man zuerst sbin dem Pfad hinzufügen.

 

[FischersFreetz]

Danke für die Tipps. (Das Setzen einer passenden Pfad-Variable ist nicht mein eigentliches Problem hier bzw. jetzt.)

Ich möchte verstehen, warum sich bei den beiden Wegen der Anmeldung die Pfad-Variablen unterscheiden!

### Ameldung direkt in der VM
freetz@freetz-linux:~/freetz-ng$ echo $PATH
/usr/local/bin : /usr/bin : /bin : /usr/local/games : /usr/games : /snap/bin

### Ameldung via putty
freetz@freetz-linux:~/freetz-ng$ echo $PATH
/usr/local/sbin : /usr/local/bin : /usr/sbin : /usr/bin : /sbin : /bin : /usr/games : /snap/bin

...

 

[B612]

Das können unterschiedliche profile sein.

 

[FischersFreetz]

Was meinst du damit?

profile im Allgemeinen, so wie "Profile eben..."? oder​

profile im Spezielleren, so wie "~/.profile"?​

Welche profile meinst du?

 

[B612]

Ich weiß nur dass $PATH in den profile festgelegt werden. Welche das bei dir genau sind musst du mal suchen.

 

[FischersFreetz]

Danke, die Zusammenhänge verstehe und überblicke ich.
Ich möchte aber wissen, warum es diese beiden Situationen überhaupt gibt.

 

[rolex0815]

Disclaimer: Ich nutze diese Distribution nicht.

Es werden anscheinend unterschiedliche environments gesetzt, vermutlich liegt der Unterschied im Aufruf der Shell.
Siehe https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell.
Beim lokalen Login unterscheidet sich die Reihenfolge der Konfigurationsdateien für die Shell von der bei externem Login z.b. per ssh.
Suche also im Homeverzeichnis nach diesen Dateien und vergleiche die Inhalte.