Ubuntu Server 19.10 Installer immediately boots to GRUB rescue prompt.

[Surfrock66]

I am attempting to install Ubuntu Server on a Dell Poweredge R710 server. There is a single RAID-5 volume group. This is a similar hardware configuration to other servers I have successfully deployed (with older releases, all are LTS). I am booting into Legacy mode, not UEFI.

I have downloaded the latest Ubuntu Server 19.10 installer as of 12/22/2019. When installing the OS using the default options in the GUI, the install completes "successfully" but immediately boots to GRUB rescue. When going through the installer choosing to update the installer as prompted, again the system boots to GRUB rescue. All partitioning is done accepting the defaults.

If I download the most up to date Ubuntu 18.04.3 LTS installer, the system installs and boots fine. Packages update and everything is peachy. If I upgrade to the latest release using do-release-upgrade, the upgrade "completes" successfully, but then immediately boots to GRUB rescue.

I can boot into a live environment and chroot into the system and it works fine. My installs, in testing, accept all defaults especially in terms of those related to partitioning.

I am not very experienced working in GRUB, so everything after this comes from these guides:
https://askubuntu.com/questions/232215/stuck-in-grub-rescue-mode
https://www.howtoforge.com/tutorial/repair-linux-boot-with-grub-rescue/
https://help.ubuntu.com/community/Grub2/Troubleshooting

When I ls, I get the following:
(hd0) (hd0,gpt2) (hd0,gpt1)

If I do "ls (hd0,gpt2)/" I get the contents of my root file system. Inside here, /boot and /boot/grub appear fully populated.

If I do "ls (hd0,gpt1)/" I get "Error, unknown file system".

When I do "set" I see the following relevant entries:
prefix=(hd0,gpt2)/boot/grub
root=hd0,gpt2

These appear to be correct. If I do the following, I can get the system to boot to initramfs prompt but not the actual system:

insmod normal
normal
insmod linux
linux /vmlinuz root=/dev/sda1 ro
initrd /initrd.img
boot

I have verified that the vmlinuz and initrd.img are there.

At this point as far as I can tell, something in the default configuration of Ubuntu Server 19.10 renders the OS un-bootable through GRUB.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1857789/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Surfrock66 (surfrock66)]

Apologies but I cannot find a way to identify the Ubuntu Server installer by package name; I believe there is a partitioning issue in the installer.

[Surfrock66 (surfrock66)]

I believe the partitions are being created in the wrong order. By manually partitioning, I have been able to get a bootable system with the following created in lsblk:

sda 8:0 0 3.7T 0 disk
├─sda1 8:1 0 1M 0 part
└─sda2 8:2 0 3.7T 0 part /

When I was in a chroot environment on the non-booting default partition scheme, the 1M partition was at the end of the drive as sda2. I believe the installer is partitioning the drive incorrectly when accepting the defaults.

[Paul White (paulw2u)]

Surfrock66, re your comment #2.
Which ISO did you use to install Ubuntu Server?
If the 'live' server image then the project is 'Subiquity' not 'Ubuntu'
otherwise the package is 'debian-installer'.
Please advise or update the report so that your issue can be directed
towards those that can investigate.

[Surfrock66 (surfrock66)]

Thank you, I will mark it.

[Michael Hudson-Doyle (mwhudson)]

Hi, this sounds strange and fairly serious. The install media you used should have logs copied to it -- they'll be on the filesystem with label casper-rw. Can you tar up and attach the logs for the install that failed to boot?

[Michael Hudson-Doyle (mwhudson)]

If you could also try a focal daily, that would be great.

[Surfrock66 (surfrock66)]

The problem is, once I got it fixed I proceeded with the server as I needed to get it into production. I don't have any similar hardware to re-create this on. I'll check the media tonight, but the last install I ran was fixed using manual partitioning.

[Michael Hudson-Doyle (mwhudson)]

Yes I wondered if that might be your response. Hopefully the next person who runs into this will not actually need to use the server immediately :)