| Author |
Message |
|
|
Post subject: Menschenskind sowas muss doch nicht ...Lösungen
 Posted: Jul 17, 2008 - 08:58 PM
|
|
Joined: Jan 10, 2008
Posts: 225
Status: Offline
|
|
Heute Nacht hatte es die besonders fleissigen sidux dist-upgrader zu allererst von den Stühlen gehobelt:
Neue Versionen von dmsetup, lsb etc... machten vielen ein unbrauchbares System. Und andere konnten zwar Runlevel 3 booten aber nicht ins graphische System.
Die einfachste Lösung solches künftig zu vermeiden wäre :
Einen TestPC aufstellen, der zu den 2 Zeiten pro Tage an denen das Debian sid Repository aufgefrischt wird selber dist-upgraded und danach neu bootet. Nach erfolgreichem Boot sendet der TestPC die aufgefrischte debian sid main Paketliste zum sidux Server. Wir sidux User ändern die /etc/apt/sources.list auf
Code:
deb http://sidux.net/debian/ sid main DEBIANSIDMAIN contrib non-free firmware fix.main fix.contrib fix.non-free
oder
Code:
deb http://debian.tu-bs.de/project/sidux/debian/ sid main DEBIANSIDMAIN contrib non-free fix.main fix.contrib fix.non-free
und haben dann die Gewissheit, das wenigstens ein TestPC nach dem dist-upgrade schon mal erfolgreich gebootet hat. Der einzige Nachteil wäre, dass wir eine halbe Stunde später dist-upgraden können, weil wir die Paketliste nicht mehr direkt von debian.org holen.
Ich würde 10 Euro aus meinem ziemlich leeren Portmanaie für eine solche Verbesserung an den sidux e.v. spenden!
Nachtrag: Geht das überhaupt eine Liste von einem anderen Server als die Pakete gedownloaded werden? |
Last edited by ralul on Jul 18, 2008 - 10:11 AM; edited 1 time in total
|
| |
|
|
|
 |
|
|
|
Post subject: Menschenskind sowas muss doch nicht passieren - diese Lösung
Posted: Jul 17, 2008 - 09:38 PM
|
|
Joined: Nov 30, 2006
Posts: 776
Location: Germany
Status: Offline
|
|
naja. welche software wird denn auf dem test-pc laufen? ein "typisches" setup gibt es ja nicht und nur die pakete zu benutzen, die bei sidux dabei sind, ist auch kein realistischer produktiveinsatz. auch kann ein PC unmöglich die verschiedenen hardwarekonfigurationen simulieren.
die idee find ich zwar eigentlich gut, aber der aufwand wäre relativ groß und der nutzen gering. außerdem wäre sidux dann ja nicht mehr wirklich debian/sid. |
_________________
http://sidux.wordpress.com/ inoffizielles sidux-Blog
|
| |
|
|
|
|
|
|
|
Post subject: Menschenskind sowas muss doch nicht passieren - diese Lösung
Posted: Jul 18, 2008 - 07:59 AM
|
|
Joined: Dec 02, 2006
Posts: 78
Status: Offline
|
|
Eine "Rückgängig"-Funktion fürs d-u wäre cool!
Sonst von Hand aus dem log, sofern das eigene lokale Repo noch gefüllt ist. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Menschenskind sowas muss doch nicht passieren - diese Lö
Posted: Jul 18, 2008 - 09:19 AM
|
|
Joined: Jan 07, 2008
Posts: 298
Status: Offline
|
|
| Du kannst dein eigenes System in einer vbox einrichten und ein Test-d-u vorher laufen lassen (mit Paket-Cache). |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: Menschenskind sowas muss doch nicht passieren - diese Lö
Posted: Jul 18, 2008 - 09:34 AM
|
|
Joined: Jan 10, 2008
Posts: 225
Status: Offline
|
|
@wannek2 : Die Rückgängig Funktion hätte ich mir gestern auch gewünscht. Aber das Debian Paketsystem ist für vorwärts Arkualisierung gebaut ist, dass heisst rückwärts Deaktualisierung geht zwar in den meisten Fällen (gestern nicht bei mir), ist aber nicht getestet und nie garantiert.
@zulu9: Jedenfalls wäre das gestrige Malheur wohl nicht passiert, weil gestern Pakete gestört waren, die jede Installation benutzt.
@ModestUser: Werde ich jetzt wohl auch so machen mit Vbox. Ich war gestern Abend nur etwas verärgert, weil ich ne Stunde lang blind im sidux rumkonfiguriert habe und nichts wieder hinkriegen konnte mit dem Einspielen der alten Versionen. Da ich kein Internet hatte (Ich habe nur wLan, was nicht mehr ging), half mir nur in Gentoo zu booten und mit chroot die betroffenen Pakete aus dem sidux Repository zu aktualisieren. Dazu noch einen großen Dank an die schnelle Reaktion der sidux Developer!
Aber wenn ich bedenke, dass ich schon ein gutes halbes Jahr bei sidux bin, also auf einem "rolling release" rolle, ist es schon erstaunlich, dass ich erst jetzt das erste Mal ernstliche Schwierigkeiten hatte. |
|
|
| |
|
|
|
|
|
|
|
Post subject: andere Idee - per smxi Feedbacksystem
Posted: Jul 18, 2008 - 10:06 AM
|
|
Joined: Jan 10, 2008
Posts: 225
Status: Offline
|
|
Durch den Thread in http://sidux.com/PNphpBB2-viewtopic-t-11768.html kam ich gerade auf eine Idee einer "billigeren" Software Lösung. Wie wäre es h2 vorzuschlagen in sein smxi script ein freiwilliges Mitmachfeedbacksystem zu integrieren: Freiwillige melden sich an bei einem smxi-feedback server. Dann wird der Erfolg eines jeden smxi initiierten dist-upgrades rückgemeldet (vielleicht nur nach einem erfolgreichen Reboot ohne Fehler).
Jedem dist-upgrader könnte dadurch eine Erfolgsstatistik des letzten Tages angezeigt werden. Fehlende erfolgreiche Reboots wären eine deutliche Warnung für die Nachfolgenden. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: andere Idee - per smxi Feedbacksystem
Posted: Jul 18, 2008 - 11:07 AM
|
|
Joined: Jan 07, 2008
Posts: 298
Status: Offline
|
|
| So etwas ist praktisch nicht automatisierbar. Schwerwiegend sind ja gerade die Nicht-Standard-Probleme. Wie wolltest du ausschließen, dass irgendwelche User ihr System selbst zerschossen haben und dann unnötige Warnmeldungen an smxi verschickt? Wie sollte smxi testen, ob ein reboot erfolgreich war? Das momentane System ist sehr gut und hat sich auch hier bewährt. Jemand hat Schwierigkeiten, kurze Zeit später gibt es eine Warnung und sehr schnell eine Lösung. So muss man nur von den Nutzern erwarten, dass sie kurz in den upgrade warnings nachschauen, ob alles in Ordnung ist. Ein paar Pechvögel gibt es dann halt. Aber so erhält niemand ein falsches Gefühl von Sicherheit. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Menschenskind sowas muss doch nicht passieren - dies
Posted: Jul 18, 2008 - 11:42 AM
|
|
Joined: Mar 29, 2007
Posts: 228
Location: München
Status: Offline
|
|
|
ModestUser wrote:
Du kannst dein eigenes System in einer vbox einrichten und ein Test-d-u vorher laufen lassen (mit Paket-Cache).
Das ist imho die beste und einfachste Lösung, (edit) denn sie beinhaltet auch ein gewisses Maß an Interesse und Eigenverantwortung. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Menschenskind sowas muss doch nicht passieren -
Posted: Jul 18, 2008 - 01:57 PM
|
|
Joined: Dec 02, 2006
Posts: 532
Status: Offline
|
|
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Menschenskind sowas muss doch nicht passieren -
Posted: Jul 18, 2008 - 06:24 PM
|
|
Joined: Apr 13, 2008
Posts: 111
Status: Offline
|
|
Wie wäre es einfach nicht gierig jeden Tag sofort zu upgraden?
Muss ja nicht sein oder?
Ein bisschen warten und gut ist 
Gruß
Snatch |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Menschenskind sowas muss doch nicht passiere
Posted: Jul 18, 2008 - 06:46 PM
|
|
Joined: Mar 29, 2007
Posts: 228
Location: München
Status: Offline
|
|
|
Snatch wrote:
Ein bisschen warten und gut ist
..und während des Wartens die News lesen bzw. die Upgrade Warnings im englischen Forenteil.
Gruß
M.
p.s.: und vor 24:00 ins Bett gehen |
|
|
| |
|
|
|
|
|
|
