Error: Volume corruption while loading vmlinuz...

[Jose Silva]

Hello,

Thank you so very much for this very useful piece of software. I've been using it for about 3 years on a Macbook Pro 8.2

But now I needed to change my disk and so I copied the MacOS apfs, the data partition, an Artix (Manjaro) partition and a Gentoo partition.

The Gentoo partition is the only one not working, showing "Error: Volume Corruption while loading vmlinuz-4.14.65-gentoo"

This exact setup was working on another disk, with initramfs and vmlinuz in the /boot folder, in the root filesystem, with a refind-linux.conf with "root=UUID=....", which is correctly pointing to the volume.

I then copied initramfs, vmlinuz and refind-linux.conf to the ESP in /boot/efi/EFI/gentoo and it shows up as another menu entry that now works.

I presume the drivers are ok, since they are loading the Artix partition which also uses ext4 and the same scheme, with the kernel and conf file in the boot folder of the root filesystem.

I can live with this setup, although it's a bit inconvenient because I cannot forget to copy the kernel to the ESP whenever I upgrade the kernel, which happens very often with Gentoo. But it woul be nicer to have it right.

So, can anybody give me a lead about what's happening, please?

TIA,
jss

[Roderick W. Smith]

"Volume corruption" suggests just that -- the partition's filesystem may be damaged. Several possible reasons for this spring to mind:

• If you did a low-level copy of your computer's partitions (using dd or some disk-cloning tools), it may have been corrupted in the transfer.
• If you used tar, cp, or some other file-level tool, then it's possible that the filesystem was created (via mkfs) incorrectly, or simply suffered random damage at some point.
• It could be that the partitions were created incorrectly, so that two partitions overlap one another. This would be likely to result in filesystem damage. Using the v option in gdisk will tell you if any of your partitions overlap one another.
• If the disk is over 2GiB in size, it could be that some OS or utility is using 32-bit pointers and therefore causing damage to some partitions. This type of problem was common in Windows a few years ago. It's less common today, but it could still be happening.
• The disk itself may be failing. You can run a SMART utility, like GSmartControl, to check for some common problems; but sometimes disk failures elude diagnostic tools until it's too late.

Running a filesystem check (fsck) from Linux on the partition should clear up most of these types of damage, but the issue may recur, depending on the cause. If your disk hardware is failing, you should replace it immediately.

Another possibility is that the filesystem is using a feature that's not supported by the EFI driver you're using. For instance, rEFInd's ReiserFS driver lacks support for that filesystem's tail-packing feature, so you must disable it via the notail option in /etc/fstab. You mentioned ext4fs, and rEFInd's ext4fs driver works with most ext4 filesystems; however, I can't guarantee that it works with all ext4fs features. If you created the filesystem with exotic options, that could be the issue. The fix in this case would be to re-create the filesystem with more mundane options (if this is not too inconvenient). If necessary, you can shrink a large filesystem by 1GiB or so, create a fresh partition in the freed space, and use that as a new /boot partition so that you can adjust filesystem options or even use an entirely different filesystem.