Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 10:35 #
Ich habe am 11.4 den RC3 der Cinnamon-Live-DVD runtergeladen und da war der Fehler auch schon drin, ebenso am 27.5 den RC4 der Cinnamon-Live-DVD.
Die normale Installations-DVD hat allerdings funktioniert. Wundert mich, daß solche Basisfunktionalitäten nicht durch automatisierte Tests gewährleistet werden.
Vielleicht sollte ich die Fehler beim nächsten Release doch an Debian zurückmelden
Ist schon erstaunlich was Leute in deren Freizeit so für lau alles machen, und das auch noch für andere. Das Debian Release Team sind übrigens primär nur zwei Personen.
https://wiki.debian.org/Teams/DebianCd
Dann zu erwarten, dass ein riesiger automatischer und dazu noch manueller Testworkflow dranhängt ist vielleicht etwas vermessen.
Aber wie immer, jeder ist eingeladen die Situation zu verbessern! Debian ist ein Projekt basierend auf Volontären und eine Firma dahinter.
Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 12:28 #
Es braucht ja kein riesiger manueller Testworkflow sein, aber ein EINMAL eingerichteter automatisierter Test der BASISfunktionalität könnte solche Bockschüsse im GA-Release vermeiden und auch Regressionen bei der Entwicklung erkennen. Ich hab jetzt EINMAL und BASIS groß geschrieben, um darzustellen, daß der Aufwand für die nach der 20/80-Regel zu findenden Fehler nicht so groß ist.
Ich mach solche Sachen zwar nicht für lau( $$$ ab etwa 7k€ pro Monat seid ihr bei mir dabei $$$), aber sowas erst NACH dem Release zu erkennen, ist, laß mich das Wort suchen - SUBOPTIMAL.
lol also als vollqualifizierter Linux-Entwickler nur 7k zu verdienen spricht nicht gerade für dich Entweder verkaufst du dich schlecht oder bist schlecht.
Du verwechselst hier CD-Team mit Release-Team. Das CD-Team, wie übrigens auch die FTP-Master, arbeiten beim Release dem Release-Team zu. Unter https://www.debian.org/intro/organization#officers sind die Mitglieder der einzelnen Teams aufgeführt.
Hast du einen Vogel oder wie kommst du auf die Idee dass es auch wenn was für lau gemacht wird man zumindest erwarten kann dass wenigstes EINER EINMALIG testet ob der Dreck zumindest rudimentär funktionieren kann, nachdem ALLE unbrauchbar sind hätte es da keinen riesigen Aufwand gebraucht sondern ein beliebiges scheiss image in einer VM booten und ein paar mal clicken
Man stellt sich alles immer so professionell vor. Aber es gibt wirklich extrem viel zu tun bei so einem großen Projekt. Viel Hardware und Personal wäre eigentlich notwendig. Aber das ist alles nicht da. Die vielen Freiwilligen geben ihr Bestes. In der professionellen Welt würdest du vielleicht ein Test-Team ernennen. Aber Debian hat kein bezahltes Test-Team. Wer hat denn in seiner Freizeit Lust, ein System aufzubauen, das automatisiert Installations-Medien testet. Wo sich niemand findet, dort gibt es eben nichts.
Du hast doch einen Knall - Wenn ALLE Images unbenutzbar sind braucht es keine grossartigen Automatismus sondern EINEN der Entwickler der den scheissdreck den sie auf die Welt loslassen EINMAL testet und nicht wartet bis es die User machen
Wenn ich als User nämlich anfangen will zu helfen und zu testen und bei den basics schon nichts funktioniert habe ich die Fresse voll und will vom rest gar nichts mehr wissen
Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 14:15 #
Eigentlich wollte ich nur unsere eigenen Testprozeduren auf Stretch anpassen und da unsere Software auch auf dem neuen Debian laufen soll, sollte eine Standard-Stretch-Umgebung geschaffen werden. Ich wollte die Standard-Testprozeduren für unsere Debian-8-Standard-Installation entsprechend anpassen. Das setzt einmal eine manuelle Installation voraus, um eine Voreinstellungsdatei für eine automatisierte Installation erstellen zu können. Da ist mir das aufgefallen.
Wie mein Nick andeutet, habe ich das nicht bei Debian gemeldet, da ich ansonsten nicht bei Debian involviert bin und außerdem die Cinnamon-Live-Umgebung doch sehr speziell ist und ansonsten bei uns und Kunden nicht verwendet wird. Ich hatte die gerade nur zur Hand, weil ich vorher ein paar manuelle hardwarespezifische Tests mit der Live-DVD durchgeführt hatte. Da spart man sich die vorherige Installation. Außerdem wollte ich wissen, ob es bezüglich der Voreinstellungsdatei Unterschiede zwischen Installations- und der Live-DVD gibt.
Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 11:27 #
Also bei Fedora sind meist schon die alpha-Versionen auch der Live-Spins INSTALLIERBAR. Ich hab hier eine Fedora-Cinnamon-Live-x86_64-26-20170420.n.0.iso installiert und ohne Probleme laufen.
Ja, Fedora ist schon was feines, für den Desktop finde ich es recht gelungen und stabil, wenn es aber um Server geht würde ich persönlich doch eher zu RHEL bzw. CentOS greifen.
Nur das man bei CentOS, wie bei vielen anderen leider auch, immer erst das SELinux abschalten muss. Sicherheit ist ja gut und schön aber wenn diese einem ständig im Weg steht und so den Aufwand oft um das zehnfache erhöht kann ich darauf verzichten, da sind mir solche Sache wie AppArmor um einiges lieber.
Bei SELinux gebe ich dir recht. Bin ja nicht ganz der dümmste, aber ich raffe es nicht, wie ich eine neue Regel anlege. Unter Red-Hat gibts zwar eine Anleitung, aber das ist alles viel zu komplex.
Ich denke es kommt eher auf den Anwendungszweck an. Wenn der Server öffentlich zugänglich ist (dass die Benutzer also auch beispielsweise SSH-Zugang haben), dann ist SELinux meiner Meinung nach recht sinnvoll wenn man nicht will dass andere, sei es absichtlich oder versehentlich, irgendwo rumpfuschen oder gar Zugriff darauf haben.
Natürlich braucht SELinux viel Konfigurationsaufwand, das lässt sich leider nicht vermeiden, aber meistens tut man diese nur einmal und dann nie wieder, es sollte also kein sehr großes Problem sein sich das mal kurz anzuschauen
SELinux vollständig abzuschalten ist ganz sicher oft nicht der richtige Weg. Ich löse das anders, vielleicht ist das ein Weg den du auch gehen kannst. Nach der Installation schalte ich SELinux "permissive" damit werden die Richtlinien angewendet aber nicht durchgesetzt. Ich richte alles ein was man so braucht und schicke das ganze in den Testbetrieb. Sollte etwas klemmen, laufen die Systeme weiter, ich kann aber dennoch ganz gezielt und ohne Zeitdruck (SELinux kostet durchaus viel Zeit) alles zurechtbiegen. Was ich bemängel, das SELinux sehr starr ist z.B. wenn ich Maschinen zur Webentwicklung betreibe. Durch das ständige ändern an der Umgebung bedingt durch neue Projekte fällt mir SELinux tatsächlich heftig ins Kreuz. Mangelhaft ist auch die Dokumentation und die veränderte Syntax der jeweiligen Versionen. Gerade weil SELinux so wichtig ist, muss sich hier noch einiges ändern.
Ich finde es immer wieder erstaunlich wie Leute auf die Idee kommen etwas sofort auszurollen ohne es vorher mal selbst vollständig auszuprobieren ...
Aber bei Debian scheint das ja Alltag zu sein, wenn ich mir so weitere Bugs anschaue:
- LightDM zerstückelt sich von selbst wenn man zwei oder mehr Bildschirme hat - Pulseaudio lässt sich nicht installieren, weil rtkit nicht starten kann, ein Neustart ist notwendig, danach ein "dpkg --configure -a" - Im Kernel werden plötzlich von heute auf morgen plötzlich irgendwelche Module entfernt die man vorher benötigte bzw haben wollte, wie beispielsweise TPM ... Nach ständigen Fragen an das Debian-Team bekomme ich immer nur die selbe Antwort: Ich wär ein Troll.
Gestern reproduzierbar untergekommen. Failed to unmount /var. Fehler bereits seit 2015 bekannt, Lösung var in root packen. Also Partitionieren wie zur Steinzeit.. Genau so Bluetooth, die gleiche Suppe wie unter Jessie, scheinbar funktioniert alles, schaust ins Log, Peng die rote Suppe, auch bekannt, Debian und Ubuntu haben dazu die Bugs gemeldet bekommen, Lösung nur bedingt vorhanden. So könnte ich noch paar Knaller hier reinwerfen, schön ist anders.
Das Problem ist das sich meist schon eine Stufe höher, in deinem Fall bei den Devs von bluez, keine Sau dafür interessiert.
Ist beim SAMBA BUG: 11761 nicht anders, auch der ist mittlerweile seit rund einem Jahr bekannt und es gibt noch immer keinen Fix. Nicht einmal eine Warnung in der Manpage des VFS-Modul acl_tdb ist den Devs drin gelegen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 22. Jun 2017 um 07:57.
Führe einmal ein e2fsck von einer anderen aktuellen Distro wie Ubuntu Xenial oder OpenSuse 42.2 aus oder von Debian Jessie. Was dann folgt, ist allerdings kein Bug, sondern ein "Feature", quasi hypermodern.
Oder starte Gparted in Xenial oder Jessie und versuche die Stretch-Root-Partition zu benennen oder umzubenennen. Die Ursache des auftretenden Fehlers, der keiner ist, ist die gleiche.
Ach ja, die Fehlermeldung beim Mounten der Stretch-Ext4-Partitionen von einem vorherigen Debian (ab 8 abwärts) habe ich noch vergessen: "Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so" Aber das ist so gewollt.
Wer das zugrundeliegende Stretch-Feature schon kennt, hat 100 Punkte.
Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 17:46 #
Also von einem richtigen DVD-Laufwerk hab ich schon lang nicht mehr gebootet. Bei physischen Maschinen ohne Netzwerk vom USB-Stick, bei virtuellen Maschinen ohne NW direkt von der ISO-Datei im virtuellen DVD-LW.
Die netiso ist immer die erste Wahl. Eigentlich aber eher, um unnötigen Traffic zu vermeiden. Es muss also auch im Einzelfall unterschieden werden, wie oft du mit einem Medium installieren möchtest.
Von Tester und Nichtmelder am Mi, 21. Juni 2017 um 22:51 #
Steve McIntyre hat neue 9.0.1-Versionen der Live-ISOs bereitgestellt, die den Fehler beheben: Hier gibts die ISOs: http://get.debian.org/cdimage/release/current-live/amd64/iso-hybrid/ Und hier die Torrent-Dateien dazu: http://get.debian.org/cdimage/release/current-live/amd64/bt-hybrid/
Ich habe am 11.4 den RC3 der Cinnamon-Live-DVD runtergeladen und da war der Fehler auch schon drin, ebenso am 27.5 den RC4 der Cinnamon-Live-DVD.
Die normale Installations-DVD hat allerdings funktioniert. Wundert mich, daß solche Basisfunktionalitäten nicht durch automatisierte Tests gewährleistet werden.
Vielleicht sollte ich die Fehler beim nächsten Release doch an Debian zurückmelden
Wundert mich, daß solche Basisfunktionalitäten nicht durch automatisierte Tests gewährleistet werden.
Mich wundert noch mehr, dass die ihren Shice vor dem Ausrollen nicht mal händisch testen.
Ist schon erstaunlich was Leute in deren Freizeit so für lau alles machen, und das auch noch für andere. Das Debian Release Team sind übrigens primär nur zwei Personen.
https://wiki.debian.org/Teams/DebianCd
Dann zu erwarten, dass ein riesiger automatischer und dazu noch manueller Testworkflow dranhängt ist vielleicht etwas vermessen.
Aber wie immer, jeder ist eingeladen die Situation zu verbessern! Debian ist ein Projekt basierend auf Volontären und eine Firma dahinter.
Es braucht ja kein riesiger manueller Testworkflow sein, aber ein EINMAL eingerichteter automatisierter Test der BASISfunktionalität könnte solche Bockschüsse im GA-Release vermeiden und auch Regressionen bei der Entwicklung erkennen.
Ich hab jetzt EINMAL und BASIS groß geschrieben, um darzustellen, daß der Aufwand für die nach der 20/80-Regel zu findenden Fehler nicht so groß ist.
Ich mach solche Sachen zwar nicht für lau( $$$ ab etwa 7k€ pro Monat seid ihr bei mir dabei $$$), aber sowas erst NACH dem Release zu erkennen, ist, laß mich das Wort suchen - SUBOPTIMAL.
lol also als vollqualifizierter Linux-Entwickler nur 7k zu verdienen spricht nicht gerade für dich Entweder verkaufst du dich schlecht oder bist schlecht.
Wow da ist aber jemand neidisch
Welche Firma genau?
Nachdenken gekommen: Ich möchte ein 'k' kaufen und löse: keine Firma.
Du verwechselst hier CD-Team mit Release-Team. Das CD-Team, wie übrigens auch die FTP-Master, arbeiten beim Release dem Release-Team zu. Unter https://www.debian.org/intro/organization#officers sind die Mitglieder der einzelnen Teams aufgeführt.
Hast du einen Vogel oder wie kommst du auf die Idee dass es auch wenn was für lau gemacht wird man zumindest erwarten kann dass wenigstes EINER EINMALIG testet ob der Dreck zumindest rudimentär funktionieren kann, nachdem ALLE unbrauchbar sind hätte es da keinen riesigen Aufwand gebraucht sondern ein beliebiges scheiss image in einer VM booten und ein paar mal clicken
Ordinäres pöbelndes Gelaber. Aber es trägt zur Unterhaltung bei.
Jeder kann Images testen...
Die Debian Community ist mehrere hundert Entwickler und tausende erfahrene Anwender groß....
Man stellt sich alles immer so professionell vor. Aber es gibt wirklich extrem viel zu tun bei so einem großen Projekt. Viel Hardware und Personal wäre eigentlich notwendig. Aber das ist alles nicht da. Die vielen Freiwilligen geben ihr Bestes. In der professionellen Welt würdest du vielleicht ein Test-Team ernennen. Aber Debian hat kein bezahltes Test-Team. Wer hat denn in seiner Freizeit Lust, ein System aufzubauen, das automatisiert Installations-Medien testet. Wo sich niemand findet, dort gibt es eben nichts.
Du hast doch einen Knall - Wenn ALLE Images unbenutzbar sind braucht es keine grossartigen Automatismus sondern EINEN der Entwickler der den scheissdreck den sie auf die Welt loslassen EINMAL testet und nicht wartet bis es die User machen
Wenn ich als User nämlich anfangen will zu helfen und zu testen und bei den basics schon nichts funktioniert habe ich die Fresse voll und will vom rest gar nichts mehr wissen
Mit dem Kommunikationsstil würdest Du bei keinem Debian-Projekt das erste Posting auf der Debian-Mailingliste überstehen.
Ach, der Märchenerzähler meldet sich auch mal wieder.
Mich wundert, dass der Bug-Report dann erst am 18.6. erstellt wurde und nicht schon am 11.4 bzw. 27.5. ...
Eigentlich wollte ich nur unsere eigenen Testprozeduren auf Stretch anpassen und da unsere Software auch auf dem neuen Debian laufen soll, sollte eine Standard-Stretch-Umgebung geschaffen werden. Ich wollte die Standard-Testprozeduren für unsere Debian-8-Standard-Installation entsprechend anpassen. Das setzt einmal eine manuelle Installation voraus, um eine Voreinstellungsdatei für eine automatisierte Installation erstellen zu können. Da ist mir das aufgefallen.
Wie mein Nick andeutet, habe ich das nicht bei Debian gemeldet, da ich ansonsten nicht bei Debian involviert bin und außerdem die Cinnamon-Live-Umgebung doch sehr speziell ist und ansonsten bei uns und Kunden nicht verwendet wird. Ich hatte die gerade nur zur Hand, weil ich vorher ein paar manuelle hardwarespezifische Tests mit der Live-DVD durchgeführt hatte.
Da spart man sich die vorherige Installation. Außerdem wollte ich wissen, ob es bezüglich der Voreinstellungsdatei Unterschiede zwischen Installations- und der Live-DVD gibt.
nehmt doch einfach Fedora lach, duck und weg...
Also bei Fedora sind meist schon die alpha-Versionen auch der Live-Spins INSTALLIERBAR. Ich hab hier eine Fedora-Cinnamon-Live-x86_64-26-20170420.n.0.iso installiert und ohne Probleme laufen.
Duck und wech
Ja, Fedora ist schon was feines, für den Desktop finde ich es recht gelungen und stabil, wenn es aber um Server geht würde ich persönlich doch eher zu RHEL bzw. CentOS greifen.
Nur das man bei CentOS, wie bei vielen anderen leider auch, immer erst das SELinux abschalten muss. Sicherheit ist ja gut und schön aber wenn diese einem ständig im Weg steht und so den Aufwand oft um das zehnfache erhöht kann ich darauf verzichten, da sind mir solche Sache wie AppArmor um einiges lieber.
Bei SELinux gebe ich dir recht. Bin ja nicht ganz der dümmste, aber ich raffe es nicht, wie ich eine neue Regel anlege.
Unter Red-Hat gibts zwar eine Anleitung, aber das ist alles viel zu komplex.
Ich denke es kommt eher auf den Anwendungszweck an. Wenn der Server öffentlich zugänglich ist (dass die Benutzer also auch beispielsweise SSH-Zugang haben), dann ist SELinux meiner Meinung nach recht sinnvoll wenn man nicht will dass andere, sei es absichtlich oder versehentlich, irgendwo rumpfuschen oder gar Zugriff darauf haben.
Natürlich braucht SELinux viel Konfigurationsaufwand, das lässt sich leider nicht vermeiden, aber meistens tut man diese nur einmal und dann nie wieder, es sollte also kein sehr großes Problem sein sich das mal kurz anzuschauen
SELinux vollständig abzuschalten ist ganz sicher oft nicht der richtige Weg. Ich löse das anders, vielleicht ist das ein Weg den du auch gehen kannst. Nach der Installation schalte ich SELinux "permissive" damit werden die Richtlinien angewendet aber nicht durchgesetzt. Ich richte alles ein was man so braucht und schicke das ganze in den Testbetrieb. Sollte etwas klemmen, laufen die Systeme weiter, ich kann aber dennoch ganz gezielt und ohne Zeitdruck (SELinux kostet durchaus viel Zeit) alles zurechtbiegen. Was ich bemängel, das SELinux sehr starr ist z.B. wenn ich Maschinen zur Webentwicklung betreibe. Durch das ständige ändern an der Umgebung bedingt durch neue Projekte fällt mir SELinux tatsächlich heftig ins Kreuz. Mangelhaft ist auch die Dokumentation und die veränderte Syntax der jeweiligen Versionen. Gerade weil SELinux so wichtig ist, muss sich hier noch einiges ändern.
Ich finde es immer wieder erstaunlich wie Leute auf die Idee kommen etwas sofort auszurollen ohne es vorher mal selbst vollständig auszuprobieren ...
Aber bei Debian scheint das ja Alltag zu sein, wenn ich mir so weitere Bugs anschaue:
- LightDM zerstückelt sich von selbst wenn man zwei oder mehr Bildschirme hat
- Pulseaudio lässt sich nicht installieren, weil rtkit nicht starten kann, ein Neustart ist notwendig, danach ein "dpkg --configure -a"
- Im Kernel werden plötzlich von heute auf morgen plötzlich irgendwelche Module entfernt die man vorher benötigte bzw haben wollte, wie beispielsweise TPM ... Nach ständigen Fragen an das Debian-Team bekomme ich immer nur die selbe Antwort: Ich wär ein Troll.
Wirklich nett, diese Debianer ..
Gestern reproduzierbar untergekommen. Failed to unmount /var. Fehler bereits seit 2015 bekannt, Lösung var in root packen. Also Partitionieren wie zur Steinzeit.. Genau so Bluetooth, die gleiche Suppe wie unter Jessie, scheinbar funktioniert alles, schaust ins Log, Peng die rote Suppe, auch bekannt, Debian und Ubuntu haben dazu die Bugs gemeldet bekommen, Lösung nur bedingt vorhanden. So könnte ich noch paar Knaller hier reinwerfen, schön ist anders.
Das Problem ist das sich meist schon eine Stufe höher, in deinem Fall bei den Devs von bluez, keine Sau dafür interessiert.
Ist beim SAMBA BUG: 11761 nicht anders, auch der ist mittlerweile seit rund einem Jahr bekannt und es gibt noch immer keinen Fix. Nicht einmal eine Warnung in der Manpage des VFS-Modul acl_tdb ist den Devs drin gelegen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 22. Jun 2017 um 07:57.Stimmt, ist echt bitter.
Führe einmal ein e2fsck von einer anderen aktuellen Distro wie Ubuntu Xenial oder OpenSuse 42.2 aus oder von Debian Jessie. Was dann folgt, ist allerdings kein Bug, sondern ein "Feature", quasi hypermodern.
Oder starte Gparted in Xenial oder Jessie und versuche die Stretch-Root-Partition zu benennen oder umzubenennen. Die Ursache des auftretenden Fehlers, der keiner ist, ist die gleiche.
Ach ja, die Fehlermeldung beim Mounten der Stretch-Ext4-Partitionen von einem vorherigen Debian (ab 8 abwärts) habe ich noch vergessen:
"Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so"
Aber das ist so gewollt.
Wer das zugrundeliegende Stretch-Feature schon kennt, hat 100 Punkte.
vielleicht ist es eher besser die kleine netiso zu benutzen, weil es kann schneller sein als in dvd Laufwerk. oder wie sind die mb/s Zahlen ?
Also von einem richtigen DVD-Laufwerk hab ich schon lang nicht mehr gebootet. Bei physischen Maschinen ohne Netzwerk vom USB-Stick, bei virtuellen Maschinen ohne NW direkt von der ISO-Datei im virtuellen DVD-LW.
also angeblich lässt sich die neue iso von Manjaro 17.01 nicht unter windows auf ein usbstick bringen, dann muss man wohl ein dvd laufwerk benutzen.
Da behauptet das Manjaro-Wiki aber was anderes:
Manjaro Wiki - Burn an ISO File
Die netiso ist immer die erste Wahl. Eigentlich aber eher, um unnötigen Traffic zu vermeiden.
Es muss also auch im Einzelfall unterschieden werden, wie oft du mit einem Medium installieren möchtest.
Steve McIntyre hat neue 9.0.1-Versionen der Live-ISOs bereitgestellt, die den Fehler beheben:
Hier gibts die ISOs:
http://get.debian.org/cdimage/release/current-live/amd64/iso-hybrid/
Und hier die Torrent-Dateien dazu:
http://get.debian.org/cdimage/release/current-live/amd64/bt-hybrid/