Score:6

Ubuntu Server 20.04.3 LTS won't boot after installation

cn flag

I have a small desktop that I am trying to set-up as a web server and I can't get the system to boot after I install Ubuntu Server 20.04.3 LTS. When I do try to boot it up, there are no messages of any kind and all I get is a single blinking cursor in the top-left corner of the screen; nothing else happens no matter how long I leave the system like that.

I've tried several different installation options (LVM w/soft RAID, no LVM & single volume, etc), and different physical hard drives, but the results are the same. I tried Ubuntu Server 18.04.5 and got exactly the same results. I went way back and tried a copy of Ubuntu Server 10.04 and that was able to boot OK (I don't have anything between 10.04 & 18.04). At no point were any errors reported during installation.

I had been using Linux Mint 18.3 just fine before (that's what was previously on that system) and never experienced any problems booting. The last thing I tried was Ubuntu Desktop 20.04.3, and that WAS able to install itself and it boots just fine even though I technically don't have as much RAM as they say I should have (4GB required when I only have 2GB).

I checked the ISO for Ubuntu Server 20.04.3 LTS and the hash is correct (there was a mismatch between the Ubuntu Server 18.04.5 ISO and the SHA256 hash on their website, but that's another matter), and each version passed their integrity checks. I can't find any mention of PPT or UEFI or Legacy Boot in the BIOS as was suggested in some other posts.

The basic system specs are:

  • Intel DG965RY ATX Motherboard
  • Intel Core 2 Duo 6600 SL958 CPU
  • 2GB DDR2 RAM
  • WD 80 GB Hard Drive

Any help would be appreciated.


UPDATE 1:

I noticed that the Ubuntu 20.04.3 Desktop installation (an installation that actually boots & works) has separate partitions for /boot (formatted as vfat), / (formatted as ext4), and Swap. I tried to manually create the same kind of partitions using gParted, and I can then select those partitions for /boot, /, and Swap, but no matter what I do, the Server installation program refuses to let me select a working boot disk to be the new boot disk if I select my existing partitions.

UPDATE 2:

After hunting through the installation options, I found where I could tell the install program to create separate partitions for /boot, /, and Swap (they certainly didn't make it easy to find!) and I re-installed it again (for about the 20th time). Again, no joy.

So I thought maybe something might be wrong with Grub, so I re-installed that using a live CD Ubuntu Desktop. Once again, no joy.

UPDATE 3:

Having no luck finding anything that worked with Ubuntu, I decided to try Debian to see if their installer had any more options w.r.t. configuring the destination drive. Using selections similar to the ones I chose when installing the different versions of Ubuntu, I installed Debian, but the results were the same -- a single blinking cursor at the top-left corner of the screen.

In responding to one of the comments below, I started to think about what else (besides the grub bootloader) could explain the difference between the installations of Ubuntu Desktop and Ubuntu Server. I think the hardware is vintage 2007(?), so I thought maybe UEFI might be a factor -- i.e., the hardware might not be compatible w/UEFI but the Server installer is defaulting to that and Desktop wasn't? I saw a reference to using an Ubuntu "mini ISO" that downloads everything on-the-fly and the size of the ISO didn't include provisions for UEFI, so it defaults to a BIOS/Legacy boot configuration. I tried that, but again, the results were no different than the standard Server installations before.

During the night, I started to think about the filesystem being used for the /boot partition. The only installation that successfully booted, Ubuntu Desktop, uses VFAT for the boot partition. I checked, and Ubuntu Server doesn't allow selecting FAT, VFAT, or FAT32 formats for the /boot partition, so that was a dead end. In trying Debian, I saw it had many more options when it came to formatting the disk, so I tried their installer again. However, attempts to choose either FAT or FAT32 triggers an error message saying something to the effect that "the FAT (or FAT32) format is not fully UNIX-compatible and can't be used for /boot" and suggested I use Ext2 instead. So I tried that, but it produced the same results as before. No joy.

I'm still convinced that the problem lies in the differences in how Ubuntu Desktop and Ubuntu Server are setting up the drive (grub, /boot, the filesystem on the boot partition, etc.). I'm just out of ideas of what else to check, how to fix the installation, or how the choose the right options during the installation to make Ubuntu Server work.

UPDATE 4:

As I mentioned in the comments below, I copied the files off the /boot partition, reformatted it as FAT32 (reported as VFAT by multiple tools as mentioned in my previous posts), copied the /boot files back, chroot'd from a live Ubuntu Desktop to the hard drive installation, updated and reinstalled grub, then tried to reboot. I don't know if I did it all correct (I think I did), but it made no difference. The result was the same as all of my previous attempts -- a single blinking cursor and nothing else.

After dealing with another issue, I reinstalled Ubuntu Desktop 20.04.3 (using all of its defaults) on a completely wiped drive, and the configuration was slightly different from previous installations (a separate partition for /boot/efi only, rather than /boot), but it still created a small FAT32 partition for the boot files. I then thought that completely wiping the disk may have changed something, so I wiped it again and tried reinstalling Ubuntu Server, but I was back at square one again.

Alejandro suggested (in the comments below) that I should try to install Ubuntu Seerver on another computer to verify the disk is ok. It's a good idea, but I would have to take apart a complete working system to do that, and that would not be feasible right now.

I still believe that my theory about the system not being able to understand EXT2/EXT4 filesystems is still the leading contender to explain my problem, but I still don't have a way to install Ubuntu Server with a FAT32 /boot partition to prove or disprove it. If someone can provide a way to do that, I'll try it. Otherwise, I don't think I'll pursue this any further.

Nmath avatar
ng flag
Did you remove all traces of Linux Mint? For example, did you format (erase) the hard drive prior to installation? Are you certain that your installation media is valid? Does it pass integrity checks?
Big_Al_Tx avatar
cn flag
@Nmath - It's a different hard drive than the one I used for Mint and every time I installed anything, I did a complete wipe and repartition of the drive, so nothing else was on there except the new OS.
David avatar
cn flag
With under powered hardware why would you not expect problems. Add ram.
Big_Al_Tx avatar
cn flag
@David - Since the system does boot just fine with other distros (namely Mint 18.3 & Ubuntu Desktop 20.04) that require even ***more*** resources than Ubuntu Server, memory is ***not*** the problem. And according to their website, Ubuntu Desktop is based on the same codebase as Ubuntu Server, it's just packaged with X and a whole lot of GUI utilities and applications. So, since Ubuntu Desktop ***does*** boot and Server doesn't, the difference must have something to do with how Ubuntu Server is installed.
sudodus avatar
jp flag
Would you like to try a tool, that is in the process of development how? It is a tool to help users like you upload [sanitized] detailed information about the computer to helpers like me. I have a version, that works fairly well in the operating systems where I have tested it (including Ubuntu Server 20.04.3 LTS). You can download the script from a [link to the Ubuntu pastebin in this link to the Ubuntu Forums](https://ubuntuforums.org/showthread.php?t=2465764&page=10&p=14057478#post14057478) and write a comment to me with **link to your uploaded report file** at https://paste.ubuntu.com.
sudodus avatar
jp flag
A quick tip for you is to re-format the drive (remove all file systems, only have either the classic MSDOS or the newer GUID partition table, but no partitions. Then let the installer do its thing (select the default settings where possible, do not try any advanced or custom partitions). It should work. - If it still does not work I think the problem is somewhere else, for example the graphics chip/card or the network chip/card. You may need the boot option 'nomodeset'. You may need a wired connection to the internet.
Big_Al_Tx avatar
cn flag
@sudodus - I started out letting the installers use all of the defaults, and that's where I first started having trouble with Ubuntu Server. It was when I installed Ubuntu Desktop (also using it's default settings) and it booted-up fine after installation that I realized that I would have to deviate from the defaults used by Ubuntu Server. Since the Desktop installation works fine for graphics and networking, I doubt those are involved. Besides, Server is character-based and there is no GUI. I'll try the script a little later today and let you know what it reveals.
Nate T avatar
it flag
Tl;dr: The issue is your machine, not the OS. Windows doesnt like you leaving, and they dont mind playing dirty.What OS did it have on it prior to this? If the answer is windows 10, you may have bit locker enabled, which if you deleted windows 10 with bit locker enabled (IE your hard drive is machine eccrypted and Windows had the key, ) then your hard drive may be a hunk of metal now and nothing more. If this is the case, blame Windows, not us. Imo, BitLocker is ransom-ware, nothing more, nothing less.
Big_Al_Tx avatar
cn flag
@NateT - In this instance, that's not the case, I never had Windows 10 on it and I avoid BitLocker like the plague. I know the drive isn't bricked since I did have a running instance Ubuntu Desktop on that drive (& another one too). I do think you're right about the hardware being at fault. I don't think it can understand EXT2/EXT4 filesystems. I just confirmed the Mint 18.3 that I used to have on that machine (& it worked) used VFAT for the /boot partition, just like the instance of Ubuntu Desktop that worked. Next, I'll try cloning the /boot partition, reformat as VFAT, then clone it back.
Nate T avatar
it flag
I would try to pull a 4g ram card from another device, if you can find one, (i am guessing ddr3?) and see if it boots with that. Just so you can eliminate it as the issue. Ext2 is an old system. Unless your device is a Commodore or an atari, I would think it would work with the fs. XD
pa4080 avatar
cn flag
Hi, maybe some BIOS settings must be changed. Does there secure boot option enabled in your BIOS settings? Also does ACHI access mode is selected for the hard drives?
Alejandro avatar
jp flag
Could you try to install Ubuntu Server 20.04.3 on a different computer, make sure that it boots OK, then move the hard drive to your server computer? - If it works, then something was wrong with the installer. - If it does not, you should be able to move the hard drive back to the original computer and use `journalctl` to provide the logs for the failed boot.
Big_Al_Tx avatar
cn flag
@pa4080 - I didn't see any options for anything called "secure boot" or "AHCI", but I'll look again.
Big_Al_Tx avatar
cn flag
@Alejandro - I don't have another computer readily available to do that, but that isn't something I had tried yet. My main concern is that the type of installation on the second system is compatible with the current computer (i.e., legacy boot rather than UEFI). Another thing to look into. Thanks for the suggestion.
Jags avatar
kp flag
@big-al-tx if everything else fails, as a last option you could try converting Ubuntu desktop 20.04.3 into a server, since Desktop is booting just fine.
R0bur avatar
mx flag
Are you ready to reinstall it one more time? But before to do this try to wipe the boot sector and partition table of the HDD (!you will lost ALL data!) executing the command "$ sudo dd if=/dev/zero of=/dev/sdX bs=1024k count=8096" replacing sdX with your HDD name (execute lsblk to get it). To do this - boot Live Server media and switch to the second VT using [Alt]+[F2]. Then !reboot! and install the OS with default options.
jpbrain avatar
ca flag
Hello @Big_Al_Tx. I have a similar machine (DQ45EK / Core 2 Duo / 4GB ) running 20.04.3 Server x64. with gpt. I have had similar problems when disk was about to fail. Do you have the possibility to use a different hard disk to try? (sorry if I missed something... I did not go on all the details and comments, just a quick look )
Big_Al_Tx avatar
cn flag
@jpbrain - I did try different physical drives to rule out that there was something wrong with them, but the results were the same regardless of which one I used.
Big_Al_Tx avatar
cn flag
@R0bur - FYI, when I said I "wiped" the drive, that's what I did -- the MBR, partition table, every sector of the drive overwritten with zeroes.
R0bur avatar
mx flag
@Big_Al_Tx - Ok, thank you for the attention.
Score:5
jp flag

The old style Ubuntu Server iso file with the Debian installer

I suggest that you take a step backward and try the well tested Ubuntu server iso file with the debian installer. It is rather well hidden, but here is a link, where you can download it,

You can try

Remember to check the sha256sum,

<<< 'f11bda2f2caed8f420802b59f382c25160b114ccc665dbac9c5046e7fceaced2 *ubuntu-20.04.1-legacy-server-amd64.iso' sha256sum -c

Cloning to a USB pendrive

You can clone from the iso file to a USB pendrive for example with

  • the Ubuntu Startup Disk Creator or
  • Disks alias gnome-disks or
  • mkusb.

Use a simple USB pendrive

A simple and cheap Sandisk Cruzer Blade USB 2 pendrive works well, but I have had problems with a more advanced USB 3 pendrive, that 'pretends' to be a SATA drive. The installer wanted me to insert a CD disk !!! So if that happens, you can simply borrow or buy the simplest possible pendrive and try again.

Stay with the kernel series or upgrade the HWE stack

It will probably work well with the 5.4 linux kernel series, but if you upgrade the hardware enablement (HWE) stack you will get the same kernel series as Ubuntu 20.04.3. That in turn will be upgraded with new HWE stacks until 20.04.5 (with the same kernel series as the next Ubuntu LTS release, 22.04. There is a risk however, that something will stop working with new HWE stacks, so if the server works well, I suggest that you stay with the 5.4 linux kernel series.

Try different boot modes

Edit 1: If you have problems with this iso file too, I suggest that you switch between UEFI mode and BIOS mode (alias CSM alias legacy mode), but in my computers this legacy server's debian installer works both in UEFI mode and BIOS mode.

Try different virtual screens

Edit 3: In the beginning my server's screen was showing the text properly, but after an apt update && apt upgrade and reboot the screen was locked with only a blinking cursor. Maybe this is what you see. The server could/can still be reached via ssh via the network from another computer (if openssh-server is installed).

I get around this by entering different virtual screens.

  • Press a hotkey combination CtrlAltF1 or CtrlAltF2 ... CtrlAltF6.

  • If you press CtrlAltF7 you will probably get back to a screen with a twinkling star in the northwest corner of the sky.

I get rid of this twinking star by the following tweak: put a # character in front of the line that sets the boot "quiet splash", change

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to a comment (not active code, only information)

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

in the file /etc/default/grub and after that run

sudo update-grub

Install via Xubuntu Core

Edit 2: If still problems, you can install the lightest possible desktop system, Xubuntu Core. It has a desktop, but not the typical desktop application programs. It will probably work to install your system, and once installed you can remove the package

xubuntu-core

which is a meta package and the packages that you think use too much drive space. Then you can instead install the program packages that you want in your server,

ubuntu-server openssh-server ...

This is not straightforward but it is possible.

PS.

Look at my comments to your question again. Maybe they can help you find a solution or workaround.

Big_Al_Tx avatar
cn flag
BOOM! That did it, smooth as hot butter! The legacy installer ran smoothly with no errors, rebooted with all the initiation messages you'd expect to see during start-up, and I was able log-in right off. And this installer saved me some extra work by configuring most of the server applications that I would have wanted anyway. I still don't know exactly why the others wouldn't install what I needed, but I can investigate that later. The important part is that it now works; I just need to apply all of the updates and I'm off to the races. Thanks a lot.
Big_Al_Tx avatar
cn flag
I forgot to mention that I had tried before to see if there was some video weirdness or if I could switch to a different virtual console, but no key presses of any kind seemed to be recognized.
sudodus avatar
jp flag
@Big_Al_Tx, I'm glad that I could help you find a solution :-)
Score:2
de flag

It sounds a lot like your system is using a legacy bios which only supports booting from MBR while the Ubuntu installer tries to format the disk using GPT instead of MBR style. The easiest way to fix this is to convert from GPT to MBR:

https://superuser.com/questions/1250895/converting-between-gpt-and-mbr-hard-drive-without-losing-data

Then you need to manually reinstall grub:

sudo apt-get purge grub-* os-prober grub-gfxpayload-lists 
sudo apt-get install grub-pc os-prober grub-gfxpayload-lists 
sudo grub-install /dev/sd<your boot device without partition number>

Or even worse: There had been devices around that used 32 Bit UEFI and where not able to load 64 Bit Grub binaries or something along those lines. I remember this special issue with some older Laptops made by MEDION. In order for those systems to boot correctly, you need to place bootia32.efi on your /EFI/BOOT on your UEFI partition. See this answer for reference: Ubuntu on 32-bit UEFI (only) based tablet pc

Big_Al_Tx avatar
cn flag
I think you might be onto something. The last time I installed Ubuntu Desktop (using all the default settings), I forgot to mention that the installer created a small partition just for /boot/efi (formatted as FAT32). I'll try your first suggestion and I'll let you know how that works out. Thanks.
Marcel Noe avatar
de flag
I would be really interested in the results of this. The release notes of the Bios of the DG965RY are quite interesting. It seems to be based on InsydeH2O which is built on top of UEFI while trying to behave like a classical bios. The release notes state several issues with detecting partitions, e.g: "if the first partition is deleted, BIOS will not be able to recognize the other two partitions, and if the second partition is deleted, BIOS will not be able to recognize the third partition". You can try upgrading to BIOS 1761 which seems to be the latest to fix that one.
Big_Al_Tx avatar
cn flag
It turns out that both the Desktop & Server installers set the drive for BIOS Legacy booting with the MBR. Both reported `GPT: not present`. The difference is that the Desktop installation had a separate partition for the /boot/efi directory, and the Server did not (and no option to make it use one). I haven't tried your 2nd idea yet; I'm going to try the legacy installer idea first (that looks a lot more straightforward).
Marcel Noe avatar
de flag
The installer should create the EFI partition if there is enough free space on the disk, you've booted the installer via UEFI and not via Legacy Boot and the disk uses GPT. You always have the option to use GPARTED to take some space from an existing partition and manually create the UEFI System partition (ESD). It should be ~512MB of size, formated with fat32 and needs the flags 'boot' and 'esp'. parted or gparted can create that partition. It should have a directory /boot/efi/EFI/BOOT which contained a bootloader for your platform (BOOTX64.EFI or BOOTIA32.EFI).
Big_Al_Tx avatar
cn flag
I agree, that's what it ***should*** do. The Desktop installer ***did*** create a ~512MB EFI partition formatted as FAT32 and mounted it at /boot/efi, and ***it worked***. The Server installer, for the ***same version*** of Ubuntu (20.04.3) ***didn't***, even with a completely blank disk. That's what was so frustrating. Also, the Server installer won't use *any* partition for the installation unless ***it*** is the one to format that partition, so using gPartEd ahead of time won't work -- the Server installer gives you an option to either ignore it or overwrite it.
Marcel Noe avatar
de flag
From an academical point of view it would be interesting, if the alternate installer of the desktop version runs into the same problem. I suppose that the graphical installer gets a lot more attention because it is used by a lot more people. The last time I used the server installer must have been in 2011 - nowadays I use the desktop isos also for Server installations and use a ansible playbook to get rid of all the GUI clutter.
Score:1
kr flag

Your machine is very old, better use a 32bit Linux.

Get Debian 11, it's a fine and stable OS.

32bit-Boot-CD-Installer: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.0.0+nonfree/i386/iso-cd/

32bit-Boot-DVD-Installer: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.0.0+nonfree/i386/iso-dvd/

PS Debian is like Ubuntu, but better for older hardware

PPS you can "burn" those ISO also to a USB stick, it will boot (via dd if=/tmp/debian.iso of=/dev/sdX status=progress && sync, where sdX is your USB stick)

Big_Al_Tx avatar
cn flag
The Mint 18.3 I previously had on that system was 64-bit, and so is the Ubuntu Desktop that I successfully installed, so being 64-bit isn't the problem. And as I mentioned above, I did try to install Debian (v11.0.0) before, and the result was the same as Ubuntu Server. I also need to stick with Ubuntu Server because that's same the OS that'll be used when my customer deploys the software I'm writing. I need to use the same OS, software, and setup for development, testing, and configuration to ensure I identify all issues before I deliver it to my customer. If it was just for me ...
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.