checking integrity - computer hangt

Status
Niet open voor verdere reacties.
M

mariannevanh

Terugkerende gebruiker
Lid geworden
14 dec 2004
Berichten
2.085
Als ik de computer met Ubuntu 20.04.1 LTS heb gestart, wordt er steevast een integriteitscontrole uitgevoerd.
Sinds enkele dagen kom ik daar niet doorheen. De computer "hangt" volledig.
Op het scherm staat dit:
Code: 
[    3.340651] sd 4:0:0:0:0: [sdb] No Caching mode page found
[    3.340675] sd 4:0:0:0:0: [sdb] Assuming drive cache: write through

Checking integrity, this may make some time
.................................................................................................................

Na een uur is er nog niets veranderd.
Wat is er aan de hand?

Groetjes,
Marianne
 
Probeer het op de volgende manier op te lossen:

Start op met de live linux usb/cd & overzie de indeling van je partities met het volgende commando in een terminal:
sudo fdisk -l
Je krijgt dan een overzicht als onder, waaruit blijkt dat je Linuxpartitie /dev/sda1 is.

Code: 
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 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: 0xa71bc45b

Device     Boot     Start       End   Sectors   Size Id Type
[B]/dev/sda1  *         2048 480393215 480391168 229.1G 83 Linux
[/B]/dev/sda2       480395262 488396799   8001538   3.8G  5 Extended
/dev/sda5       480395264 488396799   8001536   3.8G 82 Linux swap / Solaris
Je ziet aan het * dat het een opstartschijf is en aan het einde van de regel dat het de Linuxschijf betreft


Voer dan het volgende commando uit: (reparatie van het bestandssysteem)
sudo fsck -yv /dev/sda1

waardoor je het volgende overzicht krijgt:

Code: 
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
[B]/dev/sda1 contains a file system with errors, check forced.[/B]
Pass 1: Checking inodes, blocks, and sizes
[B]Inodes that were part of a corrupted orphan linked list found.  Fix? yes[/B]

Inode 11275098 was part of the orphaned inode list.  FIXED.
Inode 11275099 was part of the orphaned inode list.  FIXED.
Inode 11275100 was part of the orphaned inode list.  FIXED.
Inode 11275101 was part of the orphaned inode list.  FIXED.
Inode 11280599 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Error reading block 51389518 (Attempt to read block from filesystem resulted in short read) while reading directory block.  Ignore error? yes

Force rewrite? yes

Directory inode 12855288, block #0, offset 0: directory corrupted
Salvage? yes

Missing '.' in directory inode 12855288.
Fix? yes

Setting filetype for entry '.' in ??? (12855288) to 2.
Missing '..' in directory inode 12855288.
Fix? yes

Setting filetype for entry '..' in ??? (12855288) to 2.
Pass 3: Checking directory connectivity
'..' in /var/lib/docker/aufs/mnt/efa5ec50cb7cda556e07082ce6f284bc89209ffc566a91212110072d83e73e91 (12855288) is <The NULL inode> (0), should be /var/lib/docker/aufs/mnt (12468994).
Fix? yes

Pass 4: Checking reference counts
Inode 2 ref count is 23, should be 24.  Fix? yes

Inode 12468994 ref count is 58, should be 57.  Fix? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(45219840--45220206)
Fix? yes

Free blocks count wrong for group #1380 (31392, counted=31759).
Fix? yes

Free blocks count wrong (47147739, counted=46915808).
Fix? yes

Inode bitmap differences:  -(11275097--11275101) -11280599
Fix? yes

Free inodes count wrong for group #1376 (5, counted=10).
Fix? yes

Free inodes count wrong for group #1377 (7279, counted=7280).
Fix? yes

Free inodes count wrong (14328772, counted=14270663).
Fix? yes


/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

      745273 inodes used (4.96%, out of 15015936)
        2132 non-contiguous files (0.3%)
         607 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 698409/204
    13133088 blocks used (21.87%, out of 60048896)
           0 bad blocks
           3 large files

      607356 regular files
       89743 directories
          56 character device files
          25 block device files
           0 fifos
       41620 links
       48079 symbolic links (46566 fast symbolic links)
           5 sockets
------------
      786884 files

Hierna zul je weer kunnen opstarten!
 
Laatst bewerkt:
Het lijkt er op dat ik weer kan opstarten.
Het * in het overzicht zie ik niet, maar ik herken aan de grootte wel de harde schijf.
Code: 
# fdisk -l
Disk /dev/loop0: 54.98 MiB, 57626624 bytes, 112552 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


Disk /dev/loop1: 71.28 MiB, 74735616 bytes, 145968 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


Disk /dev/loop2: 29.9 MiB, 31334400 bytes, 61200 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


Disk /dev/loop3: 31.9 MiB, 32600064 bytes, 63672 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


Disk /dev/loop4: 55.48 MiB, 58159104 bytes, 113592 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


Disk /dev/loop5: 69.9 MiB, 73277440 bytes, 143120 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


Disk /dev/sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRZ-00G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: EDCB0457-A749-4A1A-BF39-F15C62DB575E

Device       Start        End    Sectors  Size Type
/dev/sda1     2048       4095       2048    1M BIOS boot
/dev/sda2     4096    2101247    2097152    1G Linux filesystem
/dev/sda3  2101248 7814033407 7811932160  3.7T Linux filesystem




Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 200 GiB, 214748364800 bytes, 419430400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
# sudo fsck -yv /dev/sda3
fsck from util-linux 2.34

Bij het installeren van Nextcloud lijkt vervolgens alles goed te gaan, maar als ik mijn data wil opslaan krijg ik na verloop van tijd een de melding:

Code: 
=> / is using 94.3% of 195.86GB

Wat is er aan de hand dat mijn grote partitie niet wordt herkend?

Vriendelijke groet,
Marianne
 
Als je GParted start of Schijfgebruik, zie je dan ook dat 94,3% gebruikt wordt van de 195.86GB?
Hier staat een manier om de partietabel te herstellen indien de grote partitie niet wordt weergegeven.....
 
Het is mij niet geheel duidelijk wat ik moet zien in het onderstaande overzichtje.

Als ik GParted vanaf een USB-stick start en ik kies vervolgens voor /dev/sdb dan zie ik
/dev/sdb1 - grub2 core.img - 1.0 MiB
/dev/sdb2 - ext - 1.0 GiB - 155.32 MiB - 868 MiB
/dev/sdb3 - lvm2 pv - ubuntu-vg - 3.64 TiB - 200 GiB - 3.44 TiB
ongebruikt - - 1.84 MiB

Ik heb op de computer Ubuntu Server 20.04.1 LTS staan.

Kun je me op weg helpen wat ik moet doen om nextcloud te installeren zodat de data in elk geval in de grote partitie komt?
 
Het is duidelijk iig dat Nextcloud niet naar de grote partitie wordt geschreven, want die is 3.7T oftewel 3700GB en geen 195,86GB waar 94,3% van gebruikt is. Waarschijnlijk is de partitietabel beschadigd en moet deze hersteld.Nu kan dat met Testdisk:

Testdisk kan je helpen bestanden terug te vinden en te halen.
Klik op Log creation
testdisklogcreation.png



Selecteer de schijf welke moet worden geanalyseerd:
testdiskdiskselection.png



Selecteer het soort partitietabel:
testdiskpartitiontabletype.png

Klik in jouw geval op [EFI GPT]


Testdisk toont het menu. Klik op Analyse:
testdiskanalyse.png



Daarna zie je de afgebeelde schijven en partities:
In dit voorbeeld zie je partitie 1 twee x vermeld staan:
testdisklistdisks.png

Wanneer alle schijven worden weergegeven, ga dan naar het gedeelte onder de horizontale lijn waarin beschreven wordt hoe je de partitietabel kunt herstellen.


Klik daarna op Quick Search waarna je de gemiste partitie zult kunnnen zien, in dit geval partitie 3 (Deze was niet eerder zichtbaar(!))
testdiskmissedpartition.png

Klik op P om de bestanden te kunnen zien & klik op Enter om verder te gaan.


Wanneer alle partities welk beschikbaar zijn correct worden weergegeven, klik je op Write om de partitiestructuur op te slaan.
Extd Part geeft je de mogelijkheid om te beslissen of de uitgebreide partitie alle mogelijke ruimte zal gebruiken of alleen de benodigde minimale ruimte.
testdiskpartitionwrite.png



Wanneer een partitie toch nog steeds mist, gebruik je Deeper Search waarna je onderstaand menu ziet:
testdiskdeepersearch.png

  • Selecteer de eerste partitie en klik P om de data ervan weer te geven.
  • Het bestandssysteem van de eerste logische schijf is beschadigd
    (klik op de afbeelding)
  • Klik op q om terug te gaan naar het vorige scherm
  • Laat de partitie Partitie 2 als beschadigd gemarkeerd.
  • Selecteer dan Partitie 2 daaronder
  • Klik p om de bestanden te zien
testdisklistfiles.png

  • Het werkt, je bestanden worden weergegeven, je hebt de correcte partitie gevonden!
  • Gebruik de navigatiepijltjes links & rechts door je mappen.
    FAT mappen zijn gelimiteerd om weer tegeven tot 10 clusters - sommige bestanden zullen waarschijnlijk niet te zien zijn, maar dat hindert het herstellen niet!
  • Klik op q om terug te gaan naar het vorige scherm
  • Beschikbare statussen zijn Primary, * bootable, Logical Deleted
  • Door gebruik te maken van de rechter & linkerpijlknop verandert de status van de geselecteerde partitie van (D)verwijderd naar (L)ogisch. Daardoor is Testdisk in staat te herstellen.


Het is nu mogelijk om de partitietabel te schrijven:
testdiskpartitionwrite.png

Wanneer alle partities worden weergegeven, klik dan op Write & Enter


De opstartsector van de eerste partitie Partitie 1 is nog steeds beschadigd. Tijd om te repareren.
De status van de NTFS opstartsector is slecht en de backup opstartsector is wel goed
Om de backup van de opstartsector over de opstartsector te kopiëren, selecteer Backup BS
testdiskbackupbs.png



Vervolgens klik je op Quit
testdiskafterbackupbs.png



De opstartsector en de backup zijn nu beide ok en gelijk: de NTFS opstartsector is succesvol hersteld.
testdiskreboot.png
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan