zeroc
Anmeldungsdatum: 20. September 2008
Beiträge: 147
|
Hallo ubuntuusers, seit einigen Jahren kompiliere ich mir meine Lieblingsanwendungen. Dafür schreibe ich mir nen Script, aktualisiere damit svn oder git und installiere es. Da ich zu faul bin, verstehen zu wollen, wie man wirklich deb-Pakete bastelt, benutze ich seit Jahren schon ganz faul checkinstall. Mein Script übergibt automatisch Versions-Nummern, Beschreibungen, etc...läuft eigentlich reibungslos. Heute habe ich mir eine Kernel-Panik eingefangen: run-init: can't execute '/sbin/init': No such file or directory In der Konsole kamen genau bei diesem Script schon die ersten "No such file or directory" Meldungen. Danach ging nichts mehr. Alles was in /bin oder /sbin hätte gefunden werden müssen, war nicht mehr da. Ich hatte verfrüht einen Neustart gemacht und dann kamen die init Fehler. Ich habe ein paar Stunden, alle logfiles gecheckt und eigentlich gab es überhaupt fast nichts auffälliges(bis auf einige "Datei nicht gefunden Meldungen"...im Grunde recht viele, aber ansonsten gar nichts) Es gab wohl zeitgleich ein Live-Update. Keine Ahnung, wie das wirklich heißt. In diesen logs ist der früheste Eintrag für "no such file or directory" zu finden. Ich weiß nicht, was hier wirklich passiert ist. ich würde es gerne verstehen. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119 | #!/bin/sh
###settings
start="$(tput setab 2)make geany script$(tput sgr0)"
end="$(tput setab 2)END$(tput sgr0)"
d1=/home/zeroc/git/
#d3=/build01
d2=geany
dp2=geany-plugins
n1=geany
np2=geany-plugins
n2=2:1.39.0
n3=zeroc-ist
n4="-der-master."
jetzt=$(date +"%Y%m%d")
gitlink="https://github.com/geany/geany"
gitlink2="https://github.com/geany/geany-plugins"
branch=master
comp1="./autogen.sh"
comp2="./configure --disable-html-docs"
comp3="make -j2"
comp4="sudo make install"
comp5="sudo checkinstall"
#### gibt konflikte mit calf, daher ein bissl gebastel
comp6="sudo dpkg --force-all --install geany_1.3*"
comp7="rm -rf geany_1.3*"
comp8="./configure --enable-all-plugins"
echo;echo $start;echo
read -p "(f)ast c(a)ncel or (r)enew git repo " answer
case "$answer" in
f)
echo ""
echo update $d1$d2 && cd $d1$d2 && git remote update && git pull && git submodule update --init --recursive && echo
$comp2
$comp3
echo ""
read -p "geany-plugins installation (n)ew or (f)ast " answer02
case "$answer02" in
n)
echo ""
sudo rm -rf $d1$dp2
cd $d1
git clone -b $branch $gitlink2 $dp2
cd $d1$dp2 && git remote update && git pull && git submodule update --init --recursive
$comp1;$comp8;$comp3
cd $d1$d2
;;
f)
echo ""
cd $d1$dp2 && git remote update && git pull && git submodule update --init --recursive
$comp8;$comp3
cd $d1$d2
;;
esac
;;
r)
echo ""
sudo rm -rf $d1$d2
cd $d1
git clone -b $branch $gitlink $d2
cd $d1$d2 && git remote update && git pull && git submodule update --init --recursive
$comp1
$comp2
$comp3
echo "";echo "geany-plugins installation";echo "";sleep 4s;
sudo rm -rf $d1$dp2
cd $d1
git clone -b $branch $gitlink2 $dp2
cd $d1$dp2 && git remote update && git pull && git submodule update --init --recursive
$comp1;$comp8;$comp3
cd $d1$d2
;;
a)
echo "";echo $end; exit 0
;;
*)
echo "";echo $end; exit 0
;;
esac
echo
read -p "install and create a deb package? (y/n) or (i)nstall only " answer02
case "$answer02" in
y|j)
cd $d1$d2
$comp7
$comp5 --pkgname=$n1 --provides=$n1 --pkgversion=$n2 --pkgrelease=$n3$n4$jetzt --nodoc
$comp6
echo ""; echo "geany-plugins installation..."; echo ""; sleep 4s&
cd $d1$dp2
$comp5 --pkgname=$np2 --provides=$np2 --pkgversion=$n2 --pkgrelease=$n3$n4$jetzt --nodoc
;;
n)
echo $end;exit 0
;;
i)
cd $d1$d2
$comp4
echo "";echo "geany-plugins installation...";echo "";sleep 4s&
cd $d1$dp2
$comp4
;;
esac
clear
cat ~/bin/maske|nms -a -c red
cat ~/bin/zeroc.ascii|nms -a
sleep 3s
echo ""
echo $end
exit 0
|
|
zeroc
(Themenstarter)
Anmeldungsdatum: 20. September 2008
Beiträge: 147
|
Entweder hatte ich ein kompromittiertes System, oder Ubuntu Livepatch ist doof. Ich habe meine SSD's geprüft, aber nichts gefunden. Im Grunde konnte ich alles retten und hatte nach 30 Minuten fast das gleiche System(leider nur fast), aber bin hart sauer. Irgendwer ist schuld und mit hoher Wahrscheinlichkeit bin ich es selbst. 🤣
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4655
Wohnort: Berlin
|
Mit den ganzen durchnummerierten Variablennamen ist das ziemlich unübersichtlich. Da sind so einige cd -Aufrufe drin die nicht gegen Fehler abgesichert sind. Und eine Menge Codewiederholungen. Und sudo rm -rf $d1$dp2 wo $d1 das Heimatverzeichnis ist, würde mich ja sehr nervös machen. Selbst ohne das sudo .
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55058
Wohnort: Berlin
|
Nein, "gefährlich" ist checkinstall nicht. Es prüft halt nichts und muss auch vollständig durchlaufen, damit etwas "nutzbares" herauskommen kann. Auf anderen Systemen, auf denen nicht die selben Abhängigkeiten installiert sind, kann man die damit gebauten Pakete dann nicht benutzen. Und ein .deb-Paket mit dpkg und force-all zu installieren ist ... ähh... suboptimal.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 11492
|
tomtomtom schrieb:
Auf anderen Systemen, auf denen nicht die selben Abhängigkeiten installiert sind, kann man die damit gebauten Pakete dann nicht benutzen.
Aber man kann bei checkinstall "--requires" mit Paketnamen und Versionen nutzen. Das steht dann in control unter "Depends:".
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55058
Wohnort: Berlin
|
Kann man, wird aber im Skript nicht getan, daher siehe oben. 😛
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9426
Wohnort: Münster
|
zeroc schrieb: […]
1. : Da ich zu faul bin, verstehen zu wollen, […]
2. : Heute habe ich mir eine Kernel-Panik eingefangen […]
3. : In der Konsole kamen genau bei diesem Script schon die ersten "No such file or directory" Meldungen. Danach ging nichts mehr.
4. : Alles was in /bin oder /sbin hätte gefunden werden müssen, war nicht mehr da.
5. : Ich hatte verfrüht einen Neustart gemacht und dann kamen die init Fehler.
6. : Ich habe ein paar Stunden, alle logfiles gecheckt und eigentlich gab es überhaupt fast nichts auffälliges(bis auf einige "Datei nicht gefunden Meldungen"...im Grunde recht viele, aber ansonsten gar nichts)
7. : Es gab wohl zeitgleich ein Live-Update. Keine Ahnung, wie das wirklich heißt. In diesen logs ist der früheste Eintrag für "no such file or directory" zu finden.
8. : Ich weiß nicht, was hier wirklich passiert ist. ich würde es gerne verstehen.
Zusammengefasst: Du hast bei skripten einen Fehler gemacht und mit jedem Reparaturversuch wurde es schlimmer. In einer solchen Fehlerkette steht logischerweise der auslösende Fehler ganz am Anfang.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 11492
|
kB schrieb:
In einer solchen Fehlerkette steht logischerweise der auslösende Fehler ganz am Anfang.
Du meinst also Punkt 0? Oder etwa nicht? 😉
zeroc schrieb: […]
|
zeroc
(Themenstarter)
Anmeldungsdatum: 20. September 2008
Beiträge: 147
|
Naja, ich habe das Script in der Form, bestimmt schon 100x benutzt. Was für eine Reparatur? sudo make install erzeugt Files, die sich mit rm -rf nicht löschen lassen, daher benutze ich sudo rm -rf /home/zeroc/git/geany-plugins. Der Ordner git ist dazu noch ein symlink auf eine externe Platte. In diesem Fall lassen sich die geany-plugins, nach einem git remote update, nicht erneut fehlerfrei kompilieren(sudo make install erzeugt die plugins als root und kopiert sie danach mit cp in irgendwelche local/share Ordner. make hat danach natürlich keine Rechte mehr, die Dateien zu überschreiben.) und daher wird der Ordner gelöscht und einfach komplett neu erzeugt. Da die Plugins und geany selbst nicht im gleichen git liegen, springe ich natürlich mit cd hin und her. | #### gibt konflikte mit calf, daher ein bissl gebastel
comp6="sudo dpkg --force-all --install geany_1.3*"
|
checkinstall baut das Paket, aber installiert es nicht, daher --force-all. Ist nen Workaround, mit dem ich auch nicht zufrieden bin. Im Grunde handelt es sich um docs, die komischerweise auch im, mit checkinstall erzeugtem calf-Paket enthalten sind. why ever. Da ich dieses Problem also nur mit geany und calf habe, bin ich in diesem Fall nicht weiter bemüht, mein Problem anders lösen zu wollen. Dieses Script läuft ähnlich bei ca. 200 weiteren Tools, daher die Variablen. Die lassen ich schnell ändern und ich habe nen weiteres Script, welches mir die ca. 200 make Scripte in einem wisch durchackert. Das Spiel läuft seit 2013 bisher fehlerfrei. Eigentlich bricht der Kram dann nur ab, wenn irgendein Projekt auf cmake, oder dann von cmake auf waf, oder ähnlich switcht, bzw. sich build dependencies ändern. Das merkt man ja schnell. ☺ Mit der Kernelpanik Fehlermeldung habe ich natürlich google bemüht und es fanden sich gleich 2 Treffer, die den selben Fehler nach der Benutzung von checkinstall erzeugten. Ich würde das Script selbst, als Fehlerquelle ausschließen, aber ich habe es ja nicht umsonst gepostet. Verunsichert bin ich natürlich trotzdem. Schaut mal hier: https://forum.ubuntuusers.de/topic/kernel-panic-sbin-init-wird-nicht-gefunden/ Selbst hier im Forum ist das schon beschrieben worden: "Bei checkinstall (ohne irgendwelche weiteren Optionen dazu, bevor es da wieder Missverständnisse gibt) gabs eine Fehlermeldung, und danach war Schluss mit lustig." Er hat exakt das Selbe erlebt und hatte kein Script. Die Frage bleibt also bestehen: Ist checkinstall gefährlich?
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17518
|
Ja, checkinstall ist gefährlich. Warum? Das tool ist dumm wie Brot. Warum nimmst du für 200 Tools (deine Zahl) checkinstall, anstatt z.B. PPAs oder andere Fremdquellen? Auch nicht perfekt, macht aber weniger Probleme als Dinge die per sudo make am System fummeln. checkinstall wird seit 2017 nicht mehr weiterentwickelt (hab gerade das git ausgecheckt zum nachschauen), hat nur einen Entwickler, ist nicht auf Github oder sonstwo das Ding jemand auch vielleicht forken würde. Vieles was checkinstall macht, machen heute Container (gut) oder neuere Paketformate wie AppImage (gut), Flatpak (naja) oder Snap (pfui). Gleichzeitig gibt es immer mehr Software die in Go, Rust oder Python geschrieben ist, welche man ordentlich deployed bekommt ohne das halbe System zu zerlegen. Du willst aktuelle Software, und hast Bock auch mal was zu paketieren? Perfekt, dann nimm Arch Linux oder was anderes. Debian und Ubuntu werden mit checkinstall nicht verwaltet oder administriert, sondern misshandelt etwas zu sein was diese nie sein wollten (oder sollten).
|
DocHifi
Anmeldungsdatum: 21. Oktober 2008
Beiträge: 1470
|
Du willst aktuelle Software, und hast Bock auch mal was zu paketieren? Perfekt, dann nimm Arch Linux oder was anderes. Debian und Ubuntu werden mit checkinstall nicht verwaltet oder administriert, sondern misshandelt etwas zu sein was diese nie sein wollten (oder sollten).
👍
|
Dieter_Ubuntu
Anmeldungsdatum: 4. Juli 2007
Beiträge: 448
|
Hallo Zeroc, wenn Du Dein System wieder mal zerschossen hast, dann sieh Dir mal diesen Wiki-Artikel an: qt-fsarchiver Wenn Du Dein System vorher gesichert hast, hast Du in wenigen Minuten das ursprüngliche System wieder hergestellt. Grüße aus Südbaden
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo,
Dieses Script läuft ähnlich bei ca. 200 weiteren Tools, daher die Variablen. Die lassen ich schnell ändern und ich habe nen weiteres Script, welches mir die ca. 200 make Scripte in einem wisch durchackert.
Da hast 200 Lieblingstools. Wow. Bei 200 verschiedenen Programmen würde ich auch mal schauen, ob es nicht einige davon als von den Entwickler selber gepflegtes snap, AppImage, Flatpak (in der Reihenfolge) gibt oder - besser noch via pip (für Python Programme), via cargo (für Rust Programme) oder als precompiled binaries (für Go-Programme gibt). Und wenn nicht wäre es halt zeitgemäßer und besser für das System, die deine vielen Liebungstools in ein snap (https://snapcraft.io/build) oder ein AppImage oder ein Flatpak zu bauen. Gruß, noisefloor
|
zeroc
(Themenstarter)
Anmeldungsdatum: 20. September 2008
Beiträge: 147
|
Bestimmt habe ich mehr. Hast du schon mal einen Container gebaut? Nein!?! Dann gebe auch kein Tipps dazu!!! Die Dinger sind nicht Zeitgemäß, sondern im Gegenteil unsicher! Baue mal so ein Ding und dann frage dich, wo die ganzen Abhängigkeiten herkommen und wer das alles mal aktualisiert, oder überhaupt überprüft. Ich wüsste da nicht, wer mir spontan einfällt....Der Entwickler macht es auf jeden mal nicht! Ich bin kein Freund von diesem snap oder flatpak Mist. Werde ich auch nie. 24.04 ist die letzte Ubuntu-Version für mich und dann bin ich leider wieder bei irgendwo bei Arch, oder gentoo... ...wenn man pro und kontra gegenüberstellen muss, dann lieber das, als dieser snap scheiß. Vor allem: Was sind das eigentlich für komische Ratschläge hier? Benutze kein sudo, nimm lieber PPA's, schreibe keinen eigenen Script's? Geht mal lieber zurück zu Windows, bevor ihr hier irgendwas kommentiert.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17518
|
zeroc schrieb: Hast du schon mal einen Container gebaut? ... Die Dinger sind nicht Zeitgemäß, sondern im Gegenteil unsicher!
Es gibt heute validierte/trusted Container, mit Security Reviews, automatischen Vulnerability Scans und reproducible builds. Aber ja, wenn man sich den Shady Container 0815 von einer unbekannten Container Registry zieht, und diese Container 4 Jahre alt ist sollte man eventuell bisschen Nachdenken.
Baue mal so ein Ding und dann frage dich, wo die ganzen Abhängigkeiten herkommen und wer das alles mal aktualisiert, oder überhaupt überprüft.
Sieht man auf z.B. Github im Dockerfile, welches vom Docker Hub oder Quay aus verlinkt wird. Man sieht sogar wer wann welche Änderungen gemacht hat.
Ich wüsste da nicht, wer mir spontan einfällt....Der Entwickler macht es auf jeden mal nicht!
Entwickler neigen dazu heute z.B. Github Actions oder Gitlab CI zu verwenden, um den Bau von Images zu automatisieren.
Ich bin kein Freund von diesem snap oder flatpak Mist.
Zumindest da sind wir uns einig.
wieder bei irgendwo bei Arch, oder gentoo...
Ich nutze Arch Linux seit mindestens 14 Jahren, und eins kann ich dir sagen: Sollte man da ernsthaft was mit checkinstall machen, wird das keine Lange Halbwertszeit haben, schlicht weil eine RR Distribution ständig was aktualisiert. Eventuell kannst du dir mal Slackware anschauen, oder LFS.
...Benutze kein sudo, nimm lieber PPA's, schreibe keinen eigenen Script's?
Nun, man sollte sudo nur so wenig wie möglich nutzen, einfach weil man den root Account auch so wenig wie möglich nutzen sollte. PPAs stellen vorgebaute Ubuntu Pakete für vieles Bereit, direkt vom Entwickler. Ist nicht mehr aber auch nicht weniger Vertrauenswürdig als der Dreisatz (./configure && make && make install ). Übrigens: Hast du dir schon mal ein configure Script oder Makefile angeschaut? Und verstanden? Ich glaube nicht, denn wenn man das hat ist ein Dockerfile (oder anderes Container Format) nicht mehr der große Impact an Sicherheit. Scripts: Nun ja, ich mach den Quatsch schon diverse Jahre. Und wann immer jemand gesagt hat: "Da Schreibe ich mir schnell ein kleines Script.", sagen wir es mal so: Richtige Programmiersprachen fliegen wenigstens (im Standard) auf die Nase wenn man sich etwas unglücklich anstellt, bash/sh im Standard tut munter weiter was man ihm sagt. Und so haben auch selbst Firmen wie Valve schon mal Home Verzeichnisse durch den Reiswolf geworfen, aber ich bin mir sicher: Du weißt was du tust, dir passiert sowas nicht.
Geht mal lieber zurück zu Windows, bevor ihr hier irgendwas kommentiert.
Nicht so mein Fall, aber für dich eine großartige Alternative: Es gibt sowohl setup.exe als auch install.msi, und vor allem: Man braucht kein checkinstall. Eine kleine Anmerkung noch zu checkinstall: Das Ding wird seit mindestens 2017 nicht mehr weiterentwickelt. Du kannst dir einfach das git Repository davon klonen falls du mir nicht glaubst, es gab in den Jahren 2015, 2016 und 2017 jeweils nur einen commit. Und die alle von einem einzigen Entwickler, welcher heute vermutlich einfach keine Lust mehr hat. Wie war das nochmal mit deiner Kritik an Entwicklern weiter oben?
|