FreeBSD 8.0-RC2 und 8.0-RC3

He. So einfach ist das leider nicht. Kamikaze und mindestens eine andere Person hat das Problem, aber ich konnte es schlicht nicht reproduzieren. weder mit einem eigenen Kernel, noch mit seinem. Und nachdem er aktualisiert hatte, trat es auch nicht mehr so wirklich auf, obwohl da nichts angefasst wurde. Irgendwie beschwerte sich fsck zwar teilweise noch, aber das Dateisystem blieb heil.
 
Das Schreib-Problem ist inzwischen verbunden (ohne irgendwelche relevanten Endungen im CVS). Aber fsck_msdos schreddert intakte Dateisysteme.
 
Das mit dem USB-Stick ist mir auch mal passiert, allerdings ohne irgendwelche Tools dafür einzusetzen. An den FBSD gemountet, Datei drauf kopiert, unmount, zurück an die Win Büchse und siehe da :mad: alles wech.
War dann allerdings zu beschäftigt, um das Problem nochmal nachzustellen ;'(
 
USB-Boot funktioniert bei vielen Mainboards, aber nicht bei allen. Man fummelt da in -CURRENT noch dran rum, um eine Lösung zu finden, die auch wirklich überall funktioniert. Also, ausprobieren. :)
 
ich habs mal probiert, aber was dabei rauskam irritiert mich:
Code: 
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
SMP: AP CPU #1 Launched!
Root mount wainting for: usbus4 usbus3 usbus2 usbus1 usbus0
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
uhub0: 2 ports with 2 removable, self powered
ugen1.1: <Intel> at usbus0
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
uhub1: 2 ports with 2 removable, self powered
ugen4.1: <Intel> at usbus4
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus 4
Root mount wainting for: usbus4 usbus3 usbus2
Root mount wainting for: usbus4 usbus3 usbus2
Root mount wainting for: usbus4 usbus3 usbus2
uhub2: 8 ports with 8 removable, self powered
ugen2.1: <Intel> at usbus2
uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
uhub3: 2 ports with 2 removable, self powered
ugen3.1: <Intel> at usbus3
uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
uhub4: 2 ports with 2 removable, self powered
Root mount waiting for: usbus4
usb_alloc_device:1626: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT!
Root mount wainting for: usbus4
Root mount wainting for: usbus4
usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT!
Root mount wainting for: usbus4
Root mount wainting for: usbus4
usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT!
ugen4.2: <(null)> at usbus4 (disconnected)
uhub_reattach_port:440: could not allocate new device!
Trying to mount root from ufs:/dev/da0s4a

######## Festplatte schaltet sich von alleine ab ##########

ROOT MOUNT ERROR:
If you have invalid mount options, rebott, and first try the following from the loader prompt:

          set vfs.root.mountfrom.options=rw

and the remove invalid mount options from /etc/fstab.

Loader variables:
vfs.root.mountfrom=ufs:/dev/da0s4a
vfs.root.mountform.options=rw

[manual boot prompt]
mountroot> ?

List of GEOM managed disk devices:

Loader variables:
bei dem PR gabs keine errors ala USB_ERR_TIMEOUT etc.
liegt es jetzt an meiner festplatte oder meinem pc?
 
8.0-RELEASE wurde inzwischen - ich bin ein wenig dran - im SVN markiert. Sourceupdater können es sich schon seit Freitag Abend holen, alle anderen werden wie immer warten müssen. Eine offizielle, eigene News gibt es nach der Ankündigung.
 
Ich fahre inzwischen RELENG_8. Ich habe seit dem letzten Update noch keinen Reboot durchgeführt, aber das sollte ja heißen, dass das System jetzt -STABLE und nicht mehr -PRERELEASE getagt ist.

In RELENG_8 ist inzwischen übrigens der ATA über SCSI-Interface Kram eingeflossen. Ich hab's aber noch nicht ausprobiert.
 
Der ist in RELENG_8_0 auch schon drin. Allerdings noch in früheren Version. Nutzen würde ich beide noch nicht, dass wäre mir zu gefährlich. Soll ruhig erst noch ein wenig reifen, denn nichts ist übler als durch defekte Plattentreiber zerdepperte Dateisysteme :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben