You are not logged in.
Greetings everyone,
I am a noob with Arch and this forum. Your forbearance is appreciated! I am hugely impressed with Arch and am a recent convert from Mint.
I would greatly appreciate some advice on an installation problem than I have attempted to describe in detail here (perhaps too much detail?).
Summary: I followed the instructions on the Arch Beginner's Guide to the letter (I think - see below). Installation appeared to go well. When I reboot the first stage of grub loads and I get the "Welcome to GRUB!" message. Then I get "error: no such device: FE82239682235287". If I type ls at the grub rescue prompt I see: (hd0). If I then type ls (hd0) I see: "(hd0) Filesystem is unknown."
Details:
Hardware: Dell XPS 15 laptop with 256GB SSD.
BIOS: it arrived set to RAID (not ACHI) but there is no raid configured (just 1 disk). UEFI is not switched on (boot list option = Legacy). I switched the Fastboot option to "Thorough" from "Minimal" (the only other options is Auto) but that did not resolve or change the problem. Secure Boot is disabled.
Partitions: The SSD has 3 partitions (it is listed as nvme0n1 below, the sda is the bootable USB for installing Arch).
nvme0n1p1 is the boot partition which has grub (and the Microsoft bootmgr.exe files) on it
nvme0n1p2 has Windows 10 on it
nvme0n1p3 is where I installed Arch
Thus, I want to set up a dual boot.
Output of lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 3.8G 0 disk
├─sda1 8:1 1 663M 0 part /run/archiso/bootmnt
└─sda2 8:2 1 31M 0 part
loop0 7:0 0 288.7M 1 loop /run/archiso/sfs/airootfs
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part
├─nvme0n1p2 259:2 0 120.1G 0 part
└─nvme0n1p3 259:3 0 117.9G 0 part
Output of lsblk -f to show UUIDs:
NAME FSTYPE LABEL UUID MOUNTPOINT
sda iso9660 ARCH_201512 2015-12-01-16-59-37-00
├─sda1 iso9660 ARCH_201512 2015-12-01-16-59-37-00 /run/archiso/bootmnt
└─sda2 vfat ARCHISO_EFI 1B66-88FC
loop0 squashfs /run/archiso/sfs/airootfs
nvme0n1
├─nvme0n1p1 ntfs System Reserved FE82239682235287
├─nvme0n1p2 ntfs 82EC269DEC268C0B
└─nvme0n1p3 ext4 111816f0-7d44-451b-af7d-9ba5c00f690f
Output of parted /dev/nvme0n1 print:
Model: Unknown (unknown)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ntfs boot
2 525MB 129GB 129GB primary ntfs
3 129GB 256GB 127GB primary ext4
Output of fdisk -lu /dev/nvme0n1
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa24a5184
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 1026047 1024000 500M 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 1026048 252903423 251877376 120.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p3 252903424 500113407 247209984 117.9G 6 FAT16
Copy of my fstab from /mnt/etc/fstab:
# /dev/nvme0n1p3
UUID=111816f0-7d44-451b-af7d-9ba5c00f690f / ext4 rw,relatime,data=ordered 0 1
# /dev/nvme0n1p1 LABEL=System\134x20Reserved
UUID=FE82239682235287 /boot ntfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
Two extracts from my grub.cfg:
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-111816f0-7d44-451b-af7d-9ba5c00f690f' {
load_video
set gfxpayload=keep
insmod gzio
insmod ntfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root FE82239682235287
else
search --no-floppy --fs-uuid --set=root FE82239682235287
fi
echo 'Loading Linux linux ...'
linux /vmlinuz-linux root=UUID=111816f0-7d44-451b-af7d-9ba5c00f690f rw quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux.img
}
### (some menuentries omited!)
menuentry 'Windows 10 (loader) (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-chain-FE82239682235287' {
insmod ntfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root FE82239682235287
else
search --no-floppy --fs-uuid --set=root FE82239682235287
fi
drivemap -s (hd0) ${root}
chainloader +1
}
This is what I did (omitting informational commands like lsblk here):
mkfs.ext4 /dev/nvme0n1p3
mount /dev/nvme0n1p3 /mnt
mkdir /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot
pacstrap -i /mnt base base-devel
genfstab -U /mnt > /mnt/etc/fstab
arch-chroot /mnt /bin/bash
# uncomment locales:
nano /etc/locale.gen
# gen locales:
locale-gen
#set locale
nano /etc/locale.conf
# added: LANG=en_AU.UTF-8
# time
tzselect
ln -s /usr/share/zoneinfo/Australia/Brisbane /etc/localtime
hwclock --systohc --utc
pacman -S grub os-prober
grub-install --recheck /dev/nvme0n1
grub-mkconfig -o /boot/grub/grub.cfg
nano /etc/hostname
# (added host name)
pacman -S iw wpa_supplicant dialog
passwd
# (set admin pwd)
exit
# (exited arch-chroot)
umount -R /mnt
reboot
Further information: when I first installed grub I received a warning about some software called Flexnet using one of the boot sectors. There are several forum and blogs discussing this issue, e.g.
http://ubuntuforums.org/showthread.php?t=1661254
I zero'd that sector, reinstalled grub and received no grub warning, but the grub error remained unchanged.
The grub error is not an incorrect UUID. As the information above shows, FE82239682235287 is the correct UUID of the first partition on that drive. So I think the obvious problem that the UUID is wrong is not the issue here.
The problem *may* be related to bios settings, though the first stage of grub on the MBR clearly loads, so it must be finding the device nvme0n1. I have been unable to determine if it could be related to the BIOS Sata Operation settings (currently "Raid On" but without any raid configuration, with options Disabled or AHCI).
I am stumped and have spent hours reading the Arch forum, the Arch wiki and doing searches of may other linux forums without finding anything to help me resolve this.
Any advice and recommendations would be most gratefully received. Thank you in advance for your assistance.
EDIT: Solution
Thanks to everyone who replied. It appears that this is a known bug with Grub (see below). Before I saw the message about the patches the solution I tried was to install Ubuntu, which worked, and then re-install Arch but without overwriting the installation of Grub that came with Ubuntu (I just created the Arch Grub configuration file /boot/grub/grub.cfg). So I was able to install and boot to Arch. I hesitate to call this a "solution" - it is more of a messy workaround. It may be that the patches indicated below would be a more graceful solution.
Last edited by Crataegus (2015-12-20 23:22:53)
Offline
Can Grub boot from NTFS now?
Offline
Thanks for your reply jasonwryan.
You may be on to something there and after searching on the basis of that idea I did find a seemingly related (but unresolved) thread:
https://bbs.archlinux.org/viewtopic.php?id=197642
My grub config file seems to contain the necessary grub modules to boot off an ntfs drive (e.g. insmod ntfs in the menuentry). But I am guessing that is only useful if the first phase of grub (the bit on the MBR) can start the second phase of grub (the bit on the first partition, which is ntfs formatted).
Perhaps it is indeed not possible for the first phase of grub to load the ntfs modules. That had never occurred to me.
So the implication of this is that I would need to convert that first partition to an ext4 format and rebuild it? (or something along those lines).
Thanks for taking the time to think about this problem. Much appreciated.
Offline
└─sda2 vfat ARCHISO_EFI 1B66-88FC
You may've followed the beginners guide too closely w/o considering which sections were meant for your config. In your original post, you said UEFI isn't enabled and some of the output you posted suggests you did create and ESP partition and most likely installed Arch and grub in UEFI mode ? If so and you are in fact using bios, will have to reinstall with the appropriate media and process. Install the appropriate version of a bootloader for your system.
Also disable fast boot in window$ leads to data corruption and problems with dualboot etc. Just 2 cents, have no idea what electing to use ntfs for /boot is about but its gnu/Linux and as such anything a person wants to do is proper, as long as they're satisfied. Also a definite starting point is going to be identifying what you're working with hardware-wise. Are you using bios-mbr ? Is windows 10 presumably installed in that mode ? 32 or 64bit ? etc.
No worries, keep at it and you'll sort it out fellow nixer.
Last edited by Archforum101 (2015-12-17 04:22:27)
Offline
Thanks very much for your reply Archforum101.
Sorry to labour the point, but I just want to clarify my mistake if I can. I downloaded the Arch installation ISO and created the bootable USB on my old laptop with:
sudo dd bs=4M if=archlinux-2015.12.01-dual.iso of=/dev/sdb && sync
where "sdb" is my USB stick. When I boot to that USB stick it becomes listed as "sda" on the new laptop. The SSD drive is nvme0n1. So sda1 and sda2 are two partitions that the above command must create on that USB stick. Your point is that because sda2 says ARCHISO_EFI it implies that I either made a mistake in downloading the wrong ISO or that I should have used a different command to create the bootable USB or that I should have changed some of the boot parameters:
https://projects.archlinux.org/archiso. … bootparams
Am I on the right track? Sorry if I am slow to catch on to exactly where I went wrong. I have gone through the Beginner's Guide again and am failing to spot my error. Any further advice or clarification would be very welcome.
Thanks for your assistance with my problem!
Offline
Oh, then my bad, thought sda was your actual drive, didn't know it was a usb-drive. Arch iso is no doubt a hybrid supporting both bios and UEFI regardless. Should've read more closely before hitting the submit button. You did mention it in your OP.
Personally have always gone with /boot simply being a part of /, rather than a separate partition. Know there are legit reasons to elect a dedicated /boot ie: Disk encryption for one. Would also definitely opt for a gnu/nix filesystem, rather than ntfs for it, if you do want a dedi /boot partition. Still going with the assumption that you're installing to a bios-mbr system.
Being as how am newbish to Arch and haven't ever elected to install it with a dedicated /boot partition. I need to shut de hell up and let better qualified nixers here advise.
Offline
No worries Archforum101. I am happy for any feedback I can get and I will now think about your idea of trying to get my third partition (the ext4 formatted one) as the boot partition. I only went with that first ntfs partition as the boot partition because it was already being used for booting. But your idea may also resolve my problem.
Thanks for taking the time to reply.
Offline
I tried Archforum101's idea of installing grub on the same partition (ext4 formatted) as Arch linux but receive effectively the same error message but in relation to a different partition now:
Welcome to GRUB!
error: no such device: 111816f0-7d44-451b-af7d-9ba5c00f690f
Entering rescue mode...
So this indicates that grub is failing to find the partition of either the ntfs or the ext4 partitions despite the fact that the UUIDs are correct. Could it perhaps be related to the fact that it is an SSD drive and/or the way that grub searches for devices?
I am beginning to think this really is more of a grub issue than an Arch issue.
Any further thoughts would be much appreciated.
Offline
Here's some thoughts OP. Your output from parted is showing your partition table is msdos, so yeppers mbr. To tell the truth fellow, would hit the easy button here and use a more gui'ey focused gnu/linux live media. ie: Linux Mint or whatever, have used a LM10 live-cd to rescue an Arch install several years ago. Something with a nice shiny gparted installed. Ya may even wanna mark your /boot partition with the boot flag, if none of the others are. Some older bios versions require this. Your system probably doesn't anyway. See this, Xaos52 is a kickbutt nixer imo. That how to has saved me many an hour ( more like dys) fixing borked gnu/Nix Os's.
Edit: Oops, am mainly refering to the info on how to chroot there. Not using that info to reinstall grub2 to mbr. Though tell the truth, it'd probably work well enough. ( See other link further down as to reinstalling grub.) There is no doubt a chroot entry in the Arch wiki and tutes but gnu/Linux is pretty much gnu/Linux and it shouldn't really matter.
Format old boot ( unless there's something on there you need etc). You can also mount partitions and explore stuff with gparted or go all commandline-commando with ""mount /dev/sdaX /mnt etc etc", whichever pleases you. Setup a new /boot with gparted. Following along with this. Would also just go ahead and reinstall grub2 to the mbr of the target drive as he's describing there. Installing grub to a partition is specifically recommended against btw.
note: While chrooted, use pacman if you need to install stuff. Edit your /etc/fstab file to reflect changes made, update grub with the approved Arch command. Lol .. you've probably already just reinstalled but meh. Wanted to post something hopefully helpful after face palming in that prior posting.
One more dang it, this thread has apparently become my mission in life. According to this fellow, it's no longer necessary to create a separate non-encrypted /boot partition to use full disk encryption ( thought things had likely changed n progressed). Which btw, occurs that if you really want or need to set up a dedicated /boot partition then researching the subject of setting up Arch with full disk encryption should point you well in the direction of how to config the system's /boot successfully.
Alright ... now I can finally go back to shutting da hell up.
Last edited by Archforum101 (2015-12-17 08:08:33)
Offline
Don't put /boot on the Windows partition -- you should only share the partition in a UEFI system.
If you want to have /boot on a separate partition (why?), create one for it and use a POSIX-compliant filesystem.
Also, the `fdisk` output is confusing as it shows the Arch partition to be "FAT16" type but `blkid` says it's ext4
Can we see the output of:
# parted -l
EDIT: You already have and it is still confusing.
perhaps too much detail?
Not at all, superb OP, well done
Last edited by Head_on_a_Stick (2015-12-17 08:15:33)
Para todos todo, para nosotros nada
Offline
You need this patch: http://git.savannah.gnu.org/cgit/grub.g … a1fde2a457 (2014-04-03 19:31:12)
While we have this in Arch: http://git.savannah.gnu.org/cgit/grub.g … 2.02-beta2 (2013-12-24 20:53:40)
I have already reproduced your issue in qemu and confirm that the patch is necessary. I tried to install grub to emulated NVMe drive, and then switch them back as IDE drive (since neither seabios and ovmf support booting from NVMe drives), without the patch only UEFI booting with a partitionless FAT-formatted drive can work, I would either get SOME_UUID not found like you on BIOS boot or `` not found on UEFI boot with a ESP. With the patch applied everything works fine.
I already filed a bug report to request the maintainer to add this patch in Arch, and also request (again) for going grub-git: https://bugs.archlinux.org/task/47447
Last edited by tom.ty89 (2015-12-19 18:32:35)
Offline
Also, the `fdisk` output is confusing as it shows the Arch partition to be "FAT16" type but `blkid` says it's ext4
Can we see the output of:
# parted -l
EDIT: You already have and it is still confusing.
There's nothing really confusing. Partition table is simply a seperate thing from filesystems, he simply selected/preserved the wrong partition type in the partition table, and formatted it as ext4. This is no big deal in Linux for most of the time, and one can easily change it back to 83 ("Linux filesystem") with fdisk.
parted is the one who has been confusing everyone, it basically conveys every concept one SHOULD NOT bare in mind in Linux. Like FUDing up filesystem/partition type, using SI unit by default, having a bunch of non-sense "tags". IIRC it doesn't even ask you to confirm properly before it writes to your disk. I STRONGLY discourage anyone to use it.
Last edited by tom.ty89 (2015-12-19 18:21:22)
Offline