7

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.

0

3 Answers 3

5
+50

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.

1
  • 1
    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
    Sep 10, 2021 at 4:40
2

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

6
  • 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.
    – Big_Al_Tx
    Sep 9, 2021 at 20:06
  • 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.
    – Marcel Noe
    Sep 9, 2021 at 21:23
  • 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).
    – Big_Al_Tx
    Sep 10, 2021 at 3:32
  • 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).
    – Marcel Noe
    Sep 10, 2021 at 6:47
  • 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.
    – Big_Al_Tx
    Sep 10, 2021 at 16:06
1

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)

1
  • 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 ...
    – Big_Al_Tx
    Sep 9, 2021 at 19:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .