Den frie kafeen

[Sokkalf™]

En tommelfingerregel er; er det billig, er det "hardware"-RAID, dvs, RAID settes opp i kontrolleren, men håndteres av driveren. Er det dyrt, er det "ekte" hardware-RAID, som ikke bryr seg noe om det underliggende OSet. Sånne "ekte" løsninger koster gjerne flere tusen, og er ikke noe man finner integrert i hovedkort beregnet på "vanlige folk".

[Dy§no]

En tommelfingerregel er; er det billig, er det "hardware"-RAID, dvs, RAID settes opp i kontrolleren, men håndteres av driveren. Er det dyrt, er det "ekte" hardware-RAID, som ikke bryr seg noe om det underliggende OSet. Sånne "ekte" løsninger koster gjerne flere tusen, og er ikke noe man finner integrert i hovedkort beregnet på "vanlige folk".

Dyrt var det ikke så da sitter jeg med "hardware"-RAID som bryr seg om oset. Dropper derfor dette helt, tror ikke det ville være så mye å hente uansett; Ubuntu er rimelig rask uansett og det skal mye til for å redde vista som er bøtte tregt... Takk for oppklarende svar:-)

[jorgis]

Ellers kan du bare bruke "eject /dev/cdrom"

 

Hvis du bare har ett drev, holder det med bare "eject".

[j--]

Hvordan gå frem for å finne ut hva som skaper dette rare problemet.

 

Distro: Ubuntu 7.10

La merke til at ~nautilus-debug-log.txt hopper _veldig_ i filstørrelse innen veldig korte tidsrom. Med watch -n.2 ls -lh /home/clvn/nautilus-debug-log.txt har jeg kommet frem til at fila blir fylt opp med data (~10M-30M) ca. hvert 5. sekund, og deretter synker med ~10M i sekundet. Dette skjer nå konstant.

 

Noen som har hørt om noe lignende/vet grunnen? Hadde vært morsomt å funnet hva som er feil, og ville vært fint å få sendt inn en bug-rapport på det óg

[Frysning]

Hvorfor fungerer ikke automount i fluxbox? Når det gjør det i gnome? Er det ikke dbus og hal som tar seg av det, uavhengig av gnome?

[Sokkalf™]

Hvordan gå frem for å finne ut hva som skaper dette rare problemet.

 

Distro: Ubuntu 7.10

La merke til at ~nautilus-debug-log.txt hopper _veldig_ i filstørrelse innen veldig korte tidsrom. Med watch -n.2 ls -lh /home/clvn/nautilus-debug-log.txt har jeg kommet frem til at fila blir fylt opp med data (~10M-30M) ca. hvert 5. sekund, og deretter synker med ~10M i sekundet. Dette skjer nå konstant.

 

Noen som har hørt om noe lignende/vet grunnen? Hadde vært morsomt å funnet hva som er feil, og ville vært fint å få sendt inn en bug-rapport på det óg

 

Noe som kunne vært litt interessant å vite er hva den fyller den loggfila med. Kanskje det kan gi et hint.

[olear]

Hvorfor fungerer ikke automount i fluxbox? Når det gjør det i gnome? Er det ikke dbus og hal som tar seg av det, uavhengig av gnome?

Noe må spørre D-BUS om info. I GNOME er dette Nautilus, i KDE er dette Konqueror, i XFCE er det Thunar. Fluxbox er bare en WM.

[Sokkalf™]

Hvorfor fungerer ikke automount i fluxbox? Når det gjør det i gnome? Er det ikke dbus og hal som tar seg av det, uavhengig av gnome?

 

Jeg er ikke 100% sikker, men jeg tror at Gnome/KDE/etc bare "samarbeider" med DBus/HAL. Dvs, HAL tilbyr en interface som DEene benytter seg av for å mounte devices. Tror ikke Fluxbox inkluderer noe sånt, så da må du nok finne en tilleggsløsning. Kanskje ta en titt på autofs, har ikke erfaring med den selv, men høres litt ut som det er noe sånt du trenger.

 

Edit: olear slo meg på målstreken.

Endret 7. november 2007 av Sokkalf^

[olear]

Selv synes jeg Thunar går greit sammens med Fluxbox. Det er heller ingen som stopper deg i å f.eks kjøre konqueror som skrivebord i Fluxbox. Mulighetene er mange

Endret 7. november 2007 av olear

[BarteBaluba]

Thunar og *box er tingen:)

[luser32]

Ellers kan man jo også bruke ivman:)

[j--]

Hvordan gå frem for å finne ut hva som skaper dette rare problemet.

 

Distro: Ubuntu 7.10

La merke til at ~nautilus-debug-log.txt hopper _veldig_ i filstørrelse innen veldig korte tidsrom. Med watch -n.2 ls -lh /home/clvn/nautilus-debug-log.txt har jeg kommet frem til at fila blir fylt opp med data (~10M-30M) ca. hvert 5. sekund, og deretter synker med ~10M i sekundet. Dette skjer nå konstant.

 

Noen som har hørt om noe lignende/vet grunnen? Hadde vært morsomt å funnet hva som er feil, og ville vært fint å få sendt inn en bug-rapport på det óg

 

Noe som kunne vært litt interessant å vite er hva den fyller den loggfila med. Kanskje det kan gi et hint.

Den består nesten utelukkende av linjer identiske med denne:

0x87535a0 2007/11/07 11:29:23.6794 (USER): debug log dumped due to signal 11

 

En relativt kryptisk linje..

[Sokkalf™]

Signal 11 betyr at noe kræsjer ihvertfall.

[Frysning]

Greit, jeg tester ivman nå. Det fungerer på cd og dvd. Skal få til auto start av rox også. Meeeeen, usbsticken klarer den ikke å mounte. Ivman bruker pmount, jeg har listet minnepinnen (/dev/sdb1 og /dev/sdb) i /etc/pmount.allow. Det ser ikke ut til å hjelp, hele poenget med pmount er jo å tillate users å mounte. Noe den ikke klarer, fantastisk. Noen som har noen ide? cd og dvd går fint, kun minnepinnen jeg ikke får til.

Alle står også listet i fstab. Og hvordan jeg kan mounte cd/dvd med pmount uten at de er listet i pmount.allow med en vanlig bruker er også mystisk.

Endret 7. november 2007 av Frysning

[luser32]

Går ut ifra at brukeren er med i plugdev?

[Frysning]

Ingen gruppe som heter plugdev o.O?

[Dy§no]

Kom over denne tråden her(ikke min); som dere ser går prosessor kraftig opp og ned, selv om vedkommende ikke kjører noen tunge programmer. Hva kan årsaken være - tilsvarende skjer hos meg.

Endret 7. november 2007 av Dy§no

[luser32]

Hmm, nå aner ikke jeg åssen distro du sitter på. Men de jeg har vært borti så må brukeren være medlem av plugdev-gruppen. Så du kan jo eventuelt prøve å lage en plugdev-gruppe, legge til brukeren og logge ut og inn.

[Frysning]

My bad, glemte noen params bak linjen i fstab. Nå fungerer ivman veldig bra. <3 <3 <3

[Sokkalf™]

Kom over denne tråden her(ikke min); som dere ser går prosessor kraftig opp og ned, selv om vedkommende ikke kjører noen tunge programmer. Hva kan årsaken være - tilsvarende skjer hos meg.

 

Sjekk med "top"-kommandoen i terminal om du kan se hvilken prosess som bruker CPU. Sjekk også hvor CPUen brukes :

Cpu(s): 12.9%us,  6.0%sy,  0.0%ni, 79.8%id,  0.0%wa,  0.7%hi,  0.7%si,  0.0%st

Her er spesielt "wa" (IOwait) interessant. Er det mye CPU-bruk på IOWait kan det skyldes et hardware- eller driverproblem.