128GB eMMC drive on ASUS laptop - unable to format to ext4

Question

I got a new ASUS BR1100FKA laptop as a gift. This model got a 128GB eMMC as its primary drive. Tried to install EndeavourOS, before letting out an error. The installer complaints about "input/output" error, while formatting to ext4.

Fast forward a month, and I still can't figure it out. As an alternative, I made a persistent USB pendrive installation. The 32GB space is not very forgiving, though.

Here's what I have tried:

1. Formatting it with GParted on the live USB environment. GParted throw out more or less the same error on ANY operation that changes the partition's place, size, and filesystem. An exception for NTFS, though. It return Input/Output error while syncing device, but the partition is fixed automatically after mounting.

2. Formatting from Windows 10. I've tried AOMEI assistant, EaseUS Partition Tool, DiskGenius, and a tool that I forgot. AOMEI assistant won't format to ext4 unless if I purposely manipulate the C: drive on Win10. That way, AOMEI will do its operation in Win PE mode, and somehow succeeded. The resulting ext4 partition however, are prone to random errors. Here's a list:

• Copying files from /home directory through Thunar File Manager with gvfs installed returns no error. However, trying to mount them through /etc/fstab always failed and took me into the emergency mode. Only after commenting out the responsible line in /etc/fstab allow me to boot properly. Mounting them manually afterwards return can't read superblocks.

• Using rsync with -v option, I can see occasional lines of EXT4 ERROR, but it was scrolling too fast. Maybe I will try to catch it later.

• cp command is more stable, usually ending with no error. It does get the same /etc/fstab error, though. The error thrown out are Input/Output Error.

• dd command is very unstable, and ending up with I/O error

• ddrescue never dropped an error, but copying the OS partition means that the partition need to fixed afterwards. Not possible on Win10, as far as I know.

• Because Calamares defaults to formatting the partition first, I tried to do vanilla Arch installation. When installing base, linux-lts, and linux-firmware through pacstrap, several I/O errors get thrown out and pacstrap just stopped without installing after download is finished

• Tried to fsck the drive afterwards. After long list of errors, fsck ended up with I/O Error on one consistent fix (Could not be recreated for now, the list of errors means that I need to press the Enter button for like an hour, or automate the press and having to watch the last error, which still takes 30 minutes.)

3. BIOS Update I updated my BIOS manually through the EZ Smart Flash utility by ASUS. The firmware is downloaded from the MyASUS app on Win10. Not too many difference.

4. Disabled TPM. No difference, except that I can't login into Win10 like usual.

5. Manual formatting. Used mkfs.ext4 command with -v option. Here's the error: Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system.

A lot of Google results on I/O Error shows hardware failure, altough I doubt that is the case. I also read a lot about booting from eMMC, but I would like to tackle formatting them first. There are some pople who have tackled this with BIOS settings that are non-existent on mine.

I have tried Gparted from KDE-Neon and EndeavourOS.

Any help would be appreciated!

Answer 1

Same story here with my ASUS BR1100FKA, 128GB eMMC and Ubuntu 20.04.

It seems the laptop has eMMC controller with buggy CQE implementation.

Since linux kernel version 5.5 it is possible to make system avoid using CQE by specifying debug_quirks=0x20000 option to sdhci module. (0x20000 is the value for SDHCI_QUIRK_BROKEN_CQE flag in sdhci.h). After properly propagating the option I was able to install and use Ubuntu 20.04 with ext4 rootfs on the eMMC drive of this laptop.

There are few common ways to push the option to the system, depending on the situation you're in:

Way 1: Unload the module and reload it with the option specified.

sudo modprobe -r sdhci_pci
sudo modprobe -r sdhci
sudo modprobe sdhci debug_quirks=0x20000
sudo modprobe sdhci_pci

This works when the system isn't going to access eMMC drive during boot. For example, you are in some kind of linux installer and about to begin installation on the eMMC drive.

Way 2: Specify sdhci.debug_quirks=0x20000 option to the kernel command line.

This often can be done with bootloader menu. It might save the day when the eMMC drive is used during boot and you didn't have a chance to burn the option via /etc/modprobe.d to initramfs.

Way 3: Use /etc/modprobe.d

Create a file like /etc/modprobe.d/sdhci-disable-cqe.conf which contains:

options sdhci debug_quirks=0x20000

This is usually "the right" way to permanently tweak module load behaviour. However, in order for it to work at early boot, one should make sure the config file gets to initrd image. Ways to do this may differ across distributions. For Ubuntu it's usually running sudo update-initramfs -u after creating/editing a file in /etc/modprobe.d.

PS: From what I see - debug_quirks thing seems to be the only available option for disabling CQE on common kernel builds. The issue seems to be rare and usually encountered on some specific non-x86 hardware. I was really desperate and about to order an SSD, the idea to dig sdhci source code for all available options in response to some (non-CQE related) debug_quirks mentions came up just the last moment =)

Answer 2

I had the same issue on a ASUS BR1100FKA.

The device does have an unused m.2 slot you could get a cheap pcie m.2 ssd (it doesn't work with sata) and put linux on that.

EDIT: Here are the tear-down instructions. https://youtu.be/T6lysjmaBSA.

Some notes:

1. The case screws fit a PH1 screwdriver
2. As mentioned before, it must be a standard sized (80mm) m.2 NVME SSD. Sata m.2 SSDs may fit, but the board won't recognize them.
3. The m.2 slot doesn't have a screw preinstalled, so you will need to get one.