I’ve just installed Manjaro using the installer (manjaro-xfce-20.2.1) on my Dell XPS 13 9310. It has a 2TB NVMe drive. After disabling secure boot, I started the installer as normal & the install process went fine (no wifi adapter detected, but I believe that should be fixable according to the arch wiki). As a work-around, I just tethered to my phone, as I believe the 5.10 kernel should work better with the AX500, but the point is the install had internet access & went fine. I did not configure LUKS, but did create a swap partition (using the automatic option from the installer, erasing the entire NVMe disk).
On the next boot, I got dropped into a rescue shell unable to find the hibernation or root device, and with no output at all from blkid, and no block devices visible in /dev.
Exact output as follows, unsure why I’m unable to link or embed this:
imgur (dot) com/sjFSg4o
What I’d usually do here is run lsblk or blkid to figure out what went wrong & update my fstab accordingly, however it seems that no drives are being detected at all (blkid exits with code 2). Really not sure what’s wrong here, does anyone have any suggestions?
I have never worked with or did anything with xfce. I’m a KDE user.
I recommend starting the system up and booting with a live ISO. Once successfully booted into the new system, open a terminal and enter a chroot environment:
manjaro-chroot -a
If requested enter the correct installation, 0 by default.
When you’ve successfully entered, you can continue as if you’re working as root on the installation itself. So lsblk should work, and you should be able to edit /etc/fstab.
If the block devices aren’t accessible from the live environment either, I’d say it’s a pretty safe bet that it’s hardware related and not software, so that might be the first thing to check.
After booting into a live USB, chrooting into the installation does work, with the fstab content and blkid outputs as follows:
[manjaro /]# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=99F9-0E1E /boot/efi vfat umask=0077 0 2
UUID=90540605-30a1-4f47-8e71-6c7f8315518b / ext4 defaults,noatime 0 1
UUID=2f7d9894-f99d-402c-a209-2f2146bf1917 swap swap defaults,noatime 0 0
[manjaro /]# blkid
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/sda1: BLOCK_SIZE="2048" UUID="2021-01-03-08-16-14-00" LABEL="MANJARO_XFCE_2021" TYPE="iso9660"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MISO_EFI" LABEL="MISO_EFI" UUID="C274-6DF3" BLOCK_SIZE="512" TYPE="vfat"
/dev/nvme0n1p1: UUID="99F9-0E1E" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="82bd4f98-2314-d542-8d8e-d4bbb3e17560"
/dev/nvme0n1p2: UUID="90540605-30a1-4f47-8e71-6c7f8315518b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="59f99b97-20e2-1b49-8fe9-815e3a6985a4"
/dev/nvme0n1p3: UUID="2f7d9894-f99d-402c-a209-2f2146bf1917" TYPE="swap" PARTUUID="f2346af0-3d2d-5c49-a22b-346aa87ff0a3"
[manjaro /]#
I should also mention that I’ve tried:
Using Manjaro architect to install (this is what I usually do, I only went for a GUI install afterwards to ensure I could reproduce it & I wasn’t going wrong somehow with my Architect install)
Downloading a fresh copy of the installer ISO & burning it, then running the install, after erasing the drive (same result)
When booting up into Windows & into live USBs, there are no issues detecting drives.
In the meantime I’m going to try to perform a Debian install to try to isolate the problem to Manjaro, if that fails then maybe I have ACPI/hardware/firmware issues. Definitely an interim solution though, I really want to be running arch.
I think we can close this - the BIOS was for some mad reason configured to boot the storage devices in RAID mode, which it turns out only Windows is configured OOTB to detect properly. Switching back to NVMe yields a properly working OS.
Well, stupid BIOS then! But I’m very happy you sorted it out! If nothing else, we now know about something else that can/should be checked when something like this happens.