SuSE 11.0_RC1 Image bootet nicht
Tom
- webserver
Hello,
haben gestern Abend die SuSE 11.0 RC1 als ISO-Image i386 heruntergeladen und gebrannt. Das Ganze mit zwei unterschiedlichen Systemen.
Leider will keines der Testsysteme von irgendeiner der beiden CDs booten.
Hat noch jemand sowas festgestellt?
Ein harzliches Glückauf
Tom vom Berg
Hello,
haben gestern Abend die SuSE 11.0 RC1 als ISO-Image i386 heruntergeladen und gebrannt. Das Ganze mit zwei unterschiedlichen Systemen.
Leider will keines der Testsysteme von irgendeiner der beiden CDs booten.
Hat noch jemand sowas festgestellt?
ggf solltest du noch ein paar tage warten release candidates sind nicht bugfrei und nur bedingt als produktivsystem geeignet - am 19 juni solls schon so weit seni
Hello,
Leider will keines der Testsysteme von irgendeiner der beiden CDs booten.
Hat noch jemand sowas festgestellt?
ggf solltest du noch ein paar tage warten release candidates sind nicht bugfrei und nur bedingt als produktivsystem geeignet - am 19 juni solls schon so weit seni
Die geht auch ganz bestimmt nicht in den Produktiveinsatz.
Aber angucken kann man sie sich doch schon mal.
Zumindest wäre das meine Aufgabe.
Ein harzliches Glückauf
Tom vom Berg
Die geht auch ganz bestimmt nicht in den Produktiveinsatz.
Aber angucken kann man sie sich doch schon mal.
Zumindest wäre das meine Aufgabe.
alternativ könnte es natürlich sein, dass du beim brennen gepfuscht hast und die cds nicht bootfähig sind - is mir auch schon mal passiert
häng das ding in eine virtuele maschine und mounte die images mit einer entsprechenden software - deamon tools oder ähnliches
Hello,
alternativ könnte es natürlich sein, dass du beim brennen gepfuscht hast und die cds nicht bootfähig sind - is mir auch schon mal passiert
häng das ding in eine virtuele maschine und mounte die images mit einer entsprechenden software - deamon tools oder ähnliches
Brennen hab ich nicht selber gemacht, sondern Chef :-)
Ich habe mir eben nochmal vonm der gwdg.de ein Image gezogen und auch vorher die MD5-Prüfsumme verglichen. Die passt diesmal auf jeden Fall.
Virtuelle Maschine hab ich nicht *schnüff*
Ein harzliches Glückauf
Tom vom Berg
Hello,
jetzt habe ich drei Image-CDs und keine funktioniert...
Für andere Images (Debian) hat es aber mit den gleichen Rohlingen (von Feinkost-Aldi) geklappt.
Ein harzliches Glückauf
Tom vom Berg
Für andere Images (Debian) hat es aber mit den gleichen Rohlingen (von Feinkost-Aldi) geklappt.
naja, debian ist ein betriebssystem - suse ist ein spielzeug ;)
die einfachen produkte die für dich zum testen ausreichen sind kostenlos:
http://www.vmware.com
http://www.vmware.com/download/server/
Hallo,
Brennen hab ich nicht selber gemacht, sondern Chef :-)
dann zieh Deinem Chef endlich mal den grün, geringelten Schwanz des Suse-Kamels lang und besorgt Euch endlich Linux℠! *scnr*
Gruß aus Berlin!
eddi
Hello,
dann zieh Deinem Chef endlich mal den grün, geringelten Schwanz des Suse-Kamels lang und besorgt Euch endlich Linux℠! *scnr*
Habe ich ihm schon ein paarmal gesagt :-)
Als aber gestern das Filelocking in PHP aus dem Debain-Paket nicht funktionierte, und es nach einem Update immer noch nicht ordnungsgemäß geht, war das natürlich Wasser auf seine Mühle
Ist aber das erste Mal, dass ich mit Debian Probleme habe.
Ein harzliches Glückauf
Tom vom Berg
Hallo,
Als aber gestern das Filelocking in PHP aus dem Debain-Paket nicht funktionierte, und es nach einem Update immer noch nicht ordnungsgemäß geht, war das natürlich Wasser auf seine Mühle
Dann leg die Mühle wieder trocken. Erweiterung DIO wird nicht mehr angeboten. Debian zog dabei sicherlich nur mit. Filelocking lässt sich (auch) mit Semaphoren regeln (05. 04. 2005; das war damals schon ernst gemeint, als ich Dir schrieb: Löse ES mit Semaphoren!), jedoch sind diese immer noch Bestandteil PHPs.
BTW: ftok() arbeitet nicht 100% sauber (vgl. : man ftok). Da bin ich auch gerade bei einer gedanklichen Neukonzeption.
Gruß aus Berlin!
eddi
Hello,
Dann leg die Mühle wieder trocken. Erweiterung DIO wird nicht mehr angeboten.
Ich habe DIO noch installiert und es funktioniert, im Gegensatz zu flock() advisory Locks erwartungsgemäß.
Ich habe extra nochmal eine neue Platte OHNE DIO aufgesetzt, weil ich die Vermutung hatte, dass das vielleicht für das Ignorieren des LOCK_NB verantwortlich sein könnte. Das hat aber, soweit ich das feststellen konnte, nichts miteinander zu tun.
Flock() blockt trotzdem weiter.
Christian hat ja schon geschrieben, dass es in den neueren Versionen nach 5.2.0 (wieder) funktioniert, nur scheinen die eben nicht Grundlage für Debians PHP-Packages zu sein, bzw. Debian bietet noch keine neuere PHP-Version als Basis an.
Da müsste ich also nun selber kompilieren, was mir dieses Wochenende auch bevorsteht :-((
Ein harzliches Glückauf
Tom vom Berg
Hallo,
Flock() blockt trotzdem weiter.
naja, wenn flock() für Dich der Rechte Weg ist, dann ist es eben Suse auch...
Da müsste ich also nun selber kompilieren, was mir dieses Wochenende auch bevorsteht :-((
Statt Dich zu freuen, endlich volle Kontrolle zu haben.
Noch einige Anregung zum ausprobieren: PHP in Module gliedern, ./configure-Argumente automatisieren, CFLAGS
Gruß aus Berlin!
eddi
Hello,
Statt Dich zu freuen, endlich volle Kontrolle zu haben.
Du siehst das falsch, denke ich!
Es ist keine Lösung, am OS vorbei zu entwickeln.
Filelocking, egal ob advisory oder, wenn das OS es kann, besser mandatory, ist eben Sache der Zugriffsschicht. Alle Methoden, die da nicht unumgehbar eingebaut sind, taugen in einem heterogenen Mutliuser-Netzwerkbetrieb überhaupt nichts.
Es muss sichergestellt sein, dass das OS dem Prozess auf die Finger klopft, wenn er etwas anfassen will, was ihn (momentan) nichts angeht. Deshalb ist die Auffassung, Windows wäre mit seinem mandatory Locking das antiqierte System und Unix wäre mit seinem advisory Locking viel fortschrittlicher, auch die falsche Auffassung. Mandatory ist die Weiterentwicklung :-)
Das einzige Problem dabei ist der Ressourcenfraß. Mandatory Locking bedarf eben einer File-Deskriptor-Table im Filesystem des OS, und einer zusätzlichen Kopie (von Auszugsdaten) für jeden Prozess, der damit arbeiten will. Das kostet eben Speicherplatz für jedes offene File, auch wenn im Moment gar nicht aktiv zugegriffen wird.
Und wenn man nun auch noch auf Satzebene herunter geht oder noch tiefer, dann wird es langsam kriminell.
Ein harzliches Glückauf
Tom vom Berg
Re:
Statt Dich zu freuen, endlich volle Kontrolle zu haben.
Du siehst das falsch, denke ich!
Ja, (so) denkst Du.
Es ist keine Lösung, am OS vorbei zu entwickeln.
Dem stimme ich zu. flock() gibt es schlichtweg für MS nicht, also analysiere ich mal, dass wir eh von unix-artigen oder -unartigen Systemen reden.
Filelocking, egal ob advisory oder, wenn das OS es kann, besser mandatory, ist eben Sache der Zugriffsschicht. Alle Methoden, die da nicht unumgehbar eingebaut sind, taugen in einem heterogenen Mutliuser-Netzwerkbetrieb überhaupt nichts.
Es fällt mir auf die Schnelle kein Linux℠ ein, was default ohne V IPC daher käme.
Es muss sichergestellt sein, dass das OS dem Prozess auf die Finger klopft, wenn er etwas anfassen will, was ihn (momentan) nichts angeht. Deshalb ist die Auffassung, Windows wäre mit seinem mandatory Locking das antiqierte System und Unix wäre mit seinem advisory Locking viel fortschrittlicher, auch die falsche Auffassung. Mandatory ist die Weiterentwicklung :-)
Das einzige Problem dabei ist der Ressourcenfraß. Mandatory Locking bedarf eben einer File-Deskriptor-Table im Filesystem des OS, und einer zusätzlichen Kopie (von Auszugsdaten) für jeden Prozess, der damit arbeiten will. Das kostet eben Speicherplatz für jedes offene File, auch wenn im Moment gar nicht aktiv zugegriffen wird.
Du bist noch bei Prozessen. Multithreading kam aber bereits in der Vergangenheit. flock() arbeitet nur mit _Prozessen_. Was machst Du zukünftig, wenn sich (endlich) auch PHP der threads bedient?
Semaphoren sind auch bei Debian da, flock() nach dem, was ich hier von Dir lesen muss, arbeitet aber nicht.
Es ist keine Lösung, am OS vorbei zu entwickeln.
Aha.
Gruß aus Berlin!
eddi
Dem stimme ich zu. flock() gibt es schlichtweg für MS nicht...
Okay, okay - ist überspitzt ;)