You are not logged in.
Pages: 1
Hi everyone,
First time poster here. Just wanted to start off by saying that I really appreciate the great work of everyone involved in this project. This is an awesome distro!
I've been using it for some time and now I wanted to try out a new setup, but I seem to be stuck.
I'm trying to set up a BIOS/MBR installation with an encrypted root and /home on a single partition (/dev/sda2), and a separate non-encrypted /boot on another partition (/dev/sda1). I'm using the "devuan_beowulf_3.0.0_amd64_desktop-live.iso" image (haven't tested any of this in Ascii). During the installation process, when prompted to install GRUB, I choose the "Copy files" option and select "/dev/sda" as the location (even if I select both "/dev/sda" and "/dev/dm-0", the result is the same). This results in an error:
Error detected: 2
See /var/log/refractainstaller.log for details.
This may not be fatal.. Press "Continue" to proceed anyway
The part of the log which refers to this is as follows:
+ [[ grub-pc*.deb =~ grub-pc ]]
+ grubversion=grub-pc
+ [[ grub-pc*.deb =~ grub-efi ]]
+ install_grub
+ echo 'Setting up grub bootloader.. Please wait..'
+ [[ -n /dev/sda1 ]]
+ chroot /target mount /dev/sda1 /boot
+ [[ -n '' ]]
+ [[ '' = \e\f\i ]]
+ [[ -n '' ]]
+ chroot /target update-grub
/usr/sbin/grub-mkconfig: 253: /usr/sbin/grub-mkconfig: cannot create /boot/grub/grub.cfg.new: Directory nonexistent
+ check_exit
+ exit_code=2
After finishing the installation and rebooting, the system drops to GRUB rescue mode:
error: no such device: 05eb424f-c4f8-4a5e-88d4-7a95764f7e58
error: unknown filesystem.
Entering rescue mode...
grub rescue>
This is the fstab:
/dev/mapper/root_fs / ext4 defaults,noatime 0 1
UUID=37a1d9e9-2597-4fc7-ad7f-95def918c030 /boot ext4 defaults,noatime, 0 2
/swapfile none swap sw 0 0
This is the crypttab:
# <target name> <source device> <key file> <options>
root_fs UUID=b23b7722-8c39-47f1-a49b-cd6cc7ac4eae none luks
And this is the output of blkid:
/dev/sda1: UUID="37a1d9e9-2597-4fc7-ad7f-95def918c030" TYPE="ext4" PARTUUID="df76ca67-01"
/dev/sda2: UUID="b23b7722-8c39-47f1-a49b-cd6cc7ac4eae" TYPE="crypto_LUKS" PARTUUID="df76ca67-02"
/dev/mapper/crypt: UUID="05eb424f-c4f8-4a5e-88d4-7a95764f7e58" TYPE="ext4"
I've tried multiple solutions found on the web, but I didn't get anywhere. I've done another reinstall, so in case anyone has any suggestions, we're on a clean slate.
Interestingly enough, if I perform a UEFI/GPT installation with the exact same settings (apart from an additional partition for EFI), GRUB is installed without errors and everything works as expected. Just to make sure it wasn't a BIOS settings issue, I've performed identical installations in VirtualBox, but the result is the same - UEFI works, BIOS doesn't. The reason why I insist on BIOS is because the machine that I'm planning to install this kind of a setup on doesn't have UEFI.
Before any of this, I've tried the full disk encryption (FDE) setup, /boot included, and, ironically, both BIOS and UEFI work as expected, but I had to give up on it, as typing the same password twice at every boot would be a real PITA for the end user.
Apologies for the wall of text. Any help is greatly appreciated! :)
Offline
The fact that it works with a uefi install but not with a bios install makes me think you might be using gpt partition table on the disk. If so, you need a separate, special partition for grub:
At least 1MB in size, unformatted (the last fs type option in gparted) and with flag bios_grub in gparted or type ef02 if you're using gdisk.
fdisk -l will tell you if the disk is gpt or msdos partition table.
If that is not the issue, boot the live system and mount each partition to see that it actually has the files it needs. (e.g. /boot/grub/grub.cfg and everything else that should be in /boot)
Offline
No, the partition table is msdos:
Disklabel type: dos
root seems to be fine:
total 262413
drwxr-xr-x 2 root root 4096 May 30 17:28 bin
drwxr-xr-x 3 root root 1024 Nov 18 15:41 boot
drwxr-xr-x 15 root root 3380 Nov 18 23:22 dev
drwxrwxr-x 132 root root 12288 Nov 18 15:43 etc
drwxrwxr-x 2 root root 4096 Feb 11 2019 firmware
-rw-r--r-- 1 root root 39768 Jun 25 2019 grub-efi-ia32_2.02+dfsg1-20_amd64.deb
-rw-r--r-- 1 root root 130960 Jun 25 2019 grub-pc_2.02+dfsg1-20_amd64.deb
drwxrwxr-x 3 root root 4096 Nov 18 15:43 home
lrwxrwxrwx 1 root root 30 May 30 17:36 initrd.img -> boot/initrd.img-4.19.0-9-amd64
drwxr-xr-x 20 root root 4096 May 30 17:36 lib
drwxr-xr-x 2 root root 4096 May 30 16:31 lib64
drwx------ 2 root root 16384 Nov 18 15:38 lost+found
drwxr-xr-x 2 root root 4096 May 30 16:30 media
drwxr-xr-x 2 root root 4096 May 30 16:30 mnt
drwxr-xr-x 2 root root 4096 May 30 16:30 opt
dr-xr-xr-x 153 root root 0 Nov 18 23:21 proc
drwxr-xr-x 4 root root 4096 Nov 18 17:57 root
drwxr-xr-x 5 root root 4096 Nov 18 15:41 run
drwxr-xr-x 2 root root 12288 May 30 17:25 sbin
drwxr-xr-x 2 root root 4096 May 30 16:30 srv
-rw------- 1 root root 268435456 Nov 18 15:40 swapfile
dr-xr-xr-x 13 root root 0 Nov 18 23:21 sys
drwxr-xr-x 2 root root 4096 Nov 18 15:37 target_boot
drwxrwxrwt 2 root root 4096 Nov 18 15:41 tmp
drwxr-xr-x 10 root root 4096 May 15 2020 usr
drwxr-xr-x 11 root root 4096 May 30 16:30 var
lrwxrwxrwx 1 root root 27 May 30 17:36 vmlinuz -> boot/vmlinuz-4.19.0-9-amd64
...but /boot definitely isn't:
total 49530
-rw-r--r-- 1 root root 206157 Apr 29 2020 config-4.19.0-9-amd64
-rw-r--r-- 1 root root 41807144 Nov 18 15:41 initrd.img-4.19.0-9-amd64
drwx------ 2 root root 12288 Nov 18 15:37 lost+found
-rw-r--r-- 1 root root 3411358 Apr 29 2020 System.map-4.19.0-9-amd64
-rw-r--r-- 1 root root 5278960 Apr 29 2020 vmlinuz-4.19.0-9-amd64
In regards to /var/log/refractainstaller.log - would manually creating the /boot/grub/ directory (before trying to install GRUB during the installation process) help?
Or is there another way of fixing this?
Thanks
Offline
There are a few ways to fix this, and you should not have to make /boot/grub/ manually. I would be interested to see the whole installer log. You could send it to me at gmail or email through the forum.
Method 1. Boot the live media, chroot the installed system and install grub-pc. Make sure it runs update-grub and creates grub.cfg.
I left a bunch of steps out. Let me know if you want them. This is what I tend to do when grub screws up.
Method 2. Boot the live media and as root run apt update and apt install grub-pc. You need at least 2G of RAM to do this.
When it asks you where to put the bootloader, do not install the bootloader at this time.
Then install the system again the way you want. Instead of seeing the Copy Files button, there will be a button that says Install Bootloader. Choose that one and tell it where to put grub. (MBR of /dev/sda)
Offline
Ok, so I've tried both methods in separate VMs.
Method 1 - I've done as follows (not sure if correct):
cryptsetup luksOpen /dev/sda2 root
mount /dev/mapper/root /mnt
mount /dev/sda1 /mnt/boot
mount --bind /dev/ /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
apt install grub-pc
...which resulted in:
grub-pc is already the newest version
Then I did:
apt update
apt install grub-pc
update-grub
The only two files that appeared after that were "grub.cfg" and "unicode.pf2" in /boot/grub. Then:
exit
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev
umount /mnt/boot
umount /mnt
reboot
And I got the exact same result:
error: no such device: 05eb424f-c4f8-4a5e-88d4-7a95764f7e58
error: unknown filesystem.
Entering rescue mode...
grub rescue>
Method 2:
apt update
apt install grub-pc
Skipped installing the bootloader, but again I got "Copy Files", not "Install Bootloader", during installation.
Chose "Copy Files", which installed GRUB without asking me where I want to install it, though without errors. Rebooted, and it actually works :)
The only thing is, before seeing GRUB, I see this for a few seconds every time:
error: no such device: [UUID]
error: file `/usr/share/desktop-base/grub-themes/cinnabar-grub/unifont-regular-16.pf2' not found.
error: file `/usr/share/desktop-base/grub-themes/cinnabar-grub/theme.txt' not found.Press any key to continue...
The UUID above refers to /dev/mapper/root. I get that if I disabled GRUB theming, this wouldn't be an issue, but I don't know how to do that.
I've also sent you an email with the installer log.
Thanks
Offline
You did the chroot correctly.
The error message about grub-pc already being the newest version makes no sense. (Unless it said grub-pc-bin) because grub-pc is not installed in the amd64 desktop-live iso.
I thought maybe the boot partition didn't get mounted correctly, but the log shows that it did. I don't know what happened, and I also can't explain the errors you got in your subsequent attempts.
The theme issue is easy to fix. Comment out this line in /etc/default/grub:
GRUB_THEME=/usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
And then run update-grub.
There is a way to copy the theme into /boot/grub and get it to work with an encrypted root, but I don't remember if you need to do more than copy the theme directory and fix the path for GRUB_THEME in /etc/default/grub.
I know why you didn't get asked where to put the bootloader. That was a change in grub and a later version of refractainstaller corrects for that.
Offline
The error message about grub-pc already being the newest version makes no sense. (Unless it said grub-pc-bin) because grub-pc is not installed in the amd64 desktop-live iso.
As in, it shouldn't be there in the installed system? The deb package is included in the ISO, though. The second step during installation states:
### WARNING ###
grub-pc is not installed but you booted in bios mode.If you have the grub-pc deb packages, you will be given a chance to install them into the new system.
grub package(s) found in /grub-pc_2.02+dfsg1-20_amd64.deb
Comment out this line in /etc/default/grub:
I could've guessed that it was there. Sorry, should've taken a look before asking.
I haven't tried copying the theme folder, but it doesn't bother me, as I usually disable the GRUB timeout anyway.
I know why you didn't get asked where to put the bootloader. That was a change in grub and a later version of refractainstaller corrects for that.
Oh, good to know. Looking forward to Chimaera, then :D
At least the second method works. It's an extra step during installation, but easy enough. Thanks!
Last edited by user1120 (2020-11-20 22:45:48)
Offline
Wrong uuid before it fails and drops to the grub rescue prompt. That is the uuid of your /dev/mapper partition. Grub should be looking for the uuid of sda1. It can't find vmlinuz & initrd.img. They are now on sda1.
/dev/sda1: UUID="37a1d9e9-2597-4fc7-ad7f-95def918c030" TYPE="ext4" PARTUUID="df76ca67-01" <-- this guy
Check your grub.cfg. You should find a bunch of:
--set=root 05eb424f-c4f8-4a5e-88d4-7a95764f7e58
That should be reading:
--set=root 37a1d9e9-2597-4fc7-ad7f-95def918c030
You get the grub rescue prompt because grub can't find the 2 needed boot files. If it fails because of bad crypttab or lvm mistakes in the initramfs image file, it will drop to an (initramfs) shell instead of a grub rescue prompt.
(search & replace is ur friend)
Once you boot into the OS, crypttab needs to have the uuid for sda2, like:
crypt UUID=b23b7722-8c39-47f1-a49b-cd6cc7ac4eae none luks,discard
and fstab needs to have the entry for sda1 and the /dev/mapper entry for the luks device.
# /boot was on /dev/sda1 during installation
UUID=37a1d9e9-2597-4fc7-ad7f-95def918c030 /boot ext4 defaults 0 2
/dev/mapper/crypt / ext4 errors=remount-ro 0 1
(yep, that's a space after the uuid and the word 'crypt')
Then have it pump you out a new initrd.img with mkinitramfs
Last edited by Jafa (2020-12-07 05:45:35)
Offline
Hey, thanks for the input :)
I've tried replacing "05eb424f-c4f8-4a5e-88d4-7a95764f7e58" with "37a1d9e9-2597-4fc7-ad7f-95def918c030" in grub.cfg, but it's as if no changes were made:
error: no such device: 05eb424f-c4f8-4a5e-88d4-7a95764f7e58
error: unknown filesystem.
Entering rescue mode...
grub rescue>
I'm assuming an "update-grub" is required, but that reverts the changes in grub.cfg.
I still haven't booted into the OS, but I've entered chroot again and modified crypttab and fstab as you said, but I can't figure out the "mkinitramfs" part...
Offline
Instead of mkinitramfs, you can use update-initramfs -u in the chroot. It will rebuild the initrd.img for the running kernel. If you want to build for a different kernel, use update-initramfs -u -k <kernel-version> or update-initramfs -u -k all
Offline
Running either "update-initramfs -u" or "update-initramfs -u -k all" results in:
I: update-initramfs is disabled (live system is running without media mount on /lib/live/mount/medium).
I tried doing "apt-get install --reinstall linux-image-${kernel_ver}-generic linux-signed-image-${kernel_ver}-generic" and also managed to do "mkinitramfs -o /boot/initrd.img-${kernel_ver}-generic ${kernel_ver}-generic" without any errors, but I get the exact same grub rescue prompt when trying to boot, with the wrong UUID (and I've checked grub.cfg before rebooting).
Offline
I: update-initramfs is disabled (live system is running without media mount on /lib/live/mount/medium).
You can either remove the live-tools package or use the modified name for the command.
update-initramfs.orig.initramfs-tools -u -k all
Offline
Ok, so I did:
update-initramfs.orig.initramfs-tools -u -k all
...which returned no errors, then rechecked grub.cfg (as per Jafa's post), rebooted, but I still get the same result.
This is the current fstab:
/dev/mapper/crypt / ext4 errors=remount-ro 0 1
UUID=37a1d9e9-2597-4fc7-ad7f-95def918c030 /boot ext4 defaults,noatime, 0 2
/swapfile none swap sw 0 0
...and the current crypttab:
# <target name> <source device> <key file> <options>
crypt UUID=b23b7722-8c39-47f1-a49b-cd6cc7ac4eae none luks,discard
Offline
I just noticed that the command, grub-install, does not appear anywhere in this thread. You might need to run that or 'dpkg-reconfigure grub' before you run update-grub. It used to ask where to put the bootloader when you installed the deb package, but it no longer asks.
Offline
It used to ask where to put the bootloader when you installed the deb package, but it no longer asks.
The non-UEFI version (grub-pc) still asks for a target drive but the UEFI version does not because the question is meaningless for a UEFI system.
Brianna Ghey — Rest In Power
Offline
fsmithred wrote:It used to ask where to put the bootloader when you installed the deb package, but it no longer asks.
The non-UEFI version (grub-pc) still asks for a target drive but the UEFI version does not because the question is meaningless for a UEFI system.
Yes, that's what I remember, and it stopped doing that for me earlier this year. I modified refractainstaller to account for that. The modification involved uncommenting one line which I had commented out in the past because the user was being asked twice where to put the bootloader. Today, it's asking me again.
The problem with the 3.0.0 iso is that the boot partition isn't getting mounted correctly for grub-install. I was able to get it to work by manually mounting it right before installing the grub-pc package. But that does not explain why the attempts to fix it in chroot didn't work for OP. Everything was mounted correctly there. I'd have to go back and read everything again to be sure, but maybe there was a problem with mis-match of grub packages between the iso and the repo.
I just did a successful install with a preliminary 3.1.0 iso I made for testing before actual point-release. It works. I do get asked twice where to put the bootloader. I also get a warning before the boot menu, because it can't find the theme. Press any key to continue, and it works.
Here's the link for the test iso.
https://get.refracta.org/files/experime … p-live.iso
sha256sum: bf477a3c0dc27866509407fde670d8fa0b903296effef7f67c2222a48fd9eb2a
Offline
Finally moved from the grub rescue prompt :)
I've done:
grub-install /dev/sda
update-grub
...then fixed the UUID in grub.cfg and rebooted. I got the theme warning, then the boot menu, entered the disk password, and then:
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /run on /root/run failed: No such file or directory
run-init: can't execute '/sbin/init': No such file or directory
Target filesystem doesn't have requested /sbin/init.
run-init: can't execute '/sbin/init': No such file or directory
run-init: can't execute '/etc/init': No such file or directory
run-init: can't execute '/bin/init': No such file or directory
run-init: can't execute '/bin/sh': No such file or directory
run-init: can't execute '': No such file or directory
No init found. Try passing init= bootarg.
BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs)
I've tried going back and doing "update-initramfs.orig.initramfs-tools -u -k all" again, but it's the same. The crypttab and fstab configs are unchanged.
I'll check out the test ISO when I get the time, thanks for the link :)
Offline
I want to apologize for my earlier post. I finally realized I hadn't done an install from the LiveCD iso, just from the netinstall iso.
So I tried doing a plain install using the LiveCD iso with no crypto, just '/boot' on sda1, and '/' on sda2. I worked with that for a couple of hours. No matter what I tried, it always put '/boot' on sda2 and I only got the grub rescue prompt.
I'm guessing the install script is broken somewhere after partitioning. OTOH, the netinstall iso installer works flawlessly.
Offline
No worries. Good to know that the netinstall ISO works in this case, thanks.
Last edited by user1120 (2020-12-16 00:44:48)
Offline
The problem is with the installer. If you don't want to download a new iso, you could just upgrade the installer. The new version is currently in beowulf-proposed-updates and will be moved to the main beowulf repository very soon. You could install it from there in the live session and then do the installation.
If you don't want to mess around with editing sources.list, you could download the packages directly and install them with dpkg or gdebi. These are the same packages that are in the repo, but the links are a little shorter and easier to type.
https://sourceforge.net/projects/refrac … .6_all.deb
https://sourceforge.net/projects/refrac … .6_all.deb
Offline
The new version is currently in beowulf-proposed-updates and will be moved to the main beowulf repository very soon. You could install it from there in the live session and then do the installation.
That's awesome, thanks so much!
Last edited by user1120 (2020-12-16 00:45:27)
Offline
Pages: 1