Re: [HELP] LLVM-18.1.7 trashed my EXT4 Journal and probably my SATA Drive too

On 9/22/25 2:58 PM, azazel xes ([email protected] via blfs-support 
Mailing List) wrote:
> It seams that LLVM trashed the filesystem Journal and damaged the SATA 
> drive, does any one has a good backup tip that I can use to backup 
> what I have done so far in (B)LFS, I want to avoid having to start all 
> over again.
>
> What happend:
>
> I was running LLVM test suite and got the following error:
>
> [465.624083]EXT4-fs (sda3): failed to convert unwritten extents to 
> written extents -- potential data loss! (inode 1098125, error -30)
> FAILED: CMakeFiles/install.util
> cd /sources/BLFS/llvm-18.1.7.src/build && /usr/bin/cmake -P 
> cmake_install.cmake
> ninja: build stopped: subcommand failed.
> ninja: error: remove(.ninja_lock): Read-only file system
>
> Message from syslog@localhost at Sun. Sep 14 00:29:49 2025 ...
> kernek: EXT4-fs (sda3):  failed to convert unwritten extents to 
> written extents -- potential data loss! (inode 1098125, error -30)
>
> Message from syslog@localhost at Sun. Sep 14 00:29:49 2025 ...
> kernek: EXT4-fs (sda3):  failed to convert unwritten extents to 
> written extents -- potential data loss! (inode 1098125, error -30)
>
> From that day and until today I have tried all I could find online and 
> even tried with ChatGPT but I couldn't recover the file system, 
> neither I could delete the llvm source folder.
>
> I used a livecd to perform the following:
>
> 1. fsck:
>       fsck.ext4: unable to set superblock flags on /dev/sdc3 
> /dev/sdc3:***** WARNING: Filesystem still has errors ******
>       
>       Tried to backup superblocks, all of them failed with the same 
> message:
>       
>       sudo fsck.ext4 -b 819200 /dev/sdc3 e2fsck 1.47.2 (1-Jan-2025) 
> Superblock needs_recovery flag is clear, but journal has data. 
> Recovery flag not set in backup superblock, so running journal anyway.
>       /dev/sdc3: recovering journal Superblock needs_recovery flag is 
> clear, but journal has data. Recovery flag not set in backup 
> superblock, so running journal anyway.
>       
>       
> 2. e2fsck (latest version) didn't fix the issue either
>
> 3. Check disk health with smartctl
>
>       SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 
> 0x0001 2 0 Command failed due to ICRC error 0x0009 2 1394 Transition 
> from drive PhyRdy to drive PhyNRdy 0x000a 2 1662 Device-to-host 
> register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within 
> host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS
>       
> Changed SATA cable and SATA port in the motherboard and still the 
> issue persisted.
>
> smartctl displays 0 for Reallocated_Sector_Ct, Current_Pending_Sector, 
> and Offline_Uncorrectable.
>
> 4. Tried to remove the LLVM source directory using its inode but failed
>
> 5. Tried to remove the LLVM source directory using the "find" command, 
> but altough it displayed that the directory was gone it was back when 
> I rebooted the system
>
> 6. Tried disable journal → fsck → re-enable journal
>
>       sudo tune2fs -O ^has_journal /dev/sdb3 tune2fs 1.47.3 
> (8-Jul-2025) Recovering journal. tune2fs: Journal flags inconsistent 
> while recovering journal. Please run e2fsck -fy /dev/sdb3.
>
>       sudo e2fsck -b 32768 -f -y /dev/sdb3 e2fsck 1.47.3 (8-Jul-2025) 
> Superblock needs_recovery flag is clear, but journal has data. 
> Recovery flag not set in backup superblock, so running journal anyway.
>       /dev/sdb3: recovering journal Superblock needs_recovery flag is 
> clear, but journal has data. Recovery flag not set in backup 
> superblock, so running journal anyway. Superblock needs_recovery flag 
> is clear, but journal has data. Recovery flag not set in backup 
> superblock, so running journal anyway.
>       e2fsck: unable to set superblock flags on /dev/sdb3 /dev/sdb3: 
> ***** FILE SYSTEM WAS MODIFIED *****
>       /dev/sdb3: ********** WARNING: Filesystem still has errors 
> **********
>       
> 7. Give up, altought SMART looks "clean" the kernel is logging I/O 
> failures at the hardware level in dmesg
>
>       1. Repeated READ FPDMA QUEUED … timeout errors
>       2. ata1: hard resetting link
>       3. Unaligned write command
>       4. NCQ disabled due to excessive errors
>       5. Still ends up with I/O error, dev sda, sector
>       
> [    3.249195] EXT4-fs (sda3): re-mounted 
> 45d0c6aa-44d4-475b-a366-20c9b4969d04 ro. Quota mode: none.
> [   33.414180] ata1.00: exception Emask 0x0 SAct 0x1e0000 SErr 0x0 
> action 0x6 frozen
> [   33.414198] ata1.00: failed command: READ FPDMA QUEUED
> [   33.414202] ata1.00: cmd 60/10:88:28:08:00/00:00:00:00:00/40 tag 17 
> ncq dma 8192 in
>                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 
> 0x4 (timeout)

Hi Azazel,


I'm going to say that the underlying cause under here might be some 
controller corruption in the HDD itself. Based on some of the kernel log 
(which I have snipped because it's very long), such as:


" [  118.870064] ata1.00: device reported invalid CHS sector 0"

" [  118.870073] sd 0:0:0:0: [sda] tag#26 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=30s
[  118.870076] sd 0:0:0:0: [sda] tag#26 Sense Key : Illegal Request 
[current]
[  118.870078] sd 0:0:0:0: [sda] tag#26 Add. Sense: Unaligned write command"


There's no doubt that the controller is failing. SMART data works well 
for tracking mechanical faults, but can miss some things when it comes 
to digital problems. A COMRESET from a controller is a massive red flag.


I've encountered this before with drives when I was doing data recovery, 
and as long as you can mount the partitions you want to backup as 
read-only, you should be OK. That being said though, I would do it fast, 
as there's no guarantee that you can get data back without going to a 
data recovery service if the controller stops working completely.


If there are other partitions that you want to save, you can use 
ddrescue from something like https://www.system-rescue.org/ to save it 
to a full disk image.


Alternatively though, if you just want the LFS partition, I would 
suggest essentially:

- Boot off a LiveCD or other distribution, not on the hard drive.


- Mount another partition from an external hard drive or other media, 
and change into the directory where you mounted it.


- Mount the LFS partition at /mnt/lfs as read-only. (mount -o ro 
/dev/sdXX /mnt/lfs) for example. If you have /home and /boot as separate 
partitions, mount them into /mnt/lfs/{home,boot} like you normally 
would, but you can also back up other partitions in a similar way 
instead if desired.


- Create a tarball of /mnt/lfs. For example, "tar -cJvf 
lfs-partition.tar.xz /mnt/lfs/*", and then you can decompress that on a 
new drive.


Without more details on your setup I can't really do much else, but this 
should give you a good start!


- Doug

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-support
Unsubscribe: See the above information page