Arch Linux

Wie kann man /usr vorbeugen

Siassei

Hallo,

bei einer Neuinstallation von ArchLinux, wo /usr eine eigene Partition ist, kommt ab dem zweiten Bootvorgang die Meldung
"/usr mount ..."
Auf gut Deutsch. /usr wurde nicht eingehängt. Gut, warum weiß ich jetzt. Aber wie umgehe ich das Problem?
1.) /usr und root eine einzige Partition. Pähm, das geht auf keinen Fall
2.) ??? Für einen guten Vorschalg, der auch in Zukunuft funktioniert, währe ich dankbar.

Gruß, Thomas

Kinch

Ist dir klar, dass man aufgrund dieses Postings dir unmöglich einen konstruktiven Ratschlag geben kann? Alles was man sagen kann ist: Lagere /usr in eine eigene Partition aus, wenn du es in eine eigene Partition willst/musst. Wenn du weißt, warum es nicht beim booten gemounted wird, dann beheb' das Problem irgendwie.

stigmayta

Siassei schrieb 1.) /usr und root eine einzige Partition. Pähm, das geht auf keinen Fall

Klar geht das.

Schreib bitte noch einmal was du willst. Langsam und detailliert. Ich verstehe absolut nichts von dem was du hier sagen möchtest.

GerBra

https://bbs.archlinux.org/viewtopic.php?pid=1006924

Greg

Siassei schrieb/usr und root eine einzige Partition. Pähm, das geht auf keinen Fall

Doch das geht. Sehr gut sogar!!!
Warum soll das bei dir nicht gehen?

Siassei

stigmayta schrieb
Siassei schrieb 1.) /usr und root eine einzige Partition. Pähm, das geht auf keinen Fall
Klar geht das.

Schreib bitte noch einmal was du willst. Langsam und detailliert. Ich verstehe absolut nichts von dem was du hier sagen möchtest.

Gestern war es wohl schon ein wenig zu spät. Was habe ich da geschrieben? :-)

Bei einer Neuinstallation von ArchLinux wird /usr auf eine eigene Partition (auf einer seperaten Festplatte) ausgelagert. Auf Grund der physikalischen Trennung der Partition root und /usr ist es nicht möglich /usr auf die root-Partition zu schieben.

Beim ersten Startvorgang nach dem Network-Installer funktioniert auch alles einwandfrei. Nach der Installation von einigen Tools kommt dann das Problem. Erste Nachricht auf dem Bildschirm
"... /usr is not mounted. This is not supported."

Ein interessanter Artikel hierzu: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Leider verstehe ich nicht den Grund, warum das Akzeptiert wird.

Ich suche jetzt nach einer Möglichkeit das Problem zu umgehen.

@GerBra Den Beitrag kannte ich schon und der letzte Beitrag erschüttert mich ein wenig
"Finally moved /usr into /(root). Alls well now and updated to the latest. Phew."
Gibt es keinen anderen Ausweg? In der offiziellen Wiki und Installationsanleitung wird nicht auf das Problem hingewiesen.

Ich suche zur Zeit nach einer Möglichkeit /usr als eigene Partition anzulegen und ArchLinux zu starten. In einigen Foren liesst man von einem eigenen ...ramfs. In wie weit ist dies eine sinnvolle Lösungen? Besonders im Hinblick auf zukünftige Updates, Kernel-Builds, ....

Hierzu muss es doch bereits eine fertige Lösung existieren. Es kann doch nicht sein, dass hunderte von Benutzer das Rad jedesmal neu erfinden.

Danke, Thomas

hydro

Der Workaround in #18 ist auch nicht akzeptabel? Hier steht mehr zu den Möglichkeiten in den Bootvorgang einzugreifen. Ich selbst habe keine separate /usr-Partition.

Siassei

hydro schriebDer Workaround in #18 ist auch nicht akzeptabel? Hier steht mehr zu den Möglichkeiten in den Bootvorgang einzugreifen. Ich selbst habe keine separate /usr-Partition.

Jupps, den hab ich wohl überlesen. Werde es heute noch testen. Danke.

GerBra

Siassei schrieb @GerBra Den Beitrag kannte ich schon und der letzte Beitrag erschüttert mich ein wenig
"Finally moved /usr into /(root). Alls well now and updated to the latest. Phew."
Gibt es keinen anderen Ausweg? In der offiziellen Wiki und Installationsanleitung wird nicht auf das Problem hingewiesen.

Nur zur Klarstellung: Die Meldung vom initrd/initramfs ist ja "nur" kosmetischer Art. Wenn du dir die entsprechende Stelle in /etc/rc.sysinit anschaust wirst du ja sehen, daß das auf den weiteren Bootverlauf keine Auswirkungen hat.

Ich teste gerade/heutabend/morgen mal was ggf. passiert oder für Workarounds...
Aktuell sehe ich (ungetestet) eigentlich keine Auswirkungen. Das System sollte booten.

Kurzgefaßt geht es ja darum:
Früher[tm], in der "guten alten Zeit, als /dev z.B. noch statisch war" <g> galt die Regel (egal ob mit oder ohne initrd gebootet wurde): Alle zum Boot notwendigen Dateien befinde sich in /dev, /bin, /sbin und /lib (also das Root-FS). Unter /usr befinden sich nur Userland-Bins/Libs/etc., die erst *nach* dem erfolgten Start von init (Prozeß 1) gebraucht würden. /usr konnte somit problemlos erst später über die fstab bzw. oftmals sogar zentral per NFS eingebunden werden.

U.a. durch udev und "neumodischer Kram" (=reevent wheel !) ist das scheinbar nicht mehr so strengent machbar, bzw. zukünftig nicht mehr "gewollt". Das "Problem" wird dann zu einem Problem wenn innerhalb des initrd (bzw. vor dem Mounten/fstab lokal oder remote) auf Binaries/Libs zugegriffen werden soll, die unterhalb /usr liegen.
In den aktuellen Hooks bei mkinicpio wird oftmals schon ein Binary "fest" ins initrd-Image "kopiert" (über die Funktion add_binary) um das zu umschiffen...

Inwieweit das aktuell und zukünftig zu einem echten Problem wird bleibt abzuwarten/auszutesten. Und wem man die Türen mit Protesten eintreten soll...

Macron

Hi,

mal kurz OT:

Warum möchte man /usr überhaupt vom / trennen ? EIne Trennung von /home oder /var ist mir ja noch logisch aber warum /usr ? Vorteil davon wäre zB ?

MfG Macron

GerBra

@Macron:
Zum einen das Argument "Sicherheit" (also /usr - oder sogar / auf read-only zu setzen beim Mounten). Das ist strittig/trügerisch, da Dateien im sog. Root-FS bzw. /usr eigentlich sowieso nur mit Rootrechten verändert werden können. Wenn ein Angreifer aber eh schon Root-Rechte hat, dann kan er auch das FS wieder mir read-write mounten... R/O würde also eher z.B. vor einem betrunkenen Admin schützen ;-)

Weiterverbreitet war/ist aber /usr (der hauptanteil an einer Linux-Install) z.B. übers Netzwerk den einzelnen Terminals/Arbeistplätzen zur Verfügung zu stellen. So mußten die Festplatten in den Clients nicht groß(=teuer) sein und es langt i.d.R. wenn der Admin die Userland-Programme einmal zentral aktualisierte. Somit ist gewährleistet das alle Clients den gleichen Softwarebestand/version haben...

Macron

Danke GerBra,

Jetzt wird nen Schuh draus! Macht natürlich voll Sinn via NFS / PXE sehe ich ein aber nicht wirklich auf nem Desktop oder ?

Soviel zu "Lernkurve & Arch" 😉

MfG Macron

GerBra

Mein Testsystem mit separatem /usr bootet ohne Probleme (allerdings keine Sonder-Hooks wie raid,lvm,crypt aktiv).
Ich werde nochmal genauer die Infos im .org-Thread und dem FDO-Link prüfen, und auch nochmal das /usr per NFS holen.

Die "rote Meldung" ist wie gesagt nur kosmetischer Natur (heißt halt nicht das alles aktuell und v.a. zukünftig so auch funktionieren wird).
//Edit: Und es bedeutet *NICHT* das /usr nicht gemountet würde oder der Boot sonstwie abgebrochen wird. Es wird nur geprüft ob zum aktuellen Zeitpunkt /usr/lib vohanden ist. Wenn nein, dann wird die meldung ausgegeben.

if [[ ! -a /usr/lib ]] ; then
  printf "${C_FAIL}/usr is not mounted. This is not supported.${C_OTHER}\n"
fi

Mehr ist da nicht....

Das ist ja auch keine Archlinux-spezielle "Gängelung" sondern eher eine gutgemeinte Warnung das spät-gemountetes /usr eher Probleme als Nutzen macht und deswegen nicht "offiziell unterstützt" wird - wohlwissend das die Ursache bei den Upstream-Entwicklern liegt...

<Motzmodus>Den "Desktop" auf sowas wie Tablets, Ei-Phones etc. zu haben ist vielen wohl heutzutage wichtiger als Dinge wie Netzwerkfunktionalität des X-Servers etc... Sollen die Distributionen doch sehen wie sie mit dem gaaaanz neuen - ultimativen - Konzept zurechtkommen. Nächste Woche kommt das neue ultimative Konzept... Erinnert mich an die beliebten "10 größten XXX aller Zeiten"-Sendungen. Und an Dschungelcamp.</Motzmodus>

Siassei

Siassei schrieb
hydro schriebDer Workaround in #18 ist auch nicht akzeptabel? Hier steht mehr zu den Möglichkeiten in den Bootvorgang einzugreifen. Ich selbst habe keine separate /usr-Partition.
Jupps, den hab ich wohl überlesen. Werde es heute noch testen. Danke.

Danke, zwei Hooks registriert und schon liefs :-)

@GerBra Ein minimal GNU/Linux-System (entspricht Arch nach Installation) kann ohne Probleme /usr beim Bootvorgang mounten. Erst mit einigen zusätzlichen Programmen funktioniert es nicht mehr. Was genau das Problem verursacht, weiß ich nicht und möchte es auch nicht. Irgendwas, was in meinen Installskript steht :-)

Trennung von /usr und root?
@GerBra hat es bereits erwähnt. Trennung von Grundsystem (Konfiguration) und Software.

Danke an alle.

GerBra

Siassei schrieb @GerBra Ein minimal GNU/Linux-System (entspricht Arch nach Installation) kann ohne Probleme /usr beim Bootvorgang mounten. Erst mit einigen zusätzlichen Programmen funktioniert es nicht mehr. Was genau das Problem verursacht, weiß ich nicht und möchte es auch nicht. Irgendwas, was in meinen Installskript steht :-)

Wie äußerte sich denn bei dir das "es" nicht funktionierte? Das hast du ja bisher nicht verraten ;-)
Wenn ich das Problem "vollumfänglich" <g> verstanden habe kann es nur um das booten bzw. den Ablauf in/mit der initial ram disk zu tun haben. Wenn die Daemons gestartet werden oder nach init die inittab abgearbeitet wird - dann ist (egal wie) /usr schon vorhanden. Entweder als lokales Device über die fstab gemountet (->rc.sysinit) oder bei NFS nach dem netfs-Daemon (per NFS ist dann der Sonderfall, da hier halt das Netzwerk laufen muß, aber darum geht es bei dem Thread/deinem Problem ja auch nicht).

Ich sehe ad hoc nicht, was der Workaround-Hook verbessern würde was nicht auch "normal" per mount in der fstab möglich wäre...

hydro

GerBra schrieb Ich sehe ad hoc nicht, was der Workaround-Hook verbessern würde was nicht auch "normal" per mount in der fstab möglich wäre...

Ich habe da jetzt auch nicht den Überblick, aber dieser Liste zufolge werden die Partitionen gemäß fstab ja erst relativ spät gemountet. Die Hooks sorgen dafür, dass /usr ebenso wie das rootfs bis vor dem fsck readonly gemountet ist, udev kann also auf /usr zugreifen, falls nötig.

GerBra

Nachtrag: mkinitcpio Version 0.8.2 bringt Vorkehrungen um ein separates /usr auch wieder über initrd/udev ("early userspace") einbinden zu können.
Quelle: http://mailman.archlinux.org/pipermail/arch-general/2012-January/024124.html

//Edit: Ich mußte beim Suchen nach dem Thread wieder über den Titel desselben schmunzeln, könnte man glatt eingerahmt ins Admin-Büro hängen.... ;-) (Gegen $USER gibt es sicher doch auch was von R*tiopharm...)
//Edit2: ich liebe z.B.: kill -USR1 oder kill -USR2 ;-)