You are not logged in.
I am installing Devuan to a 256GB NVMe drive on a server w/ 256GB of RAM. I often opt to go with the guided install as it makes an encrypted root system easy. However, I was greeted with an error about not being able to use the guided install as the install disk isn't large enough - due to the system choosing the same size swap as amount of RAM in the server, naturally. And, naturally at least as far as I can tell, there is no way to change the size of that swap partition prior to the guided install attempt.
Now, I am still here in the datacenter trying to do a manual install, trying different things, as it's choking during grub installation.
After manually creating my partition which was confusing and not very intuitive - at least in the respect of setting up LVMs for the encrypted filesystem - I got the system to install. At grub installation it fails with a message in the log regarding (paraphrasing, as I've rebooted now and trying other things ) "installing for an encrypted system but blah blah.. make sure GRUB_ENABLE_CRYPTODISK=y is in the /etc/default/grub config". I tried putting that in /target/etc/default/grub to no avail. Also of note is that I cannot boot off of my PCI-e NVMes with this server and a BIOS upgrade - which also failed earlier leaving me to have to do a BIOS image recovery - did not give the option, so as a result I opt to install grub to a USB thumb drive. However, because of these grub errors, I cannot install the system.
Is the installer not creating the proper configuration for grub when using disk encryption because of something not done during setup? I am creating a physical /boot partition, the 'use for encrypted volume' option on a logical partition, then to Configure encrypted filesystems and create them, THEN to Create Logical Volumes and I create a volume group and a LVM with the 200GB partition in it, and then again in the partition manager assign that as ext4 mounted at '/' as the root. Again the system does install just fine to the disk its that grub for whatever reason is not aware and doesn't do whatever it needs to for the crypto setup?
.. so this is why I normally opt to have it done for me fully guided. So, is there any way to change the amount of swap space that is going to be created PRIOR to the partitioning, disable it, anything? Hard choking without enough disk space because the swap is so darn large is silly and should be put in the trash can along with other kludge like systemd. ;D
Thanks,
data
Last edited by dataslanger (2019-08-25 06:16:15)
Offline
It's possible this is not due to the partitioning, but that you've got a sightly buggy consolekit package installed, which makes directories in /usr/share/locale/ with names ending in .gmo, and that this upsets grub-install. One way to work around that would be to remove those directories, and then redo grub-install. Doing so makes consolekit lose its internationalization, but all else would be fine.
Offline
I'm a bit confused- I am using whatever came with the distro, and am doing this during initial installation. The error messages were very particular about the crypto related things but I will give that a try .. are we talking about the same thing? After all the installation should have packages supporting it that get it installed properly correct? Or am I missing something?
UPDATE:
Haven't gotten back to trying on D1 as I wanted to try it on Debian - I tried the exact same thing in Debian 10 and, besides grub giving me trouble for not having a valid filesystem and then having a GPT partition table instead of DOS (and failing / refusing for "safety checks" until I fixed that), it installed grub on my manually made encrypted partition scheme. I did the exact same sequence in Devuan but with the result being the failure.
Thanks
D.S.
Last edited by dataslanger (2019-08-25 09:16:27)
Offline
I was greeted with an error about not being able to use the guided install as the install disk isn't large enough - due to the system choosing the same size swap as amount of RAM in the server, naturally. And, naturally at least as far as I can tell, there is no way to change the size of that swap partition prior to the guided install attempt.
Preseeding the installer with the desired partition sizes might be an option: https://wiki.debian.org/DebianInstaller/Preseed
But I would just boot the installer with a mem=8g kernel command line parameter so that it only creates an 8GiB swap partition (mutatis mutandis).
Brianna Ghey — Rest In Power
Offline
Yes, my note regarding consolekit might not be relevant; it does depend on which distro you are talking about. It came up for me when building and testing the beowulf netinstall iso, and I've also seen it popping up elsewhere. It's merely one possible reason for failing grub-install that is easy to check for and rule in/out.
Offline
If /boot is on its own unencrypted partition, you don't need the cryptodisk line in /etc/default/grub. You only need that if /boot is part of the encrypted volume. Make sure to run 'update-grub' in the chrooted target after you add the line.
If you're using gpt with legacy/bios boot, grub needs a special partition, at least 1MB size, unformatted and type ef02 in gdisk or bios_grub in gparted.
Offline
If you're using gpt with legacy/bios boot, grub needs a special partition, at least 1MB size, unformatted and type ef02 in gdisk or bios_grub in gparted.
The OP has an NVMe drive which is almost certainly an advanced format (4k) type — such devices cannot be booted by GRUB in non-UEFI mode even if a BIOS boot partition is present.
Brianna Ghey — Rest In Power
Offline
On systems where booting from NVMe disk isn't possible, for whatever reason, I'd suggest using the NVMe disk as a cache instead. The system is installed on a 'standard' SSD while the NVMe disk is configured as cache for this SSD. Use the bcache tool from the repo's. And here's the manual: click!
This setup allows the sys-admin to choose any boot configuration and still have the benefits of fast access from the NVMe disk.
HTH!
Online
Indeed NVMe wouldn't work especially on this computer as the (upgraded!) BIOS doesn't support it. This wasn't related to the NVMe though as I tried w/o it, the NVMe indeed won't boot even if I used grub MBR on a USB stick w/ reference to the NVMe. During install it just wouldn't write if I did a manual partition setup. If I did automatic, it installed fully, but then failed when I had crypto enabled. Whether or not grub cares about the line in the config , given its on an unencrypted /boot, didn't seem to matter on Devuan *only* because it failed regardless. Debian 10 and an older Ubuntu did fine when I went to manual configuration and did the exact same steps. So there's something changed I suppose in the install process causing this.
I am thinking about removing all but 8GB of the RAM (a single stick) from the mobo but its 4x 16-core Opterons over 4 nodes, and 2 of the nodes and their memory are hidden under the top board. It would seem like a good option to provide a way to adjust the size of the swap partition prior to the auto setup, but there's definitely a bug afoot in that Ubuntu, Debian, etc. installs grub without incident when i specify manual mode w/ encryption and not automatic yet Devuan does not.
I was hoping maybe there was an argument I could set to the install process in some way that would allow me to disable or adjust the swap sizing instead of defaulting to whatever the system RAM size is.
Thanks
D.S.
Offline
But there is! If you install Devuan manually on a previously partitioned disk, it'll respect the partition sizes allocated to the various mount-points. This includes SWAP. Admittedly it's an extra step but the sysrescuecd guys offer a nice graphical way to partition and format your system with gparted from the GUI desktop. I don't use encryption (no need as I'm the sole user of my Devuan systems) so can't tell you anything on that.
Online
OP: Suggest you boot from a secondary and resize the swap partition first. Beware of its UUID changing, there's a way to set it back but you know that. Assuming you care what it's UUID is. Also suggest you pitch grub into the trash (regardless) and take a look at syslinux. It appears that it's still in the distro. Better than grub in every way, back while i was using it, but it was restricted to a single partition because nobody wrote the filesystem code for that. I'm seeing an EFI file is now associated with the syslinux package. Whatever, i wish you luck, when linux runs out of resources it's a real pain, and apparently there's no proactivity-factor to increase resource-lookahead from basically none-whatsoever to something that screams its head off before you run into the no-resources-wall and feel the Catch-22. IF all this isn't entirely irrelevant and meaningless lol.
Offline