Laatst las ik op opensuse news dat YAST, en dan in het bijzonder partitionering, zou worden opgewaardeerd. Wellicht is dat de oorzaak van het volgende probleem? :
Op mijn machine met Tumbleweed is geen van de externe harde schijven meer benaderbaar via mijn externe usb Sharkoon bay.
Ik heb 5 losse schijven oplopend in grootte van 250 gb tot 2TB, Allen NTFS geformatteerd.
Bij elk van deze schijven krijg ik bij het op starten van de bay wanneer ik kies voor bestandsbeheerder “Kon dit apparaat niet aankoppelen”
Ik schrok me rot want daar staat mijn totale digitale historie op!
Knoop ik de bay echter aan mijn Leap 42.3 machine dan is er geen vuiltje aan de lucht. Alles koppelt netjes aan en is ook gewoon leesbaar/beschrijfbaar. Gelukkig maar!
Terug naar de Tumbleweed machine.
ik heb in konsole ff wat losgelaten om wat meer info mee te geven
kanux@kpch:~> ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 28 jan 13:03 **/dev/sdb**
kanux@kpch:~>
en
kanux@kpch:~> mount | grep '/dev '
devtmpfs on **/dev **type devtmpfs (rw,nosuid,size=8141052k,nr_inodes=2035263,mode=755)
kanux@kpch:~>
Wat is de reden dat ik op mijn Leap WEL en Tumble NIET de externe schijf kan benaderen?
Volgens je verhaal heb je (minstens) 5 schijven. Waarom je alleen laat zien dat /dev.sdb bestaat is niet helemaal duidelijk. Laten we eerst eens een overzicht maken:
Dat gaat niet Henk, de sharkoon kan slechts 1 schijf per keer bevatten. Ze zijn dus niet permanent op het systeem aangesloten.
Afhankelijk van wat ik wil veilig stellen pak ik een harddisk uit de la, prik die in de Sharkoon, zet um aan en mount um dan op dezelfde manier als een usb stick. Hij geeft dezelfde melding op elke disk die ik erin prik.
In mijn Tumble systeem zit een werkende Tumbleweed op mijn ssd, updates t/m afgelopen vrijdag incluis
kanux@kpch:~> ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 28 jan 11:54 **/dev/sda**
brw-rw---- 1 root disk 8, 1 28 jan 11:54 **/dev/sda1**
brw-rw---- 1 root disk 8, 2 28 jan 11:54 **/dev/sda2**
brw-rw---- 1 root disk 8, 3 28 jan 11:54 **/dev/sda3**
brw-rw---- 1 root disk 8, 4 28 jan 13:51 **/dev/sda4**
kanux@kpch:~>
De Sharkoon staat momenteel niet aangekoppeld, vandaar alleen de sda
Ik snap dat je maar één zo’n extra schijf tegelijk kan hebben. Dan heb je er dus twee maximaal. Maar dat willen we dan ook zien, niet als er niets in zit.
Dus graag een schijf in het systeem dat het “niet doet” en dan weer
ls -l /dev/sd*
En als het even kan, zonder die kleurtjes. ik kan het zo niet lezen.
kanux@kpch:~> ls -l /dev/sd*brw-rw---- 1 root disk 8, 0 28 jan 20:27 /dev/sda
brw-rw---- 1 root disk 8, 1 28 jan 20:27 /dev/sda1
brw-rw---- 1 root disk 8, 2 28 jan 20:27 /dev/sda2
brw-rw---- 1 root disk 8, 3 28 jan 20:27 /dev/sda3
brw-rw---- 1 root disk 8, 4 28 jan 20:27 /dev/sda4
brw-rw---- 1 root disk 8, 16 28 jan 20:28 /dev/sdb
brw-rw---- 1 root disk 8, 17 28 jan 20:28 /dev/sdb1
kanux@kpch:~>
Overigens blijkt dat niet alleen de schijven maar ook usb sticks hetzelfde op te leveren: “Kon dit apparaat niet aankoppelen”
kanux@kpch:~> ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 29 jan 10:47 /dev/sda
brw-rw---- 1 root disk 8, 1 29 jan 10:47 /dev/sda1
brw-rw---- 1 root disk 8, 2 29 jan 10:47 /dev/sda2
brw-rw---- 1 root disk 8, 3 29 jan 10:47 /dev/sda3
brw-rw---- 1 root disk 8, 4 29 jan 10:47 /dev/sda4
brw-rw---- 1 root disk 8, 16 29 jan 10:47 /dev/sdb
brw-rw---- 1 root disk 8, 17 29 jan 10:47 /dev/sdb1
kanux@kpch:~>
en
kanux@kpch:~>
kanux@kpch:~> su -l -c 'mount /dev/sdb1 /mnt'
Wachtwoord:
kanux@kpch:~>
en
kanux@kpch:~> mount | grep sdb/dev/sdb1 on /mnt
type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
kanux@kpch:~>
en
kanux@kpch:~> ls -l
/mnttotaal 1726976
-rwxr-xr-x 1 root root 434 15 jun 2016 10-monitor.conf
-rwxr-xr-x 1 root root 339480290 23 mei 2016 Alexander.avi
-rwxr-xr-x 1 root root 871075840 22 mei 2016 Alexander.vob
drwxr-xr-x 3 root root 32768 19 mei 2017 Bitwig
drwxr-xr-x 6 root root 32768 13 dec 2016 Dagmar
drwxr-xr-x 11 root root 32768 25 okt 12:51 Es
drwxr-xr-x 2 root root 32768 11 sep 2016 Filmopnames
-rwxr-xr-x 1 root root 106 9 jun 2016 fix-resolution.desktop.desktop
-rwxr-xr-x 1 root root 145 9 jun 2016 fix-resolution.sh
drwxr-xr-x 4 root root 32768 19 okt 20:38 Kodi
-rwxr-xr-x 1 root root 204 10 jun 2016 lightdm.conf
drwxr-xr-x 4 root root 32768 23 mei 2017 OpenSUSE
drwxr-xr-x 2 root root 32768 22 mei 2016 Pa
-rwxr-xr-x 1 root root 278535102 22 mei 2016 PaOverzicht.odp
-rwxr-xr-x 1 root root 278634548 22 mei 2016 PaOverzicht.pptx
-rwxr-xr-x 1 root root 39293 9 jun 2016 resolutie.pdf
drwxr-xr-x 2 root root 32768 3 dec 2014 System Volume Information
-rwxr-xr-x 1 root root 26019 15 jun 2016 tankmap.odt
drwxr-xr-x 10 root root 32768 16 mei 2017 TTM
drwxr-xr-x 2 root root 32768 20 jan 18:35 TV
drwxr-xr-x 2 root root 32768 24 mei 2016 VIDEO_TS
kanux@kpch:~>
Interessant, nu laat ie zich wel mounten, ook via GUI
Na herstart niet via GUI wel indien ik via konsole de stick weer heb gemount.
Check met meerdere schijven gedaan met hetzelfde resultaat
Wat kan ik doen om dit ook weer standaard via GUI voor elkaar te krijgen?
Zo zie je maar weer dat je uit het gedrag van een GUI geen conclusies betreffende het systeem kunt trekken. De file systemen op de partities op die schijven/sticks zijn dus wel degelijk aan te koppelen in tegenstelling tot je bewering in the titel vandeze draad ;).
Maar nu, inderdaad, de GUI schijnt de eindgebruiker niet de normale akties op te leveren.
Terug naar je eerste beschrijving in post #1. Je zegt daar:
Bij elk van deze schijven krijg ik bij het op starten van de bay wanneer ik kies voor bestandsbeheerder "Kon dit apparaat niet aankoppelen
Dat is een beetje vaag. Je vertelt niet eens welke desktop je gebruikt!
En betekent "wanner ik kies vooR’, dat er ergens (waar?) iets te kiezen valt?
In tegenstelling to de kommando regel, waar je door kopieëren/plakken tussen CODE heel precies kunt laten zien wat je doet en ziet, is dat met de GUI veel lastiger, tenzij je een hoop screenschots maakt en post. Beschrijf dus bij een GUI probleem altijd zo zorgvuldig mogelijk wat he gebruikt, wat er gebeurt en wat je doet. Ga er maaar van uit dat anderen iets heel anders doen en dus niet automatisch jouw gedachtengang begrijpen.
P.S.
Ik denk dat je de eerste vraag van Knurpht wel over kunt slaan. Het is intussen duidelijk dat de systeemkant prima werkt.
Maar de tweede (over hoe update je TW), wel graag beantwoorden.
Vanuit jouw positie met de kennis die jij hebt heb je volkomen gelijk.
Ik ben echter een gebruiker die vertrouwd op GUI (KDE als enige desktop)
Helaas ontbeer ik de kennis die jij wel hebt aangaande het onderliggende systeem.
Vanuit mijn gebruikerspositie kan ik met GUI mijn sticks/schijven niet op de eenvoudige gebruikersmanier opstarten, en dat voelt wel degelijk als NIET kunnen opstarten.
Terug naar de vragen:
Updaten doe ik via konsole met sudo zypper dup (Updates van vandaag zijn ook verwerkt)
De omschrijving wat ik doe:
Plaatsen stick of schijf
KDE antwoord met pupup van apparaatmelder en vraagt wat ik wil doen
openen met bestandsbeheerder
digikam
gwenview
Ik kies voor openen met bestandsbeheerder en daar verschijnt de opmerking “Kon dit apparaat niet aankoppelen”
Helaas hebben de recente updates daar geen verandering in gebracht.
Das correct, sticks en schijven laten zich op de door Henk getoonde manier aankoppelen.
Op het moment van antwoorden had ik wel een stick voorhanden maar geen schijf, vandaar FAT.
Overigens ben ik zelf geen Tumbleweed gebruiker en kan dus niet proberen jouw probleem na te doen.
Ik ben hier voornamleijk ingesprongen om je snel een reaktie te geven en om je verhaal technisch terug te brengen tot het pijnpunt. Vanaf nu kunnen beter TW gebruikers gaan helpen met verklaren waarom Leap wel wekt en TW eerder ook, en toch de forums niet bol staan van mensen die hetzelfde probleem hebben.
Ik draai wel Tumbleweed, en heb dit soort issues niet met externe schijf of stick. Wat gebeurt er als je je gebruiker lid maakt van de groep ‘disk’ ?
Kun je ook je /etc/fstab 's laten zien ?
En toch graag output van dmesg -w terwijl je de bay aansluit/aanzet en probeert de schijf erin te mounten
Ik snap je helemaal, had er even wat motivatie bij kunnen zetten. Heb nog niet zo lang geleden een server met een hotswappable bay onderhanden gehad, en dat ding werkte met Leap 42.2 niet helemaal OK ( reboot nodig ) 42.3 helemaal niet en Tumbleweed wel. Door ‘dmesg -w’ kwam ik erachter dat het een permissie probleem was met een extra device entry, niet voor de disks, maar voor de bay zelf. Ik kan 't niet nakijken helaas. Als ik 't me goed herinner heb ik ergens een udev rule toegevoegd, Heb 't in ieder geval werkend achter gelaten