Asking for a friend. He’s just done an update to his system and is getting a Grub message saying that he needs to load the kernel first. We have tried chrooting into his system to re-install the kernel but this fails having tried to mount /dev/sda1. The error message is
/bin/bash Input/output error
Mate has tried starting the machine from one of the fallback images in Grub but nothing happens. I think this is due to there being no initramfs images in /boot. How do we regenerate a initramfs image in this situation?
Chroot into the system and run update-grub.
He can’t chroot into the system. Thats one of the problems.
Could be corrupted filesystem. What filesystem are you using? If ext4, fsck is your friend
can you check
boot from USB iso manjaro
Step 1
sudo manjaro-chroot -a ( if only 0 appears type 1 )
mkinitcpio -P
exit
-
check if all /etc/mkinitcpio.d/*.preset are presents with mhwd-kernel -li
you have to get one preset for one linux version
-
check also if latest is present , then remove all ( kernel , header , drivers with kernel )
and redo step 1
@ stephane
He cannot chroot in at all.
@ Chrysostomus
/dev/sda1 is ext4
can you run a fsck on partition ?
if no more chroot possible , do backup data ( home ) , and re-install
He has tried fsck but is told that the partition is in use.Rebooted, unmounted /dev/sda and /dev/sda1. Now getting “bad magic number in superblock”.
I’m guessing this is heading for a re-install 
Howdy!
What is the output of lsblk in the live session , may I ask?
Which are the boot and system partitions?
Is it a EFI installation?
@ The_Quantum_Alpha
My mate has gone offline for the night. We can have a look @ lsblk in the morning. IIRC boot and system are both on /dev/sda1.
I think it is an EFI install. I think that Grub shows the boot partition as (hd0, gpt2) I have to admit that I tend to stick with MBR on a legacy Bios system.
Why was it mounted? Can you reboot the live system without mounting /dev/sda?
lsblk shows a single ext4 partition.
grub.cfg is hd0, gpt1. Not sure how i tell whether is is an EFI install though. I don’t think /boot/efi exists so I am guessing that this is not an EFI installation
You can copy the backup superblock to superblock, which is bad.
I think we have taken the path of least resistance and re-installed the OS. Thanks for all your help.
Just in case someone see this later. You can solve this by replacing the first superblock with a backup superblock on the disk:
dumpe2fs -h /dev/sdY
will show you the block number of all superblocks like this:
dumpe2fs 1.42.9 (28-Dec-2013)
Primary superblock at 0, Group descriptors at 1-2
Backup superblock at 32768, Group descriptors at 32769-32770
Backup superblock at 98304, Group descriptors at 98305-98306
Backup superblock at 163840, Group descriptors at 163841-163842
Backup superblock at 229376, Group descriptors at 229377-229378
Backup superblock at 294912, Group descriptors at 294913-294914
Backup superblock at 819200, Group descriptors at 819201-819202
Backup superblock at 884736, Group descriptors at 884737-884738
Backup superblock at 1605632, Group descriptors at 1605633-1605634
Backup superblock at 2654208, Group descriptors at 2654209-2654210
Then you need to repair the file system:
fsck -b 32768 /dev/sdY
You can try every superblock until it repairs correctly.
Also… i would guess that the HDD has badblocks. The file system needs to know that there are badblocks and that it should skip them. More information here: badblocks - ArchWiki
1 Like
@megavolt
Nice writeup! Definitely something to note for later!
I know the issue is fixed in meantime (by re-install) but reading that made me 
Because /dev/sda means the whole disk and /dev/sda1 means first partition on that disk…
So how you guys managed to mount both is 
me, as you can’t have a partition table if you have a filesystem formatted on the raw disk space…
(Which is the reason for that error message about superblock)