Linux clonen?

[sdk1985]

Ik probeer vandaag mijn Debian op mijn (trage) Sandisk Cruzer te upgraden naar de snellere Sandisk Extreme USB stick. Mijn eerste poging via Acronis TrueImage (windows) was niet geheel succesvol. KDE liet alleen een muis zien en verder een zwart scherm en ook via de terminal kreeg ik geen verbinding.

Volgende idee is het dan maar vanuit Linux zelf te doen. Tutorials genoeg te vinden echter loop ik nu vast bij het identificeren van de bron. De doel usb stick was makkelijk, die heb ik doel gelabeled.

root@bugattidebian:/dev/disk/by-label# ls -la
total 0
drwxr-xr-x 2 root root 160 Dec 23 17:39 .
drwxr-xr-x 8 root root 160 Dec 23 17:18 ..
lrwxrwxrwx 1 root root 10 Dec 23 17:19 Archive -> ../../sdf2
lrwxrwxrwx 1 root root 10 Dec 23 17:39 DOEL -> ../../sdh1
lrwxrwxrwx 1 root root 10 Dec 23 17:19 Movies -> ../../sdd1
lrwxrwxrwx 1 root root 10 Dec 23 17:19 Other -> ../../sde2
lrwxrwxrwx 1 root root 10 Dec 23 17:19 software\x20\x28spinpoint\x29 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Dec 23 17:19 Video -> ../../sdc2

Dat is dus sdh1.

Maar wat is nu de bron? Alle entries met een label zijn het niet, dat zijn hard disks. In de bios is de stick te herkennen als Sandisk Cruzer blade a 16 GB.

Update:
Ik heb hem heb gevonden:

root@bugattidebian:/dev/disk/by-label# fdisk -l

Disk /dev/sda: 14.7 GiB, 15744892928 bytes, 30751744 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x661159b4

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1  *      2048   499711   497664  243M 83 Linux
/dev/sda2       501758 30750719 30248962 14.4G  5 Extended
/dev/sda5       501760 30750719 30248960 14.4G 8e Linux LVM

Bron zou sda moeten zijn.

Volgende probleem. Ik merk bijvoorbeeld dat het standaard voorbeeld blocksize 512 gebruikt maar dat mijn partities nu 1024,1024 en 4096 gebruiken.

root@bugattidebian:/dev/disk/by-label# blockdev --getbsz /dev/sda1
1024
root@bugattidebian:/dev/disk/by-label# blockdev --getbsz /dev/sda2
1024
root@bugattidebian:/dev/disk/by-label# blockdev --getbsz /dev/sda5
4096

Dat botst een beetje met het voorbeeld:

quote: https://wiki.archlinux.org/index.php/Disk_cloning

dd if=/dev/sdX of=/dev/sdY bs=512 conv=noerror,sync

Dus heb ik het per partitie geprobeerd:

root@bugattidebian:/dev/disk/by-label# dd if=/dev/sda1 of=/dev/sdh1 bs=1024 conv=noerror,sync
248832+0 records in
248832+0 records out
254803968 bytes (255 MB) copied, 21.8096 s, 11.7 MB/s
root@bugattidebian:/dev/disk/by-label# dd if=/dev/sda2 of=/dev/sdh2 bs=1024 conv=noerror,sync
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.00287152 s, 357 kB/s
root@bugattidebian:/dev/disk/by-label# dd if=/dev/sda5 of=/dev/sdh5 bs=4096 conv=noerror,sync
dd: error writing ‘/dev/sdh5’: No space left on device
2560+0 records in
2559+0 records out
10481664 bytes (10 MB) copied, 0.657756 s, 15.9 MB/s

Maar dat werkte niet. Een nieuwe fdisk -l laat gewoon de oude fat partitie zien.

[ Voor 44% gewijzigd door sdk1985 op 23-12-2015 17:03 ]

[H!GHGuY]

De blocksize van dd en de blocksize van je partitie hebben niks met elkaar te maken.
De dd-blocksize is gewoon het aantal bytes wat per keer over gezet wordt.

[sdk1985]

Hmm oké. Toch lijkt het niet helemaal goed te zijn gegaan:

dd if=/dev/sda of=/dev/sdh bs=1024 conv=noerror,sync

Disk /dev/sdh: 29.2 GiB, 31376707072 bytes, 61282631 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x661159b4

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sdh1  *      2048   499711   497664  243M 83 Linux
/dev/sdh2       501758 30750719 30248962 14.4G  5 Extended
/dev/sdh5       501760 30750719 30248960 14.4G 8e Linux LVM

Tot zo ver goed. Maar dan:

root@bugattidebian:~# blockdev --getbsz /dev/sdh1
512
root@bugattidebian:~# blockdev --getbsz /dev/sdh2
BLKBSZGET: Inappropriate ioctl for device
root@bugattidebian:~# blockdev --getbsz /dev/sdh5
BLKBSZGET: Inappropriate ioctl for device

[Borromini]

Als je van je USB-stick boot ziet Linux normaal gezien je stick als sda (en je eerste regels in dmesg zouden je een UUID moeten geven dat je kan checken op Linux).

Ik vind het persoonlijk handiger om

code:

# cp -ra * /newdir/

te doen en eerst handmatig te partitioneren + GRUB2 te installeren. -a zorgt voor een 1:1 kopie (zelfde machtigingen etc.) dus daar hoef je je geen zorgen over te maken. dd verwacht oa dezelfde partitiegroottes, het is me niet helemaal duidelijk of je die behouden hebt, maar je ene stick is 16 GB en je andere 32 GB, dus... Ik zou gewoon cp gebruiken. Dd lijkt me hier wat overkill.

[Mijzelf]

Met dd heb je een rauwe kopie gemaakt. Fdisk leest de partitie tabel en laat die zien. Maar als je de kernel niet verteld dat de partitietabel gewijzigd is, scant hij hem niet opnieuw, en bestaan /dev/sdh2 en /dev/sdh5 dus niet.

[CyBeR]

Waarom doe je niet gewoon

dd if=/dev/sda of=/dev/sdh bs=1M

?

Dat werkt namelijk prima. Daarna de sticks wisselen en booten van je nieuwe stick.

[ Voor 36% gewijzigd door CyBeR op 23-12-2015 17:37 ]

[sdk1985]

CyBeR schreef op woensdag 23 december 2015 @ 17:35:
Waarom doe je niet gewoon

dd if=/dev/sda of=/dev/sdh bs=1M

?

Dat werkt namelijk prima. Daarna de sticks wisselen en booten van je nieuwe stick.

Geen idee . Ik zie weinig verschil met wat ik heb geprobeerd behalve een missende parameter (noerror,sync) en een grotere blocksize. Zal het zo wel even proberen maar ik verwacht hetzelfde resultaat.

Mijzelf schreef op woensdag 23 december 2015 @ 17:33:
Met dd heb je een rauwe kopie gemaakt. Fdisk leest de partitie tabel en laat die zien. Maar als je de kernel niet verteld dat de partitietabel gewijzigd is, scant hij hem niet opnieuw, en bestaan /dev/sdh2 en /dev/sdh5 dus niet.

Ik heb nog wel geprobeerd te booten vanaf de doelstick. De bootloader werkte prima alleen daarna startte hij niet op in KDE, maar in de terminal modus. Toen ik daar inlogde als root verschenen er foutmeldingen mbt EXT4.

Ik ben het nu even opnieuw aan het proberen met het command van Cyber. Het viel me net op dat na 15 minuten de pc in standby ging. Ik betwijfel of hij daadwerkelijk klaar was met clonen dus ik doe hem nog wel een keer opnieuw.

[ Voor 12% gewijzigd door sdk1985 op 23-12-2015 17:59 ]

[Xudonax]

Als je opgestart bent vanaf de schijf die je wilt kopieren dan gaat dit inderdaad niet altijd goed, omdat je Ext partitie dan nog in gebruik is. Dit levert inderdaad dit soort problemen op. Zoals Borromini voorstelt, partitioneer je nieuwe stick, kopiëer alles met cp -a en installeer vervolgens de bootloader op je nieuwe USB stick. Dan zou het wel moeten werken.

[sdk1985]

Het vervelende van Linux is dat als je X wil het vaak op manier A,B,D,E,F,G kan. In dit geval is dit mijn eerste Linux install in 15 jaar en was de installatie überhaupt al iets wat letterlijk dagen heeft geduurd. Partities heb ik toen via de Debian setup gemaakt, grub werd vanzelf geïnstalleerd. Het is dus niet zo dat ik beide handelingen nu even kan uitvoeren. Dat zijn beide weer zaken die ik moet leren (Google) en waarbij ik gegarandeerd weer tegen nieuwe problemen aan loop. Hoe goed ook bedoelt met "cp -ra * /newdir/" kan ik ook weinig omdat ik bijvoorbeeld al niet weet wat ik bij de newdir zou moeten invullen om het op de juiste plek te krijgen. Dus ik voorzie al minimaal 3 problemen en een avondvullend programma met die oplossing.

dd if=/dev/sda of=/dev/sdh bs=1M
15015+1 records in
15015+1 records out
15744892928 bytes (16 GB) copied, 945.461 s, 16.7 MB/s

Ik ga even kijken of dit nu wel boot en zo nee wat de foutmelding is.

root@bugattidebian:~# fsck.ext4 -v /dev/sdh5
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdh5

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

root@bugattidebian:~# mke2fs -n /dev/sdh5
mke2fs 1.42.12 (29-Aug-2014)
/dev/sdh5 contains a LVM2_member file system
Proceed anyway? (y,n)

Als ik deze partitie gerepareerd krijg (desnoods via opnieuw aanmaken) dan zou het moeten werken... Toch? Grub staat er in ieder geval op en sdh1 is goed. Ik gebruik overigens een LVM.

Dat lijkt de boosdoener te zijn: http://www.andybotting.com/how-do-you-clone-an-lvm-partition

[ Voor 34% gewijzigd door sdk1985 op 23-12-2015 18:21 ]

[Borromini]

Ik begrijp dat je het snel en efficiënt wil maar als je gewoon een tutorial volgt zonder te weten wat bepaalde zaken met zich meebrengen loop je alsnog tegen problemen aan.

Volgorde:
1) Je partitioneert je stick (ik vind parted en gdisk persoonlijk handiger). Je kan je hiervoor baseren op de layout van je oude stick. Bij voorkeur gebruik je de legacy MBR layout, dat beperkt je qua partities maar zal nog op elk systeem opstarten (alternatief is GPT etc.). Laat voldoende ruimte om GRUB2 in te bedden - dus je begint je eerste partitie op 2MiB. Niet aan het begin van de MBR.
2) Je formatteert je partities:

code:

# mkfs.ext4 -L $label /dev/sdb1

3) Je koppelt je partities aan, van beide sticks, en kopieert van A naar B:

code:

# cp -ra /media/oudestick/* /media/nieuwestick/

4) Installeer grub

code:

# grub-install --target=i386-pc --root=/media/nieuwestick/

Het makkelijkst is dat je daarna chroot naar /media/nieuwestick/ (eerst al je speciale bestandssystemen zoals /dev, /sys en /proc aankoppelen in de chroot) en dan update-grub uitvoert. Dat zal alle UUID's etc. oppikken en een nieuwe GRUB-configuratie genereren.

Hoe je het ook draait of keert, en wat anderen je ook voorstellen, je bootloader werkt waarschijnlijk nu al met UUID's en die wijzigen als je een nieuwe stick (of een nieuwe partitie) gebruikt. Dus je kan alles 1:1 kopiëren met dd, maar de UUID's zullen niet kloppen en je bootloader gaat zijn spullen ook niet meer terugvinden.

Als je nog een vrije stick hebt raad ik je aan om bv. een Manjaro live image te gebruiken of een kleine grafische distro, de Debian-installer is degelijk (maar heeft zo z'n eigen nukken), als live distro is hij niet geschikt.

Met een grafische distro kan je makkelijk aankoppelen etc., zeker als je kennis niet zo vers meer is. Manjaro is netjes up to date (gebaseerd op Arch).

[ Voor 27% gewijzigd door Borromini op 23-12-2015 18:51 ]

[CyBeR]

Xudonax schreef op woensdag 23 december 2015 @ 18:00:
Als je opgestart bent vanaf de schijf die je wilt kopieren dan gaat dit inderdaad niet altijd goed, omdat je Ext partitie dan nog in gebruik is.

Dat is een goed punt maar te omzeilen door in rescue of single-user mode te booten met read-only filesystems. Overigens zou dit er typisch gezien niet voor zorgen dat 't helemaal niet werkt.

sdk1985 schreef op woensdag 23 december 2015 @ 17:47:
[...]

Geen idee . Ik zie weinig verschil met wat ik heb geprobeerd behalve een missende parameter (noerror,sync) en een grotere blocksize. Zal het zo wel even proberen maar ik verwacht hetzelfde resultaat.

Klopt, maar het 'boot van je nieuwe stick' deel is belangrijk. Ik zie iig nergens in je TS dat je dat daadwerkelijk geprobeerd hebt na een volledige copy, toch?

[sdk1985]

CyBeR schreef op woensdag 23 december 2015 @ 19:35:

Klopt, maar het 'boot van je nieuwe stick' deel is belangrijk. Ik zie iig nergens in je TS dat je dat daadwerkelijk geprobeerd hebt na een volledige copy, toch?

Oké even een update/samenvatting.

Ik heb wel geprobeerd te booten maar dat resulteerde toen in een niet werkende KDE en foutmeldingen in de terminal (zie iets hoger).

Ondertussen heb ik de machine verplaatst (van de garage naar naast mij) en viel mij iets op. Na x minuten gingen alle drives spinnen. Precies zoals bij een wake up/boot event. Vermoedelijk is de machine tijdens de dd actie heel kort in standby gegaan.

Ik heb de standby timer daarom verzet na 60 minuten en opnieuw dd laten lopen. De pc boot nu wel netjes via de nieuwe stick in KDE en lijkt te functioneren. Hij is te bereiken via SAMBA en putty gaat ook .

Wel is er nog iets mis met de partitie:

root@bugattidebian:~# fsck.ext4 -f /dev/sda5
e2fsck 1.42.12 (29-Aug-2014)
/dev/sda5 is in use.
e2fsck: Cannot continue, aborting.


root@bugattidebian:~# fsck.ext4 -nf /dev/sda5
e2fsck 1.42.12 (29-Aug-2014)
Warning!  /dev/sda5 is in use.
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Of is dat normaal voor een LVM volume???

[CyBeR]

Ja, je moet niet de partitie fscken dan maar de volume.

[sdk1985]

Nieuwe melding tijdens updaten:

Dit had ik dus nog nooit gekozen omdat de debian setup voor mij die keuze heeft gemaakt. Na wat google werk ben ik voor sda gegaan (dus geen partitie). Lijkt te werken .

CyBeR schreef op woensdag 23 december 2015 @ 21:45:
Ja, je moet niet de partitie fscken dan maar de volume.

Ik had ook nooit voor LVM moeten gaan *zucht* .

fsck -nf /dev/bugattidebian-vg/root
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
Warning!  /dev/mapper/bugattidebian--vg-root is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 1857 has zero dtime.  Fix? no

Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 1859 was part of the orphaned inode list.  IGNORED.
Inode 1863 was part of the orphaned inode list.  IGNORED.
Inode 1864 was part of the orphaned inode list.  IGNORED.
Inode 1865 was part of the orphaned inode list.  IGNORED.
Inode 261082 was part of the orphaned inode list.  IGNORED.
Inode 526205 was part of the orphaned inode list.  IGNORED.
Inode 526206 was part of the orphaned inode list.  IGNORED.
Inode 528192 was part of the orphaned inode list.  IGNORED.
Inode 656572 was part of the orphaned inode list.  IGNORED.
Inode 805735 was part of the orphaned inode list.  IGNORED.
Inode 805736 was part of the orphaned inode list.  IGNORED.
Inode 805738 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(95232--95629) -(114854--115453) -(499941--500298) -(558488--558526) -(3203436--3203440) -3203448
Fix? no

Free blocks count wrong (2528802, counted=2515671).
Fix? no

Inode bitmap differences:  -1857 -1859 -(1863--1865) -261082 -(526205--526206) -528192 -656572 -(805735--805736) -805738
Fix? no

Free inodes count wrong (771106, counted=771776).
Fix? no


/dev/mapper/bugattidebian--vg-root: ********** WARNING: Filesystem still has errors **********

/dev/mapper/bugattidebian--vg-root: 132878/903984 files (0.4% non-contiguous), 1084894/3613696 blocks

Kan ik via de bootloader in safemode en dan die LVM unmounten? Of moet ik persé een andere USB stick zoeken.

[ Voor 13% gewijzigd door sdk1985 op 23-12-2015 22:11 ]

[Demo]

sdk1985 schreef op woensdag 23 december 2015 @ 21:53:
Ik had ook nooit voor LVM moeten gaan *zucht* .
Kan ik via de bootloader in safemode en dan die LVM unmounten? Of moet ik persé een andere USB stick zoeken.

Heb je daar met een reden voor gekozen? Wat staat er op de LVM? Als je nog geen logical volumes hebt aangemaakt in LVM, kan je ook een ext4 partitie aanmaken op sda5.

[sdk1985]

Demoniac schreef op donderdag 24 december 2015 @ 08:04:
[...]
Heb je daar met een reden voor gekozen? Wat staat er op de LVM? Als je nog geen logical volumes hebt aangemaakt in LVM, kan je ook een ext4 partitie aanmaken op sda5.

De debian setup bpod de mogelijkheid en na een korte Google opdracht leken er wel voordelen te zijn (live resizen, snapshots). Zo ver ik mij kan herrineren valt alles onder de lvm behalve de kleine /boot partitie.

[begintmeta]

Ik kies er meestal voor om alleen de inhoud tussen de media te verplaatsen (bv met rsync), na eerst het doel-filesystem nieuw aan te maken.

[Wolfboy]

Bespaar jezelf een hoop gedoe en doe het even met een clonezilla schijfje
Die kan je zelfs op de nieuwe stick zetten, laten booten naar het geheugen en daarna de nieuwe stick laten overschrijven

[sdk1985]

begintmeta schreef op donderdag 24 december 2015 @ 16:35:
Ik kies er meestal voor om alleen de inhoud tussen de media te verplaatsen (bv met rsync), na eerst het doel-filesystem nieuw aan te maken.

De NAS is niet zo krachtig, installatie heeft de eerste keer iets van 45 minuten geduurd. Kan natuurlijk ook aan de 5MB/s hebben gelegen. In ieder geval heeft clonen de voorkeur .

Wolfboy schreef op donderdag 24 december 2015 @ 18:31:
Bespaar jezelf een hoop gedoe en doe het even met een clonezilla schijfje
Die kan je zelfs op de nieuwe stick zetten, laten booten naar het geheugen en daarna de nieuwe stick laten overschrijven

Jammer dat clonezilla niet in apt-get zit . Nu ik de migratie heb voltooid kan ik clonezilla wel eens proberen te installeren op de trage stick .

[Hero of Time]

sdk1985 schreef op donderdag 24 december 2015 @ 21:11:
[...]

Jammer dat clonezilla niet in apt-get zit . Nu ik de migratie heb voltooid kan ik clonezilla wel eens proberen te installeren op de trage stick .

Dat zittie wel!

xubuntu@xubuntu:~$ apt-cache search clonezilla
clonezilla - bare metal backup and recovery of disk drives

Live omgeving van 15.10 gewoon beschikbaar.

[sdk1985]

Hero of Time schreef op vrijdag 25 december 2015 @ 15:24:
[...]

Dat zittie wel!

xubuntu@xubuntu:~$ apt-cache search clonezilla
clonezilla - bare metal backup and recovery of disk drives

Live omgeving van 15.10 gewoon beschikbaar.

Oh dan heb ik gisteren een typfout gemaakt. Goed om te weten .

Ik kwam overigens het programma tuxboot-0.8.2 tegen waarmee je heel makkelijk een bootable stick kunt maken clonezilla of gparted.

[begintmeta]

sdk1985 schreef op donderdag 24 december 2015 @ 21:11:
[...]

De NAS is niet zo krachtig, installatie heeft de eerste keer iets van 45 minuten geduurd. Kan natuurlijk ook aan de 5MB/s hebben gelegen. In ieder geval heeft clonen de voorkeur ...

Rsync is ook niet zo zwaar, en, als de bron voor een deel uit irrelevante informatie bestaat (zoals lege ruimte), hoef je evt wat minder bytes te verplaatsen. Imho is rsync (of een andere manier van kopiëren) toch echt te prefereren als het erom gaat informatie te verplaatsen, zo lang de meta-informatie(het filsystem/de structuur daarin) niet van belang is.

[CAPSLOCK2000]

Losse opmerkingen vanaf m'n telefoon.

De hele disk dd'en is de makkelijkste oplossing, maar wel met disks die niet gemount zijn. Boot dus van een ander medium.

Let op "extended" partities.

Controleer/corrigeer je /etc/fstab na het kopieren.

Als grub moeilijk doet is grub herinstalleren meestal de snelste oplossing, daar zijn handige iso's voor.

"cat" werkt net zo goed als "dd"
cat /dev/a /dev/b
sync

[Hero of Time]

sdk1985 schreef op vrijdag 25 december 2015 @ 16:53:
[...]

Oh dan heb ik gisteren een typfout gemaakt. Goed om te weten .

Ik kwam overigens het programma tuxboot-0.8.2 tegen waarmee je heel makkelijk een bootable stick kunt maken clonezilla of gparted.

Ik heb wel eerst een apt-get update gedraaid, zodat de online repo's bekend zijn met wat erin staat. Als je een verse boot hebt, dan kent-ie natuurlijk niet wat er in de online repo beschikbaar is.

[sdk1985]

Hmm oké weer wat geleerd .

Even een vervolg vraag.. Ik heb nu gparted op de oude USB stick gezet om de LVM te kunnen repareren. Echter krijg ik bij de fsck de melding dat er geen r/w permissions zijn. In de grafische display van gparted staat ook een slotje bij de LVM. Het command lvdisplay werkt ook niet. Het lijkt erop dat gparted dus geen lvm ondersteund.

Is er een manier waarop ik wel een fsck kan draaien???

Debian Jessie + LVM is echt een drama als je googled voor oplossingen. De vraag hoe je überhaupt een fsck on boot scheduled wordt tientallen keren gesteld maar antwoorden blijven uit.

[ Voor 19% gewijzigd door sdk1985 op 27-12-2015 18:36 ]

[Hero of Time]

LVM is een volume manager. Gparted ziet hiervoor maar 1 partitie, het LVM fysieke volume. Wil je meer doen, dan zal je moeten wenden naar de command line. Als root gebruik je de volgende commando's:

pvdisplay - laat LVM fysieke volumes zien
vgdisplay - laat volume groepen zien
lvdisplay - laat de logische volumes zien
vgchange - activeer volumegroepen

Die laatste moet je met de -ay parameters draaien, dan activeer je de gevonden volumegroep en kan je in /dev/mapper de logische volumes vinden (en natuurlijk ook onder /dev/volumegroep).

Een fsck forceren doe je dan weer met tune2fs op het file system dat je wilt aanpassen. Normaal gesproken is het zo makkelijk als tune2fs op bijvoorbeeld /dev/sda2 uit te voeren met de juiste opties en parameters, maar met LVM moet je natuurlijk het LVM volume opgeven en dat kan pas als die bekend zijn. Lees wel goed de manpage van tune2fs, want een fout kan je hele file system slopen.

[sdk1985]

Oké even een update.

Gparted zag de sda2 en sda5 wel maar er stond een slotje bij.

De opmerking over root was de sleutel! Na wat zoekwerk bleek er geen root password te zitten in de live gparted versie. Het volstond om sudo lvdisplay te gebruiken. Ik putty altijd als root dus daar had ik totaal niet bij stilgestaan . Vervolgens was (sudo) fsck /dev/bugattidebian-vg/root ineens ook geen probleem meer .

Bestandsysteem bleek overigens al clean te zijn. De reden dat ik hier aan twijfelde is dat na ELKE reboot mijn sabnzndplus terug sprint van port 5050 naar port 5000 in zijn sabnzbd.ini. Dat zal dan toch het programma zelf zijn... Misschien kan ik morgen iets ontdekken in het startup script in init.d.

De aanhouder wint. Ik bleek ooit een script te hebben aangemaakt genaamd /etc/default/sabnzbdplus. Hieron stond een host (op 0.0.0.0) en een port (5000). Dat was dus de boosdoener!

Als ik nu ook nog de standby goed krijg dan ben ik onderhand klaar... De standby via KDE (suspend session) werkt niet want die gooit doodleuk de hele pc in standby terwijl er iets plaats vindt zoals een download of een filecopy.

[ Voor 29% gewijzigd door sdk1985 op 28-12-2015 04:34 ]

[Hero of Time]

Voor de standby heb je mooie opties als 'inhibit standby while downloading' e.d. Dan geef je in je DE een tijd op dat het systeem na x minuten idle zou moeten gaan slapen, maar doet het dan niet als sabbie bezig is. Niet elk programma en implementatie doet het overigens, dus sta niet gek te kijken als je systeem na een half uur (of wat je hebt ingesteld) alsnog gaat slapen terwijl een download bezig is.

Mare, waarom SSH je altijd als root naar je systeem? Ben je het zo gewend aan Windows dat je altijd alles mag en je systeem op deze manier te graaien zet voor fouten? Dus tenzij je een heel goede reden hebt, is direct aanmelden als root uit den bozen. Ik mag hopen dat je sab e.d. niet als root draait.

[synoniem]

[b][message=45499609,noline]

Debian Jessie + LVM is echt een drama als je googled voor oplossingen. De vraag hoe je überhaupt een fsck on boot scheduled wordt tientallen keren gesteld maar antwoorden blijven uit.

Dat is niet een LVM probleem maar een systemd probleem. Je kan een fsck forceren door bij het opstarten de kernelparameter fsck.mode=force mee te geven.

[Thc_Nbl]

ik zou gewoon even de hdclone free downloaden en die gebruiken.
zet hem op usb stick booten en clonen.

daarna booten, even blkid typen en je fstab aanpassen naar de nieuwe UUID's .

moet werken, zelf ook zo gedaan.