ubuntuusers.de

Saddy schrieb:

Also per by-id würde es auch nicht gehen, denn sdb1 wird ebenso wenig von initramfs gelistet, es sah nur erst so aus. (Sie müsste eine ID ähnlich ATA SAMSUNG HD502IJ haben).

Das dachte ich mir schon...

Ich werde mal gucken wie ich Sachen bei Launchpad eintrage.

Bitte! Denn wenn ich es richtig sehe werden selbst nach erfolgreichem Boot die devices getauscht, mal so:

/dev/sda1: UUID="1A5093135092F4AB" TYPE="ntfs" 

und Ubuntu startet trotzdem (siehe Dein Anhang von initramfs); mal so:

/dev/sda1: UUID="b8116d40-b60a-48bf-a387-e525095c44f7" TYPE="ext3"

und Ubuntu startet "richtig"...

Da nützt einem die UUID nichts, wenn die zuordnung von Device und UUID nicht funktioniert.

Nach meinem dafürhalten liegts definitiv am init von initramfs ▶ http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.0/suselinux-manual_de/manual/cha.boot.html

Bin mal gespannt, was die Leute von Launchpad sagen. Bitte poste den Threadlink dazu!

Saddy schrieb:

oliuntu schrieb:

Schau mal, dieser Post beschreibt, wie das jemand mit einer IDE-SATA-Kombination geschafft hat: http://www.linuxquestions.org/questions/showthread.php?p=3349090#post3349090

O weih, das versteh ich ja nicht ansatzweise, was er da macht...

Das ist eine Anleitung, mit der du dir deine eigene initrd backen kannst, die dazu die richtigen Module lädt. Damit müsste sich dein Problem ausbügeln lassen.

Das ist eine Anleitung, mit der du dir deine eigene initrd backen kannst, die dazu die richtigen Module lädt. Damit müsste sich dein Problem ausbügeln lassen.

Naja eh ich da jetzt Stunden investiere boote ich lieber den funktionierenden alten Kernel 2.6.24-19-generic, bis sich die Leute von Launchpad darum kümmern.

Saddy schrieb:

Naja eh ich da jetzt Stunden investiere boote ich lieber den funktionierenden alten Kernel 2.6.24-19-generic, bis sich die Leute von Launchpad darum kümmern.

Kann ich nachvollziehen, da muss man schon etwas rumfrickeln, bis das klappt.

So, das ist der Launchpad-Link: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/311927

Saddy schrieb:

Naja eh ich da jetzt Stunden investiere boote ich lieber den funktionierenden alten Kernel 2.6.24-19-generic, bis sich die Leute von Launchpad darum kümmern.

Hättste auch schon eher sagen können, das der Fehler nur mit dem neueren Kernel passiert... 😐 Saddy schrieb:

So, das ist der Launchpad-Link: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/311927

Sehr schön! Danke. Dann warten wir mal die Zeit ab...

Jippy nach den neuesten Updates startet der Xserver nicht mehr mit dem alten Kernel. Als der neue dann mal startete kam beim Boot 1x so etwas wie "auto configuring nvidia" irgendwas. Kann ich das irgendwie manuell ausführen unter dem alten Kernel? (Neuen Thread aufmachen?)

Saddy schrieb:

Jippy nach den neuesten Updates startet der Xserver nicht mehr mit dem alten Kernel.

Herzlichen Glückwunsch... 😉

Als der neue dann mal startete kam beim Boot 1x so etwas wie "auto configuring nvidia" irgendwas. Kann ich das irgendwie manuell ausführen unter dem alten Kernel?

Hast Du nicht die nvidia-settings? Oder : sudo dpkg-reconfigure xserver-xorg

(Neuen Thread aufmachen?)

Erst mal die Suche bemühen... Dann Thread mit aktueller /etc/X11/xorg.conf und evtll /var/log/xorg.0.log im (Nopaste-service) posten.

Hi saddy!

Hier hat einer ne Lösung für das Problem gefunden. Banal... aber hast Du mal die Master/Slave jumper überprüft?

Ja, das könnte ich mal checken. Aber leider erst in 2 Wochen solange man PC-Hardware nicht fernadministrieren kann ☺

Nun hat es doch etwas länger gedauert. Aber nein - an den Jumpern liegt es leider nicht, nur meine CD-Laufwerke waren falsch gejumpert 😉

Und bei Launchpad rührt sich anscheinend niemand...

Ich hatte dasselbe Problem. Am Anfang wurde die Partition bei jedem zweiten Booten gefunden, dann ca. bei jedem dritten, ... bis es fast gar nicht mehr ging. Was ich da alles ausprobiert und gesucht habe ... Als ich den frisch gekauften neuen S-ATA_Controller einbauen und testen wollte, fiel mir auf, dass der S-ATA-Kabel-Stecker nicht richtig fest am S-ATA-Controller eingesteckt war.

Kontrolliere mal die S-ATA-Stecker an der S-ATA-Platte und am S-ATA-Controller auf festen Sitz!

Hallo,

habe ein ähnliches Problem, und zwar bekomme ich beim botten die Meldung: /dev/disc/by-uuid/71A1-0F31 existiert nicht [fail]

er bootet aber trotzdem ganz normal. Hätte aber den Fehler gerne weg.

blkid

/dev/sda1: UUID="b4b6dceb-0d74-4021-b5b7-650d8babf9c1" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda2: UUID="4DE953087682C642" TYPE="ntfs" 
/dev/sda3: TYPE="swap" UUID="caa4c8df-faea-4c8e-bf48-1092240912ae" 
/dev/sda4: UUID="33c0ef86-19b9-4564-b7cd-30322ec9defb" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdc1: SEC_TYPE="msdos" LABEL="EOS_DIGITAL" UUID="0000-0000" TYPE="vfat" 
/dev/sdb2: LABEL="extern-ext3" UUID="c6fe44c4-d22e-4810-afbd-4944cf937f40" SEC_TYPE="ext2" TYPE="ext3" 
/dev/mmcblk0p1: SEC_TYPE="msdos" UUID="FC30-3DA9" TYPE="vfat" 
/dev/sdb1: UUID="378E-13C4" TYPE="vfat" SEC_TYPE="msdos" LABEL="EXTERN -FAT" 

menu.lst

title		Ubuntu 8.10, kernel 2.6.27-7-generic
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.27-7-generic root=UUID=b4b6dceb-0d74-4021-b5b7-650d8babf9c1 ro quiet splash 
initrd		/boot/initrd.img-2.6.27-7-generic
quiet

hatte mal SATA auf ATA und dann wieder eingeschaltet, kann es damit zusammenhängen? bin für Lösungsvorschläge dankbar.

goaran schrieb:

habe ein ähnliches Problem, und zwar bekomme ich beim botten die Meldung: /dev/disc/by-uuid/71A1-0F31 existiert nicht [fail]

er bootet aber trotzdem ganz normal.

71A1-0F31 ist UUID einer FAT32-PArtition. Vllt. steht's noch so in /etc/fstab weil du deine externe Platte neu formatiert hast, und UUID in /etc/fstab nicht angepasst hast?

hmm, aber wieso sollte ich die Externe da mal eingetragen haben? wenn ichs einfach lösche tut es jedenfalls...