Schon merkwürdig. Suspend to Disk ging nicht mehr nach Monaten ungetrübter Freude. Immer die Fehlermeldung, mit Hal gäbe es ein Problem. Nun da ich ja wie im verlinkten Artikel beschrieben habe ein alternatives Suspend uswsusp benutze und leicht modifierte Scripte, dachte ich zuerst, klarer Fall, das wird wohl ein Update überschrieben haben.
Das wars aber nicht, sondern, swap war nicht mehr aktiviert. Die Sache mit den UUID scheint nicht mehr zu klappen. Ich habe swap mit mkswap neu angelegt und die neue UUID in fstab eingetragen, das half auch nicht.
root@Asus:~# swapon -a
swapon: cannot stat /dev/disk/by-uuid/dcf3d9b3-6ce2-4381-b265-dc7787bf80d4: No such file or directory
root@Asus:~# mkswap /dev/sda7
Setting up swapspace version 1, size = 3226988 kB
no label, UUID=6ca6c230-0579-4be3-912e-3f8119778157
root@Asus:~# nano /etc/fstab
root@Asus:~# swapon -a
swapon: cannot stat /dev/disk/by-uuid/6ca6c230-0579-4be3-912e-3f8119778157: No such file or directory
root@Asus:~# nano /etc/fstab
root@Asus:~# swapon -a
root@Asus:~# free
total used free shared buffers cached
Mem: 2075964 708456 1367508 0 37296 398684
-/+ buffers/cache: 272476 1803488
Swap: 3151352 0 3151352
Die Lösung: ich habe nun das Device in alt hergebrachter Weise angegeben, nun gehts wieder
Sag was du willst: Mir ist dieses neumodische Zeugs wie z.B. diese Unsitte mit den UUID's, HAL, DBUS, udev, devfs etc. einfach nur suspekt.
Da sagst du was Wahres! Ich bin im Hintergrund auch ab- und an daran einen neuen Kernel auszuprobieren, der startet auch nur mit der alten Methode und nicht mit den UUID. Sehr misteriös, das Ganze.
Nebenbei bemerkt hat mein Beitrag auch in diesem Forum eine abfällige Diskussion ergeben. Anscheinend sind wir nicht die beiden einzigen, die das nervt.
Der Trick an Linux/Unix war doch eigentlich sich (unter anderem) von undurchsichtigen Automatismen zu lösen. Desktop schön und gut, aber muß das sein? Oder besser noch den User bei der Installation fragen: Willste Automatik oder nicht?