# Dateisystemfehler wegen Baselayout-Update?

## sprittwicht

Ich habe bis jetzt auf 2 Rechnern das Baselayout-Update durchgeführt, auf beiden kam es zu Problemen beim Runterfahren (des noch laufenden "alten" Systems).

Der letzte Schritt, das Unmounten bzw. Read-only-Mounten des Dateisystems schlug auf beiden Rechnern fehl (einer ext3, der andere ext4), beim ext4 war nach dem Neustart das Dateisystem hinüber und das neue Baselayout führte einen Dateisystemcheck mit diversen Fehlermeldungen durch. Anscheinend war die Reparatur / Journal Replay erfolgreich, trotzdem hab ich jetzt eine gewisse Angst weitere Rechner zu updaten.

Noch jemand mit ähnlichen Beobachtungen, hab ich was falsch gemacht?

----------

## mrsteven

War bei mir auch so, kaputtgegangen ist aber dank Journal auch nichts. Trotzdem irgendwie bedenklich, das ja.

Eine Idee wäre es, das Update auf baselayout 2 von einer LiveCD aus durchzuführen (chroot ins System auf der Platte  :Arrow:  Update durchführen  :Arrow:  etc-update  :Arrow:  chroot verlassen  :Arrow:  Dateisystem aushängen). Allerdings ohne Gewähr.

----------

## dtmaster

Ich habe vor zwei tagen auch auf baselayout geupdatet. 

Habe 4 HDD's ins System eingehängt. Bei mir lief alles mehr als reibungslos. Bisher konnte ich keine Probleme Feststellen. Mein System ist amd64.

----------

## Randy Andy

Hi Leute.

Genauer gesagt lags wohl eher an dem openrc Update auf 0.8.2-r1, auch wenn das bei euch vielleicht zeitgleich eintraf.

Bei mir jedoch nicht, da ich komplett auf unstable arch (~) bin.

Beleg:

```

[I] sys-apps/baselayout

     Available versions:  1.12.14-r1 (~)2.0.1-r1 2.0.2 {bootstrap build static unicode}

     Installed versions:  2.0.2(18:59:45 20.03.2011)(-build)

     Homepage:            http://www.gentoo.org/

     Description:         Filesystem baselayout and init scripts

[I] sys-apps/openrc

     Available versions:  (~)0.6.8 (~)0.7.0 (~)0.8.2 0.8.2-r1 **9999 {debug elibc_glibc kernel_FreeBSD kernel_linux ncurses pam selinux unicode}                                                                                                              

     Installed versions:  0.8.2-r1(14:54:41 29.04.2011)(elibc_glibc kernel_linux ncurses pam unicode -debug -kernel_FreeBSD -selinux)                                                                                                                         

     Homepage:            http://www.gentoo.org/proj/en/base/openrc/

     Description:         OpenRC manages the services, startup and shutdown of a host

```

Mir ist das demnach also erst nach dem update von openrc aufgefallen, das er beim runterfahren nicht unmounten konnte, Probleme hat es auf den bisher 3 aktualisierten Rechnern deshalb nicht gegeben. 

Sonst wär ich aber auch von dem ext4 journaling schwer enttäuscht, das bei mir bisher trotz aller Unkenrufe und Warnungen aus der Vergangenheit, bisher noch nie einen Dateiverlust nach sich gezogen hatte.

Es handelte sich dabei um 1 x x86_64 und 2x x86 Systeme.

Gruß, Andy.

----------

## Max Steel

Mein Update auf Baselayout 2 ist auch schon etwas her, aber hier gab es noch nie ein Problem.

----------

## Josef.95

Hmm.., bei dem Update auf openrc-0.8.2-r1 gab es aber soweit ich das sehe nur ein fix für die local.d migration

siehe im Changelog  *Quote:*   

> *openrc-0.8.2-r1 (28 Apr 2011)
> 
>   28 Apr 2011; William Hubbs <williamh@gentoo.org> +openrc-0.8.2-r1.ebuild:                                                                 
> 
>   Revision bump for local.d migration fix

 

Mir ist aber auch nicht aufgefallen das es beim runterfahren Probleme mit den aushängen der Laufwerke gab, das mag aber daran liegen das ich aktuell local gar nicht mit im Runlevel habe.

Eventuell könnte man diesem Problem ja aus dem weg gehen indem man /etc/init.d/local vor dem Update stoppt?!

----------

