Well, it seems you do have a kernel installed. So I suspect your GRUB is merely messed up. See
@Mirdarthos, when the partitions are not detected a restore of the boot loader won’t work. 
2 Likes
That be true, yes. Should have caught that. My apologies.
You are now in chroot and can proceed.
No, that is the running kernel - the one from the live system, from the ISO.
mhwd-kernel can be used to list available kernels - but not to install them from within chroot. -l works, but -i doesn’t
pacman has to be used instead:
pacman -S linux54
for instance
then
mkinitcpio -P
and
grub-mkconfig -o /boot/grub/grub.cfg
to update the grub menu
2 Likes
… not a good combination 
1 Like
Yeah, just realized this now On the toilet, of all places.
Man, this…this whole…everything makes my head hurt.
Too many operating systems…
Oh - I didn’t see that one. 
So, he will need to proceed with a more hands-on approach:
“manually” mount the correct partitions - in the correct order - to /mnt for instance
and then
manjaro-chroot /mnt /bin/bash
since manjaro-chroot -a
(the “automatic” variant of the chroot command)
will apparently choose the wrong (Ubuntu) system
2 Likes
Fastboot is disabled in bios & windows hibernating is disabled. Still not detecting partition
see my post above
You apparently have Ubuntu installed besides Manjaro as well
and the automatic detection will choose the wrong (Ubuntu) system to chroot into.
You will need to identify and mount the correct partitions (Manjaro) yourself
and then chroot like described.
2 Likes
It not detecting the nvme partition in which manajro is installed
What is “it”?
… you could mount every partition, one at a time, and look at the contents to determine which is which … if you don’t know which is which …
nvne0n1p6 Is the partion which have manjaro.
sudo mount /dev/nvme0n1p6 /mnt ✔
mount: /mnt: can't read superblock on /dev/nvme0n1p6.
dmesg(1) may have more information after failed mount system call.
If that is indeed the right partition, it is apparently damaged.
You could try running a file system check on it - using a different superblock than the default.
How to do that … you’ll have to research yourself because I do not know of the top of my head and would need to look and read and try … myself.
1 Like
Adding this parameter(GRUB_CMDLINE_LINUX=“quiet splash nvme.noacpi=1 nvme.timeout=30”)
will detect the ssd and will be able to install the kernel. But it is showing this error while updating grub
~ sudo vi /etc/default/grub INT ✘
~ sudo grub-mkconfig -o /boot/grub/grub.cfg ✔ 20s
/usr/bin/grub-probe: error: failed to get canonical path of `overlay'.
Are we talking about doing things in chroot - or not?
If we are talking about doing things in chroot, using sudo doesn’t make any sense
because you literally are root when in chroot.
and:
the error is lacking context - it may not even be relevant
If you are lost and need help, you need to show us what you see, so we see what you see in it’s entirety, not just parts of it …
… and if you are not doing this:
within chroot, you are doing it wrong …
2 Likes
If the superblock of that partition is damaged you can recover it from a filesystem backup. If your filesystem is ext4, then first run:
sudo mke2fs -n /dev/nvme0n1p6
Press “y” to continue and show us the result. It will show the location of backups, something like this (just an example, will look differently!):
/dev/nvme0n1p6 contains a ext4 file system labelled '<what-so-ever>'
last mounted on / on <any date>
Proceed anyway? (y,N) y
Creating filesystem with <no. of blocks> 4k blocks and <no. of inodes> inodes
Filesystem UUID: <actual UUID>
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
With the command
sudo e2fsck -b <location given> /dev/nvme0n1p6
the superblock can be recovered. <location given> to be replaced by one of the actual given location.
2 Likes
Can you please describe this in more detail?
It seems that it is not just the kernel that has been deleted.
If you can describe what you have done in more detail, it might be easier to fix the problem. Otherwise there is a risk that even more things will be broken during the repair attempts. 
2 Likes
Thank you for finally answering.
I recommend you disconnect the HDD with Windows 10 an Ubuntu before continuing. It can be reconnected later (after Manjaro is installed to the SSD).
When you have done this, you should be able to target the SSD without the HDD causing complication.
From what I’ve gleaned from above, you might be better served starting the Manjaro again.
Regards.