# Problem After upgrading from stretch to buster, my laptop gets stuck in boot during fsckd check, with the message: fsckd-cancel-msg:Press Ctrl+C to cancel all filesystem checks in progress It does not respond to 'Ctrl+C' or anything else. # Background ## Upgrade I upgraded from stretch to buster following this tutorial. To guard against link rot, here are the commands in consecutive order: su sed -i 's/stretch/buster/g' /etc/apt/sources.list apt update apt upgrade apt dist-upgrade apt autoremove apt clean shutdown -r now There were no error messages. ## Boot During the reboot, there was the obligatory fskd check, which never caused any problems before. Now, however, it ends with the above mentioned error message. Manually powering off and on again lead to the same result. # What I tried This question has the same problem on Ubuntu. Since Debian and Ubuntu are similar, I thought the accepted answer could fix my problem. My approach follows the answer: ## Rescue mode I did not have have a Live USB at hand, so isntead I booted in Linux 4.19.0-12-amd64 x86_64 (rescue mode) and provided the root password for maintenance. fdisk -l Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 499711 497664 243M 83 Linux /dev/sda2 501758 625141759 624640002 297.9G 5 Extended /dev/sda5 501760 625141759 624640000 297.9G 83 Linux I then ran a manual fsck on all the listed disks, also on /dev/mapper/debian--vg-root and /dev/mapper/debian--vg-home, all of which came back clean. I then rebooted, thinking maybe the problem was solved. ## Rescue mode graphical Alas, rebooting showed the same error. So I again powered off and on manually, again booting in rescue mode. This time however, instead of providing the root password, I pressed Ctrl+D to continue. It finished booting up, showing nothing but a black screen. So I switched tty with Ctrl+Alt+F1, logging in with my non-root standard user. I then started a X11 session with startx (no good reason for this other than me being more comfortable with a graphical session). This showed me already that the upgrade had worked, since the optics of buster are a little different than in stretch. Just to be sure I checked my distro with lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster ## Bad block scan I ran sudo e2fsck -fccky on all /dev/sdaX and /dev/mapper/debian-vg-X, which took almost two hours. A reboot showed that the error still remained. ## Gparted I ran gparted, but since my disk is LUKS encrypted, I couldn't see anything useful (related question). ## Checking /var I saw in multiple places that a full /var can cause similar problems. Since I couldn't check it with gparted like advised, I checked it like proposed here : sudo du -ks *|sort -nr However, the output does not look like it's very full: 698456 lib 100720 cache 53824 log 6688 backups 76 spool 68 tmp 32 snap 8 mail 4 opt 4 local 0 run 0 lock Also, the output of df looks like this: Filesystem 1K-blocks Used Available Use% Mounted on udev 1988192 0 1988192 0% /dev tmpfs 402032 6508 395524 2% /run /dev/mapper/debian--vg-root 28703652 10165160 17057380 38% / tmpfs 2010160 133528 1876632 7% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 2010160 0 2010160 0% /sys/fs/cgroup /dev/sda1 240972 89448 139083 40% /boot /dev/mapper/debian--vg-home 273421644 24010648 235452240 10% /home /dev/loop0 212864 212864 0 100% /snap/firefox/172 /dev/loop2 100096 100096 0 100% /snap/core/10185 /dev/loop1 100096 100096 0 100% /snap/core/10126 tmpfs 402032 24 402008 1% /run/user/1000 So I don't think that's the problem. ## Stopping fsck on boot ### Booting on battery power So I thought I could just prevent fsck from running on boot, like here . However, booting on battery power and pressing Ctrl+C had no discernible effect, still the same error. ### tune2fs As proposed here I used tune2fs -c 0 -i 0 /dev/sda1. But even though Maximum mount count is set to -1 and Check interval to 0 (), the error remains. I also found this solution, but since this is for archlinux, and also I don't know anything about grub, I did not attempt it. # Additional information * On boot, I was confused to see that there are apparently two kernel versions on my laptop, 4.19 and 4.9. Is this because of the upgrade or was it always there and I just never saw it? * A common issue seems to be when nvidia drivers are installed, which is why the tutorial linked above recommends to remove it before upgrading. I never had nvidia drivers installed however, so that can't be the reason. * A similar question was solved by installing nvidia-drivers. However, apt tells me Unable to locate package nvidia-drivers. # Question How can I prevent fsckd from locking up my system on boot?

I had a I/O error on an external hard drive partition sdb4 (its usual mountpoint being /run/media/yan/data). The partition was non responsive, couldn't be accessed and refused to unmount. I did not know what to do but unplug the disk and replug it. After that I had error on its fs, so I ran fsck: sudo e2fsck /dev/sdb4 -y -v It was asking for a lot of fixes (thousands) but since data is non-critical on that disk, I ran it with -y. data contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure # Fixed invalid inode numbers, incorrect filetypes, cleared links, deleted/unused inodes Pass 3: Checking directory connectivity # Connected unconnected directory inodes to /lost+found Pass 4: Checking reference counts #Fix inodes ref count, connected unattached inode to /lost+found Pass 5: Checking group summary information # Fix block bitmap differences, blocks count wrong for group # Fix inode bitmap differences, directories count wrong for group, free inodes count wrong for group data: ***** FILE SYSTEM WAS MODIFIED ***** 72955 inodes used (0.14%, out of 51200000) 2390 non-contiguous files (3.3%) 17 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 72264/636/1 186984621 blocks used (91.30%, out of 204800000) 0 bad blocks 34 large files 70447 regular files 2453 directories 0 character device files 0 block device files 0 fifos 4294966642 links 46 symbolic links (46 fast symbolic links) 0 sockets ------------ 71063 files So if I understand correctly, fsck managed to salvage 70k files, so most of the files since I had like 75-80k files on that disk. The problem is that only 20k files appear in '/run/media/yan/data/lost+found', and only 24k on the entire partition. [yan@machine ~]$ find /run/media/yan/data/lost+found | wc -l 19786 [yan@machine ~]$ find /run/media/yan/data | wc -l 23691 I reran fsck but he tells me that the partition is clear (and has 74k files ?) [yan@machine ~]$ sudo fsck /dev/sdb4 fsck from util-linux 2.28 e2fsck 1.42.13 (17-May-2015) data: clean, 74200/51200000 files, 186685980/204800000 blocks[/cpp] I also have very different disk usage according to df and du (I know there should be a difference, but here it seems too big to be normal): [yan@machine ~]$ df -h /run/media/yan/data Filesystem Size Used Avail Use% Mounted on /dev/sdb4 769G 700G 31G 96% /run/media/yan/data [yan@machine ~]$ du -sh /run/media/yan/data 586G /run/media/yan/data I'm guessing there is still recovered data that I can't access. My questions are : 1) Is it possible for recovered files by fsck to not be place in lost+found ? In that case, where are they ? 2) Is there any way to get back those missing files ? 3) If not, how do I free this space ? EDIT: I tried a more recent version of e2fsck on sourcejedi's recommandation: [yan@machine build]$ sudo ./e2fsck/e2fsck -f /dev/sdb4 e2fsck 1.43.3 (04-Sep-2016) Pass 1: Checking inodes, blocks, and sizes Inode 40501578 extent tree (at level 2) could be narrower. Fix? yes Pass 1E: Optimizing extent trees Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information data: ***** FILE SYSTEM WAS MODIFIED ***** data: 74200/51200000 files (3.2% non-contiguous), 186685964/204800000 blocks It did not do much, lost+found still has the same file count and size.

Debian crashed on Laptop (Acer Aspire 3, about 4 years old, HDD replaced with ADATA SU650 240GB SSD) and started throwing console errors reading "failed to rotate /var/log/journal: read-only filesystem". It rebooted fine, but a while later refused to load websites and eventually crashed again. Right now, it's working fine. After a quick Google search I installed smartctl to figure out the problem, and though it prints an overall "PASSED", it does have some attributes output "Pre-failed" and I'm not exactly sure how to interpret the rest of the values. Here's the output: smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-37-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Silicon Motion based SSDs Device Model: ADATA SU650 Serial Number: 2N20292G46UJ LU WWN Device Id: 0 000000 000000000 Firmware Version: XD0R6305 User Capacity: 240,057,409,536 bytes [240 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches TRIM Command: Available, deterministic Device is: In smartctl database 7.3/5319 ATA Version is: ACS-3, ATA8-ACS T13/1699-D revision 6 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sun Jun 29 21:36:52 2025 -03 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 1) seconds. Offline data collection capabilities: (0x59) SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0002) Does not save SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 2) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 050 Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 929 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1439 160 Uncorrectable_Error_Cnt 0x0032 100 100 050 Old_age Always - 0 161 Valid_Spare_Block_Cnt 0x0032 100 100 050 Old_age Always - 100 163 Initial_Bad_Block_Count 0x0032 100 100 000 Old_age Always - 48 164 Total_Erase_Count 0x0032 100 100 000 Old_age Always - 87382 165 Max_Erase_Count 0x0032 100 100 000 Old_age Always - 156 166 Min_Erase_Count 0x0032 100 100 000 Old_age Always - 44 167 Average_Erase_Count 0x0032 100 100 000 Old_age Always - 109 148 Total_SLC_Erase_Ct 0x0032 100 100 000 Old_age Always - 262148 149 Max_SLC_Erase_Ct 0x0032 100 100 000 Old_age Always - 468 150 Min_SLC_Erase_Ct 0x0032 100 100 000 Old_age Always - 132 151 Average_SLC_Erase_Ct 0x0032 100 100 000 Old_age Always - 329 159 DRAM_1_Bit_Error_Count 0x0032 100 100 000 Old_age Always - 0 168 Max_Erase_Count_of_Spec 0x0032 100 100 000 Old_age Always - 468 169 Remaining_Lifetime_Perc 0x0032 100 100 000 Old_age Always - 98 177 Wear_Leveling_Count 0x0032 100 100 000 Old_age Always - 1823 181 Program_Fail_Cnt_Total 0x0032 100 100 000 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 77 194 Temperature_Celsius 0x0032 100 100 000 Old_age Always - 26 195 Hardware_ECC_Recovered 0x0032 100 100 000 Old_age Always - 403177 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0 232 Available_Reservd_Space 0x0032 100 100 000 Old_age Always - 100 241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 139845 242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 143114 245 TLC_Writes_32MiB 0x0032 100 100 000 Old_age Always - 296002 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. I'd greatly appreciate some advice on what these values mean and what can be done about them. I know that "Old_age" means the device is worn and "Pre-fail" means it's about to give, but I don't really know if this reflects normal wear, lack of maintenance, or is recoverable from. Thanks in advance!

This is a follow-up on this question: https://unix.stackexchange.com/questions/797373/how-to-run-fsck-with-lvm I have a RHEL 9 server which uses LVM on /dev/sda3. There are several LVs on a single VG. After booting in maintenance mode (rd.break kernel option at GRUB boot line), I'd like to run a fsck on all partitions. However, /dev/mapper/ and /dev/myvg/ only list the root and swap LVs, which are the only ones mentioned in rd.lvm.lv= in the kernel options. A xfs_repair /dev/sda3 returns an error > Cannot open /dev/sda3: Device or resource busy. How can I find (and do a fs check) the other LVs?

I would like to run fsck on a RHEL 9.5 server after boot, but the proposed solutions ... - Adding a /forcefsck file - Editing the GRUB entry at boot and adding the kernel option fsck.mode=force - Making sure the fsck entry (6th column) is set to a nonzero value in /etc/fstab ... do not work, and the server boots normally. How to do that? The disk is XFS.

I am having I/O errors on /dev/sda on a RHEL 9 server. Output of dmesg | grep sda: [ 3.323141] sd 0:0:0:0: [sda] 62914560 512-byte logical blocks: (32.2 GB/30.0 GiB) [ 3.323174] sd 0:0:0:0: [sda] Write Protect is off [ 3.323177] sd 0:0:0:0: [sda] Mode Sense: 3b 00 00 00 [ 3.323218] sd 0:0:0:0: [sda] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 3.327168] sda: sda1 sda2 sda3 [ 3.327468] sd 0:0:0:0: [sda] Attached SCSI disk [ 6.338087] XFS (sda2): Mounting V5 Filesystem fb24877b-278d-412a-8f68-e7f1909484b1 [ 6.390410] XFS (sda2): Ending clean mount [ 253.414807] sd 0:0:0:0: [sda] tag#58 task abort on host 0, 0000000030035026 [ 253.415338] sd 0:0:0:0: [sda] tag#58 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=180s [ 253.415342] sd 0:0:0:0: [sda] tag#58 CDB: Read(10) 28 00 01 ac b3 20 00 00 08 00 [ 253.415343] I/O error, dev sda, sector 28095264 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 However, this disk uses LVM. Should the fsck command be run on the underlying disk /dev/sda, or on the LVM partitions /dev/mapper/...?

I had a irregular powercut 4-5 times in a row within an hour. My ubuntu suddenly went into busy box mode and showed there are errors on /dev/sda5. I then tried: fsck /dev/sda5 -y It has taken a lot of time more than an hour and still forcing rewrite. It seems that a lot of blocks are being repaired. Can someone describe what is going on or suggest any fix?

encountered this on Metasploitable 2 **Give root password for maintenance (or type Control-D to continue):** The default root password of **msfadmin** isn't working. It keeps saying login incorrect. Please what is the correct password and how do I resolve this

**System**: macOS 10.14.6 **Overview**: One of the HDD in the system was giving issues and I suspected the old disk was dying. I wanted to check for bad sectors on it. It uses the Mac OS Extended (Journaled) filesystem. So I started a scan of the disk with fsck_hfs: bash-3.2# fsck_hfs -S -E /dev/disk0 But even after more than 12-13 hours overnight it had only scanned around 66% of the 1TB drive: ** /dev/rdisk0 (NO WRITE) Scanning entire disk for bad blocks Scanning offset 6615812001408 of 1000204886016 (66%) and I had to interrupt it as the system was needed. **Questions**: 1. Does FSCK mark the bad sectors as it scans for it (or does it do it only do this after the scan is complete?) 2. If the first case is true, is there any option to resume scanning from the offset specified in the status message (i.e from block 6615812001408)? 3. Is there any better system tools to scan disks for bad sectors which supports resume if the operation has to be interrupted?

I've got Raspbian running on a Raspberry Pi 4 B. I have a USB hard disk that I'm using with it. The hard disk is a 1TB drive formatted with a single partition using ExFAT. I've got exfat-fuse and exfat-utils installed. The problem is that every time I unmount the partition, when I run fsck on that partition, it gives me this warning:

WARN: volume was not unmounted cleanly.

That makes me nervous. This happens no matter how the partition is unmounted. It happens on shutdown and subsequent bootup, it happens on reboots, it happens if I just manually sudo umount /dev/sda1 and sudo mount /dev/sda1 Here's some system information:

Linux rpi4b 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

exfat-fuse/stable,now 1.3.0-1 armhf [installed]
exfat-utils/stable,now 1.3.0-1 armhf [installed]

This is the line concerning the partition in my /etc/fstab.

UUID=BE1B-4EFA  /media/BE1B-4EFA      exfat   defaults,auto,users,rw,nofail  0       0

Why isn't my partition unmounting cleanly? How can I make sure it does?

I'm trying to read old IDE disks through an USB adapter on my Linux Mint machine. One issues a "Can't read superblock on /dev/sdb1" when I try to mount it. I use dumpe2fs to get the superblock :

sudo dumpe2fs /dev/sdb1 | grep superblock
[sudo] password for mc:                
dumpe2fs 1.47.0 (5-Feb-2023)
  Primary superblock at 0, Group descriptors at 1-1
  Backup superblock at 32768, Group descriptors at 32769-32769
  Backup superblock at 98304, Group descriptors at 98305-98305
  Backup superblock at 163840, Group descriptors at 163841-163841
  Backup superblock at 229376, Group descriptors at 229377-229377
  Backup superblock at 294912, Group descriptors at 294913-294913
  Backup superblock at 819200, Group descriptors at 819201-819201
  Backup superblock at 884736, Group descriptors at 884737-884737
  Backup superblock at 1605632, Group descriptors at 1605633-1605633
  Backup superblock at 2654208, Group descriptors at 2654209-2654209

That gives me the value needed : 32768 Then I can use it to perform a fsckcommand:

sudo fsck -b 32768 /dev/sdb1
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 10642 extent tree (at level 1) could be shorter.  Optimize? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23866, counted=1085).
Fix? yes
Free blocks count wrong for group #1 (32080, counted=317).
Fix? yes
Free blocks count wrong for group #2 (32768, counted=1008).
[long list of messages]
Directories count wrong for group #82 (0, counted=621).
Fix? yes

Free inodes count wrong (703125, counted=430832).
Fix? yes

Padding at end of inode bitmap is not set. Fix? yes

Error writing file system info: Remote I/O error

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

Last but one message states "Error writing file system info: Remote I/O error", and the disk is not repaired. Could anyone help me with this issue? I can't figure it out. Is it due to the fact that I use an USB adapter? Is the issue related to some (un)fixable condition of the disk? Best regards, MC

I have mounted an external hard drive via /etc/fstab with the following entry: UUID=a8286fc9-5b08-41d9-8c4e-cb993a8976d1 /home/bu/safe-heaven-2/ ext4 defaults 0 I can read/write from this disk but I have some issues related to making backups via backintime (see below). So I started to poke around and see if I can find out anything but for some reason, I cannot see this drive with any of the commands mount, blkid or lsblk. So I am stuck. What can be the reason for this? The 'actual' issue at hand: This is a new 2TB drive I use for making backups but for some reason backintime keeps telling me that the disk is full at some point. This can't be true as I am trying to (partially) back up a disk that is only 1TB big and by no means full. When I try to do a fsck /home/bu/safe-heaven-2 on this disk, I get the following error: fsck.ext4: Unable to resolve 'UUID=a8286fc9-5b08-41d9-8c4e-cb993a8976d1' But as I wrote, I can read / write to this disk. I am totally confused :D Please help! Edit: Output of fdisk -l as requested: Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 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 Disk /dev/mmcblk0: 14,9 GiB, 15931539456 bytes, 31116288 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: 0x1ddfbf63 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA) /dev/mmcblk0p2 532480 31116287 30583808 14,6G 83 Linux Disk /dev/sdb: 931,5 GiB, 1000170586112 bytes, 1953458176 sectors Disk model: Elements 10A8 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: 0x07e93288 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 1953458175 1953456128 931,5G 83 Linux

Inode usage go from 1 to 100% on a single file creation in a raid array on Debian. First, clean boot, then:

sudo cryptsetup luksOpen /dev/RaidVG/LVMVol CVol
sudo mount /dev/mapper/CVol /mnt/raid/

Checking inode usage

$ df -ih
Filesystem           Inodes IUsed IFree IUse% Mounted on
/dev/mapper/CVol   117M    11  117M    1% /mnt/raid

Then, doing any touch on /mnt/raid, it failed saying disk is full. My inode usage ramped up at 100% :

$ df -ih
Filesystem           Inodes IUsed IFree IUse% Mounted on
/dev/mapper/CVol   117M  117M     0  100% /mnt/raid

Counting files inside /mnt/raid returns :

$ find | cut -d/ -f2 | uniq -c | sort -n
      1 .
   6033 d1
  14070 d2
  31211 d3
 145866 d4
 184352 d5

fsck can't seems to finish

$ sudo fsck /dev/mapper/CVol
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
/dev/mapper/CVol contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create? no
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Signal (6) SIGABRT si_code=SI_TKILL

Also df -h return wrong values : there is more than 1T in use in reality:

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/CVol  1.8T   77M  1.7T   1% /mnt/raid

I don't really know what to do or where to look at. My file system is "read only" but is there a risk of losing data here? How to fix the problem and be able to write on this disk again? **EDIT** smartctl -a

=== START OF INFORMATION SECTION ===
Vendor:               WD
Product:              My Passport
Revision:             1028
Compliance:           SPC-4
User Capacity:        2,000,365,289,472 bytes [2.00 TB]
Logical block size:   512 bytes
LU is resource provisioned, LBPRZ=0
Rotation Rate:        5400 rpm
Serial number:        WX22A30FX287
Device type:          disk
Local Time is:        Fri Mar 28 12:10:55 2025 GMT
SMART support is:     Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

No self-tests have been logged

mdadm --examine-badblocks

Bad-blocks list is empty in /dev/sda1
Bad-blocks list is empty in /dev/sdb1

fdisk -l /dev/sda /dev/sdb

Disk /dev/sda: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Disk model: My Passport 
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: 0x1dfd4f21

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3906963455 3906961408  1.8T fd Linux raid autodetect


Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Disk model: My Passport 
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: 0x9f2cb37d

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb1        2048 3906963455 3906961408  1.8T fd Linux raid autodetect

pvs

PV         VG     Fmt  Attr PSize  PFree
  /dev/md0   RaidVG lvm2 a--

I had to hard-reset my Ubuntu system after a memory leak made it unresponsive. After that, the home partition (which is encrypted with LUKS) wouldn't mount anymore. Decrypting it works fine however, so it must be the file system, which is JFS. From the emergency console I did a simple fsck on the mapped device, which returned a Filesystem is clean. Since the device would still not mount, I did fsck -f to force a full check, which reported no errors or corrections. I verified by dumping the log with jfs_fscklog. The device still doesn't mount. I get wrong fs type, bad option, bad superblock, missing codepage or helper program, or other error when trying to mount it. What could be wrong? What else could I try to recover it?

I have an external Toshiba hard disk. I tried to make it a bootable drive, but during the process, it became corrupted. and It wasn't showing up on windows. I am not able to access it on windows but shows as the /dev/sda in my ubuntu OS. I don't need to recover any data therefore making it usable is my only goal here. The command sudo fsck /dev/sda gives this response: fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/sda 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 or e2fsck -b 32768 Using any of the above suggested commands gives the same response. How do I make it usable? Does the date 5-feb-23 implies the last day this disk was accessed? Edit: lsblk shows it as: sda 8:0 0 1.8T 0 disk output for sudo parted -l: Error: /dev/sda: unrecognised disk label Model: TOSHIBA External USB 3.0 (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags:

I have error in operating system Oracle Linux cannot startup and got this error Problem in HTREE directory inode please see the image error of the system when reboot : what is the error reason and how to fix the error I am not LINUX administrator and thank you in advance

I have mounted raid1 luks non-root partition which is automated through created mount unit. Recently I've discovered that the FS is corrupted and decided to fsck it remotely without rebooting the server. So, I've stopped the unit. And tried fsck it, and got the response that the device is still seen mounted. The same happens when I try to umount manually: it refers that the resource is busy, and only lazy umount works but the result is the same, as with stopping the unit. So, I've decided to change the Options=defaults,noauto in the mount unit. Stopping/starting leads to the the errors. In the log I see: kernel: [258607.858951] dm-1: Can't mount, would change RO state. So, how to do it properly to umount the partition and fsck it without rebooting to live mode wich cannot be controlled remotely?

Following my System76 Debian laptop battery drained and the computer shut down, I could not boot the device that I could solve with a live cd and fsck -y but the QEMU/KVM virtual machine it contained cannot be booted because the issue at the bottom. I tried to fix it using the same method: mounting a live cd and running fsck, but that exists with error code 9. I'm wondering if is this different to fix because of the VDA disk that contains my /home directory. How do you make it boot again? Thank you for any help :pray:

/dev/vda1: clean, 1811334/15863040 files, 14275857/63692544 blocks 
[ 2.767035] blk_update_request: I/O error, dev vda, sector 515741952 op Ox0:( READ) flags 0x80700 phys_seg 2 prio class 0 
[ 2.776713] blk_update_request: I/O error, dev vda, sector 515742552 op Ox0:( READ) flags Ox0 phys_seg 1 prio class 0 
[ 2.777028] Buffer I/O error on dev vda6, logical block 524395, async page re ad [ 2.778294] blk_update_request: I/O error, dev vda, sector 515742552 op Ox0:( READ) flags Ox0 phys_seg 1 prio class 0 
[ 2.778538] Buffer I/O error on dev vda6, logical block 524395, async page re ad [ 2.779791] blk_update_request: I/O error, dev vda, sector 515742552 op Ox0:( READ) flags Ox0 phys_seg 1 prio class 0 
[ 2.779792] Buffer I/O error on dev vda6, logical block 524395, async page re ad [ 2.780884] blk_update_request: I/O error, dev vda, sector 515742552 op Ox0:( READ) flags Ox0 phys_seg 1 prio class 0 
[ 2.780885] Buffer I/O error on dev vda6, logical block 524395, async page re ad "(

I have an external HDD drive formatted as Ext4 connected to my Raspberry Pi server. The server has been crashing lately and as a consequence the HDD is corrupt. When I plug to my computer and run sudo fsck /dev/sda I get the output

fsck from util-linux 2.40.2
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda

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 
 or
    e2fsck -b 32768 

Found a gpt partition table in /dev/sda

I searched online and found [this answer](https://unix.stackexchange.com/a/628354) explaining how to find backup superblocks. However, when I run mke2fs I am not getting a straightforward output as I was expecting, neither on the device (sda) nor on the partitions (sda1 or sda2), and I don't want to proceed if I don't know what I'm doing. I'm afraid I will break something. These are the outputs: * sudo mke2fs -n /dev/sda

mke2fs 1.47.0 (5-Feb-2023)
    Found a gpt partition table in /dev/sda
    Proceed anyway? (y,N)

* sudo mke2fs -n /dev/sda2

mke2fs 1.47.0 (5-Feb-2023)
    /dev/sda2 contains a ext4 file system labelled 'data'
        last mounted on /srv/dev-disk-by-uuid-19f0b495-7b9d-4f67-ae8e-9f8933ff19eb on Sat Nov  2 13:36:52 2024
    Proceed anyway? (y,N)

* sudo mke2fs -n /dev/sda1

mke2fs 1.47.0 (5-Feb-2023)
    /dev/sda1 alignment is offset by 3072 bytes.
    This may result in very poor performance, (re)-partitioning suggested.
    /dev/sda1 contains a vfat file system labelled 'EFI'
    Proceed anyway? (y,N)

This makes clear to me that the problem is on partition sda1, but I'm still not confident to proceed with mke2fs. The way it asks Proceed anyway? makes me worry I will break something. Moreover, I don't know why the hard drive has 2 partitions nor what the EFI partition sda1 is (this is not a system drive, just an external data drive, although it has docker containers installed in it). Is mke2fs -n the right command for me here? If so, should I run it on sda or sda1? Should I repeat what I did and select Proceed anyway?

I have created a custom Plymouth theme (based on MIB Ossigeno) configured to process fsck's messages coming from systemd-fsckd by implementing the communication protocol whose message has the following format: fsckd::: According documentation (8-systemd-fsckd.service ) When executed it, in test mode ("post-boot"), using the command: plymouthd; plymouth --show-splash ; for ((I=0; I<10; I++)); do plymouth --update=fsck:sda1:$I ; sleep 1; done; plymouth quit With special FSCK messages, plymouth shows desired messages, like "Checking disk 1 of 1 (2% complete)". See: Plymouth . So far, so good. But when restarting the system, the fsck messages are not displayed on bootsplash. But if I switch to console by pressing Esc key, fsck progress messages are visible. To force fsck to run at boot, I have alternately used tune2fs and grub (GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fsck.mode=force fsck.repair=yes") to see if there were any implications. For some reason the communication between fsck and Plymouth is not working or working well. The default theme, futureprototype, does not work either. I guess the problem is in systemd-fsckd, How does one determine whether systemd-fsckd's tasks were performed at bootup?, Is there a report or status that shows whether any issues were found? I look in /run/initramfs/fsck.log (this looks good): ~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda1 Wed Feb 28 15:26:27 2024 e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 212266/593344 files (0.2% non-contiguous), 1705537/2371072 blocks Wed Feb 28 15:26:30 2024 Journal... ~# journalctl -u systemd-fsck* -- Boot f8b976dfd857400085057901577c56f9 -- feb 28 10:40:53 debian12 systemd[1] : Started systemd-fsckd.service - File System Check Daemon to report status. feb 28 10:41:23 debian12 systemd[1] : systemd-fsckd.service: Deactivated successfully. feb 28 10:51:02 debian12 systemd[1] : Started systemd-fsckd.service - File System Check Daemon to report status. feb 28 10:51:32 debian12 systemd[1] : systemd-fsckd.service: Deactivated successfully And systemctl ~# systemctl status systemd-fsckd.socket ● systemd-fsckd.socket - fsck to fsckd communication Socket Loaded: loaded (/lib/systemd/system/systemd-fsckd.socket; static) Active: active (listening) since Wed 2024-02-28 15:26:31 -03; 16min ago Triggers: ● systemd-fsckd.service Docs: man:systemd-fsckd.service(8) man:systemd-fsck@.service(8) man:systemd-fsck-root.service(8) Listen: /run/systemd/fsck.progress (Stream) CGroup: /system.slice/systemd-fsckd.socket ~# systemctl status systemd-fsckd.service ○ systemd-fsckd.service - File System Check Daemon to report status Loaded: loaded (/lib/systemd/system/systemd-fsckd.service; static) Active: inactive (dead) TriggeredBy: ● systemd-fsckd.socket Docs: man:systemd-fsckd.service(8) The goal is to notify the user that the boot process is delayed by fsck's disk check and to view its progress. I have exhausted all my resources and have found nothing on the web. In general, all I find is about hiding boot messages. ~# more /etc/debian_version 10.13 ~# uname -a Linux debian 4.19.0-26-686-pae #1 SMP Debian 4.19.304-1 (2024-01-09) i686 GNU/Linux For reasons that are not relevant, the development is on OS Debian 10, although I have also tried with Debian 12 with the same result. PD: A detail that may be relevant: the tests with Debian 10 and Debian 12 were both carried out on virtual machines on Virtual Box. More test: **Case one:** Debian 10 on Virtual Box. The fsck messages do not appear and the journal shows the following: root@debian:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@debian:~# journalctl -b /usr/lib/systemd/systemd-fsck -- No entries -- root@debian:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- No entries -- root@debian:~# journalctl --boot | grep systemd-fsck* mar 04 13:07:01 debian systemd[1] : Listening on systemd-fsckd.socket - fsck to fsckd communication Socket. mar 04 13:07:01 debian systemd[1] : systemd-fsck-root.service - File System Check on Root Device was **skipped** because of an unmet condition check (**ConditionPathExists=!/run/initramfs/fsck-root**). root@debian:~# cat /run/initramfs/fsck.log Log of fsck -C -a -T -t ext4 /dev/sda1 Mon Mar 4 13:06:59 2024 /dev/sda1: clean, 212351/593344 files, 1708897/2371072 blocks Mon Mar 4 13:06:59 202 **Case Two:** Debian 10 on physical PC (amd64). In this case the messages are visible, but at the end of the process and very few seconds. Nothing is displayed during execution of fsck. root@Dell:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@Dell:~# journalctl -b /usr/lib/systemd/systemd-fsck -- Logs begin at Mon 2024-03-04 15:58:16 -03, end at Mon 2024-03-04 19:25:01 -03. -- mar 04 15:58:21 Dell systemd-fsck: e2fsck 1.44.5 (15-Dec-2018) mar 04 15:58:21 Dell systemd-fsck: Pass 1: Checking inodes, blocks, and sizes mar 04 15:58:21 Dell systemd-fsck: Pass 2: Checking directory structure mar 04 15:58:21 Dell systemd-fsck: Pass 3: Checking directory connectivity mar 04 15:58:21 Dell systemd-fsck: Pass 4: Checking reference counts mar 04 15:58:21 Dell systemd-fsck: Pass 5: Checking group summary information mar 04 15:58:22 Dell systemd-fsck: /dev/sda1: 1034/69360 files (0.7% non-contigu root@Dell:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- Logs begin at Mon 2024-03-04 15:58:16 -03, end at Mon 2024-03-04 19:25:01 -03. -- -- No entries -- root@Dell:~# journalctl --boot | grep systemd-fsck* mar 04 15:58:21 Dell systemd-fsck: e2fsck 1.44.5 (15-Dec-2018) mar 04 15:58:21 Dell systemd-fsck: Pass 1: Checking inodes, blocks, and sizes mar 04 15:58:21 Dell systemd-fsck: Pass 2: Checking directory structure mar 04 15:58:21 Dell systemd-fsck: Pass 3: Checking directory connectivity mar 04 15:58:21 Dell systemd-fsck: Pass 4: Checking reference counts mar 04 15:58:21 Dell systemd-fsck: Pass 5: Checking group summary information mar 04 15:58:22 Dell systemd-fsck: /dev/sda1: 1034/69360 files (0.7% non-contiguous), 189933/276480 blocks mar 04 15:59:01 Dell systemd[1] : systemd-fsckd.service: Succeeded. root@Dell:~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda2 Mon Mar 4 18:57:36 2024 e2fsck 1.44.5 (15-Dec-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda2: 673194/9551872 files (0.8% non-contiguous), 29651430/38200576 blocks Mon Mar 4 18:58:11 2024 ---------------- **Case three:** Debian 10 on physical PC (amd64) with multiple entries grub menu (Debian and other bootable partitions with Windows). root@5VQU7SN:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@5VQU7SN:~# journalctl -b /usr/lib/systemd/systemd-fsck -- Logs begin at Mon 2024-03-04 15:38:25 -03, end at Mon 2024-03-04 20:39:47 -03. -- -- No entries -- root@5VQU7SN:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- Logs begin at Mon 2024-03-04 15:38:25 -03, end at Mon 2024-03-04 20:39:47 -03. -- -- No entries -- root@5VQU7SN:~# journalctl --boot | grep systemd-fsck* -- No entries -- root@5VQU7SN:~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda6 Mon Mar 4 18:37:59 2024 e2fsck 1.44.5 (15-Dec-2018) /dev/sda6: recovering journal Clearing orphaned inode 15992282 (uid=1000, gid=1000, mode=0100644, size=32768) Clearing orphaned inode 15991323 (uid=1000, gid=1000, mode=0100600, size=460) Clearing orphaned inode 15990858 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990852 (uid=1000, gid=1000, mode=0100600, size=131072) Clearing orphaned inode 15990840 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990827 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990826 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990859 (uid=1000, gid=1000, mode=0100644, size=4132) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong (112010854, counted=112010689). Fix? yes Free inodes count wrong (28961618, counted=28961585). Fix? yes /dev/sda6: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sda6: 292047/29253632 files (0.3% non-contiguous), 4981311/116992000 blocks fsck exited with status code 1 Mon Mar 4 18:38:19 2024 ---------------- This issue is becoming quite complex and I don't see where to move forward. I hope there is some expert collegue who can help me in this matter. STATUS UPDATE: I found that the default Plymouth theme worked on another PC, and when I installed my theme, it worked too. I spent days checking grub, fsck, and plymouth configurations, but I couldn't find a difference. Until I noticed that on that PC the /boot directory was mounted on a different partition from the root. Install Debian from scratch on a physical and a virtual PC, with /boot separately. And it worked!!! Could it be a bug of systemd-fsck?