PATH verandert na veranderen home directory

[Confusion]

Edit: de meeste informatie in deze startpost is waarschijnlijk irrelevant; zie de vierde post voor het probleem...

Ik loop tegen een vreemd probleem aan waarvan ik niet eens begrijp waar het vandaan zou kunnen komen. De situatie is als volgt: ik heb een nieuwe harde schijf gekocht en wil een aantal delen van mijn filesystem daar op zetten. Zo gaat mijn /home van hda6 naar hdc5. Hdc is gepartitioneerd en op hdc5 is een ext3 filesystem gemaakt. Ik kopieer mijn home directories van hda6 naar hdc5 met "cp -a /home/* /mnt/hdc5". Voorzover ik kan beoordelen is hdc5 nu identiek aan hda6. Ik unmount /home (is dus door geen enkel proces in gebruik) en mount hdc5 op /home (mount /dev/hdc5 /home, hij herkent dat het ext3 is). Voordat ik deze procedure begon kon ik als normale user met startx vanaf de command line naar KDE. Na deze procedure kan ik als normale user met startx niet meer vanaf de command line naar KDE. Startx keert terug met de foutmelding dat hij geen xinit kan vinden en roept iets in de trant van "make sure /usr/X11R6/bin is in your PATH". Vreemd genoeg staat die directory in de wel werkende situatie ook niet in mijn PATH.

Kortom: hoe kan het veranderen van de partitie waarop de home directory staat, wanneer de home directory met cp -a gekopieerd is tussen de partities, leiden tot een verandering in het PATH?

[ Voor 6% gewijzigd door Confusion op 07-07-2005 21:02 ]

[Confusion]

Hmmm, ik ben erachter waar het verschil in zat: na het wijzigen van de home directory, deed ik
'startx 2&> startx.log' om alle output naar die file te loggen, terwijl ik in de 'gewone' configuratie gewoon 'startx' gaf. Die eerste constructie gebruikte ik ook altijd toen ik net met X aan het stoeien was, om uit te vinden waar het misging. Ik heb alleen geen flauw idee waarom het redirecten van de error output samen met de standaard output naar een file een error "xinit: No such file or directory (errno 2): no program named "/usr/X11R6/bin/xterm" in PATH" zou moeten geven...

Edit:
Ehmm, WTF, als mijn /tmp van hda7 naar hdc6 verplaats krijg ik weer hetzelfde probleem...

Edit2:
Nog steeds niet opgelost. Kortom, eigenlijk dezelfde situatie als in mijn eerste post, maar nu met /tmp. Ik zorg dat niets /tmp gebruikt, kopieer /tmp met -a naar een andere partitie, unmount /tmp, mount de andere partititie als /tmp en in die nieuwe situatie kan ik X niet starten...

[ Voor 26% gewijzigd door Confusion op 07-07-2005 17:28 ]

[Parasietje]

Je hoeft niet eens /tmp te kopiëren. /tmp kan je, als er geen gebruikers zijn ingelogd of belangrijke services draaien, gewoon wissen...
Probeer eens je /etc/fstab te veranderen, zodat de nieuwe partities bij het booten worden gemount.

[Confusion]

Parasietje schreef op donderdag 07 juli 2005 @ 18:10:
Je hoeft niet eens /tmp te kopiëren. /tmp kan je, als er geen gebruikers zijn ingelogd of belangrijke services draaien, gewoon wissen...
Probeer eens je /etc/fstab te veranderen, zodat de nieuwe partities bij het booten worden gemount.

Ik heb geprobeerd te booten met hdc6 als nieuwe, lege /tmp en dat werkt niet. Als ik dan X afsluit, hdc6 unmount en de oude /tmp er weer aanhang, dan kan ik wel weer inloggen. Het moment waarop het fout gaat is wanneer ik met de gewone user vanaf de kdm login probeer in te loggen. Als het goed gaat krijg ik alleen een ander beeld; als het fout gaat verspringt de schermmodus, krijg ik even een zwart beeld en spring dan terug naar het kdm inlogscherm. Blijkbaar gaat er iets ernstig mis met die partitie, maar ik kan er niets verkeerd aan ontdekken.

Edit: ik heb hdc6 als ext2 en als ext3 geprobeerd en dat maakt niet uit. Ga nu andere partities als /tmp testen..

Edit2: Schijnbaar kan ik alle partities van hda en hdb als /tmp gebruiken, maar geen partities van hdc. Ik heb nu wel een hdc partitie als /home. Wazige toestand; ik zal wel iets simpels over het hoofd zien, of het zit op een diepte waarvan ik gewoon niks weet.

[ Voor 19% gewijzigd door Confusion op 07-07-2005 21:41 ]

[Confusion]

Het was een permissieprobleem, zoals ik misschien wel had moeten verwachten uit het feit dat er voor de root user niets aan de hand was, maar voor andere users wel. De nieuwe partitie werd op /tmp gemount met 0755 in plaats van de voor /tmp vereiste 1777. Dit was ook in bootprocedure zo, dus volgens mij heb ik nu geleerd dat de rechteninformatie voor de directory waar een partitie aan gekoppeld wordt in de partitie opgeslagen ligt en niet door het 'bovenliggende' filesystem wordt bepaald.

[M-ThijZ]

De meeste irritante probleempjes die ik tegenkomen zijn bij mij ook altijd permissie problemen. Maar ik denk altijd maar zo, beter een te strenge beveiliging dan een te slappe.