Can't boot to new dual boot

[JJJ]

I have Xubuntu on a 1TB M.2 card and it has worked well for years. I think I want to change to Debian, so I downloaded the Xfce flavor of the Debian 12 ISO and burned it to a USB drive. Then I went out and bought a new 2TB M.2 drive and installed it in the computer. When I booted to the flash drive I went through the installation, specifying the new 2TB drive, and at the end the installer stopped and said it had found the Xubuntu installation, and did I want to create a dual boot. I answered 'yes,' and it said that upon booting I would have the choice of which OS to boot to. After the installation completed and I rebooted it went straight into Xubuntu; no option to boot to Debian. While in Xubuntu I noted that the / and /Home partitions on Debian had been mounted, so I looked at them and all the files appeared to be in the partitions.

The BIOS has a feature where you can choose which disk drive you want to boot to; all you have to do is hold down F12 and you will get a menu. I did so, and there was the new M.2 drive in the list, so I selected it. Unfortunately it did not boot. Instead a few minutes later I was staring at a black screen with a flashing underscore in the upper left corner. The keyboard was inactive, and there was no mouse.

I had one more trick up my sleeve - the BIOS directly. In the BIOS I swapped the boot order of the drives so the new M.2 drive would be first to boot. But when I booted it still wouldn't boot Debian; all I got was the same black screen and flashing underscore.

I've been reading up on how to get this to work and I haven't found the answer yet. Both drives have a separate partitions for / and /home, and each of them has a /boot/grub/grub.cfg file. The one in the Debian drive has Debian and Debian-Altenative at the top of the menu entries, followed by 80 (believe it or not) menu entries for Xubuntu. On the Xubuntu drive the file has menu entries only for Xubuntu.

This would probably be easy to fix, if I only knew how. I'm anxiously looking for suggestions.

[JJJ]

I finally succeeded, albeit not very elegantly. I tried and tried to get the BIOS to look in /boot/grub on the Debian drive, but I continually failed. Finally I decided 'OK, if the BIOS won't look at anything but /boot/grub on the Xubuntu drive, then that's where I should put the correct instructions.' It was a bit of a hassle dealing with two files owned by root in different distros, but I finally got the two menu entries for Debian copied from its grub.cfg file into the Xubuntu grub.cfg file. As I rebooted I was telling myself 'no way this is gonna work,' but astonishingly I was quickly looking at Debian 12!

As it booted to Debian 12 I noticed the lines for the grub menu flick by, too fast to read, but I saw eight tiny lines on the 4K monitor. Later, when I went back to Xubuntu I remembered to hit Esc to force Grub to display its menu and leave it there so I could pick what I wanted. All I need to do now is to make Grub always do that, and without my needing to hit Esc. And a readable font would also be nice.

[CwF]

And a readable font would also be nice.

Code: Select all

# dpkg-reconfigure console-setup

Choose something larger than 12x24

[pbear]

The BIOS problem is strange, but another user reported something similar recently. None of my computers have more than one drive, so not something I can test. At a guess, there's a bug in the installer (and/or Grub scripts) such that Debian's boot loader isn't being configured correctly, but that's just a hunch.

In any event, there's a better way to do the workaround. Manually editing grub.cfg isn't a good answer, because it will be recompiled every time Grub updates, which among other things happens with every kernel update. As @sunrat mentioned in your other thread, one option is to enable os-prober. My preference, though, is to use a custom.cfg file, which enables Grub to chain boot to the other OS (here, Debian).

First create the file: sudo touch /boot/grub/custom.cfg. Then using whichever editor you like (with elevated privileges), add something in this form:

Code: Select all

menuentry "Debian" {
    insmod msdos
    insmod ext4
    search --no-floppy --label --set=root Debian
    configfile /boot/grub/grub.cfg
}

Notice the curly brackets, they're essential. The above assumes you are using old-fashioned MBR partition tables. If you're using GPT, replace msdos with gpt; if you're using one of each, retain insmod msdos and add a line insmod gpt. For this to work as shown, you need to add a label to the Debian system partition. (UUID can be used instead, but label is easier, imho.) You can do this from Xubuntu. For my test (in VirtualBox), I installed GParted and used that. Anyhoo, what happens is that Grub is already scripted (by 41_custom) to look for a custom.cfg file; if it finds one, it adds those entries to the boot menu. Selecting Debian will boot its Grub.

Now for the problem of how to display the boot menu. Pretty simple. You need to edit /etc/default/grub to change these lines:

Code: Select all

GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0

to

Code: Select all

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

Then run sudo update-grub to incorporate the changes.

By the way, you should do something about the excess kernel images. There's no reason to keep more than two or three. The simplest solution is sudo apt autoremove, which will retain the current kernel and one backup. Then run update-grub again.

[JJJ]

Thanks for the reply although I didn't understand much of it. As I write this I have reinstalled Debian 12 ten times, and only once would it boot. And after booting it I spent several hours configuring and installing, and then I started uninstalling some of the hundreds of Thai fonts (why?), and when I was almost done I hit the Synaptic Apply button and watched in horror as it proceeded to delete half the operating system. And that was the end of the only installation that I ever got to boot.

Before I go further I like very much the idea of reconfiguring the console, but I didn't get something right:

Code: Select all

dpkg-reconfigure-console-setup
dpkg-reconfigure-console-setup: command not found
sudo apt install dpkg-reconfigure-console-setup
E: Unable to locate package dpkg-reconfigure-console-setup

Back to installing Debian, the main problem is that I'm too uneducated to understand everything in the install process, and I think that is especially true about setting up Grub. I wish the ISO install utility had help file to explain things better. Maybe there's a different install utility, but I haven't stumbled across it yet.

I've got Xubuntu on a three year old 1TB M.2 drive, and I want to keep it as a dual boot, and I want to install Debian 12 on a brand new 2TB M.2 drive, installed a few days ago. The old drive may have only a couple years of life left, so I should center the boot process on the new drive. Sitting here in Xubuntu I see that it found the / and /home partitions on the new drive, and looking at it I see /boot/grub/grub.cfg, but there's another grub.cfg on the Xubuntu drive. Where do I put the custom config file, and which one do I run update-grub on? And what if update-grub screws it up so that neither OS will boot? Make copies first, and after screwup use Knoppix to put back the original, I guess.

[arzgi]

Have not used Knoppix for years, but I have Debian Live CD if I get stuck

So what ever you are using, Xubuntu you said, open terminal, and try

Code: Select all

~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 223,6G  0 disk 
├─sda1   8:1    0   524M  0 part /boot/efi
├─sda2   8:2    0     1K  0 part 
├─sda5   8:5    0 178,9G  0 part /home
├─sda6   8:6    0   7,4G  0 part [SWAP]
└─sda7   8:7    0  36,7G  0 part /

The command was lsblk, can be run as user. Take a screen shot, or write down, so that you have that info when when you install Debian. You probably need to do partitions manually, so you can dictate where grub will be installed.

[JJJ]

@pbear,
Thanks for your advice. I finally got the dpg-configure console-setup to run (had to delete the middle hyphen), and I think I set it to the highest font setting, but nothing changed. Oh well.

As for the custom.cfg file, I created one in the Debian /boot/grub folder, and after I did sudo update-grub, the grub.cfg files in both Debian and Xubuntu folders were edited, with all references to Debian deleted. When I reboot I no longer get any menu; it just automatically boots to Xubuntu. Looks like it's time for reinstall number 11. But I need someone sitting behind me at the end who knows how to do the grub setup for dual boot, because it is obvious that I do not.

[pbear]

Sigh, the custom.cfg file goes in the system in charge of Grub, in this case Xubuntu. As I said, " ... one option is to enable os-prober. My preference, though, is to use a custom.cfg file, which enables Grub to chain boot to the other OS (here, Debian)." With respect to an earlier question, yes, there's another Debian installer. Indeed, the main one is the net installer. You select the desktop as part of the installation process.

[JJJ]

I did another installation (#11) and, as before, I got no Grub menu to choose between Debian and Xubuntu. My BIOS has an option to choose which drive to boot to, by just hitting F12 after the BIOS flashes by. (Useful when trying to boot to a live distro on a USB or optical drive.) I had tried this previously, but if I chose the new drive with Debian on it I just got a black screen with a flashing underscore in the upper left, looking a lot like a cursor awaiting input, except the keyboard was dead. So, after install #11 I tried the F12 trick again. It's easy to see which drive is which because BIOS lists the full names that Samsung gave them. I selected the new drive and, amazingly, Debian 12 booted.

I sat there for a minute contemplating what had just happened. I thought 'who needs a Grub menu?' I decided to verify that the F12 list would also let me boot to Xubuntu, so I shut down Debian and rebooted, also using F12, and this time I chose the old drive. A moment later Xubuntu was booting. Hooray!

So all my efforts to get Grub to create a menu were unnecessary because each OS was on a different drive. The F12 manoeuver probably wouldn't work if both were on the same drive, because F12 just lists whole drives, not their partitions. Others probably have different BIOSes, so this might not always be a solution, but I'm sitting here installing and configuring in my new Debian 12.

[CwF]

So all my efforts to get Grub to create a menu were unnecessary because each OS was on a different drive. The F12 manoeuver probably wouldn't work if both were on the same drive, because F12 just lists whole drives, not their partitions. Others probably have different BIOSes, so this might not always be a solution, but I'm sitting here installing and configuring in my new Debian 12.

...and now we know why it is sensible for os-prober to be off.

[steve_v]

While the OP appears to have a solution of sorts, I can't help thinking that all this would have been a lot easier to diagnose if they had:
* Generated, or at least inspected the proposed contents of grub.cfg manually with grub-mkconfig (and posted it here).
* Installed grub manually with grub-install, possibly specifying the EFI root manually, and possibly in verbose mode (and posted the output).
* listed the contents of /boot/efi (or wherever the EFI partition is mounted).
* Provided more useful disk and partition layout information than "a new 2TB M.2 drive", i.e. the output of lsblk as suggested above.

I'm no expert on this newfangled UEFI nonsense, but nothing but a blinking cursor sounds to me like the bios/uefi loader isn't finding a bootloader on the drive. If it was, you should get at least something from grub. This makes me wonder if the installer is installing the bootloader properly, and to the right place...

now we know why it is sensible for os-prober to be off.

os-prober works just fine, IIRC the main reason it was disabled by default was it's tendency to pick up "other operating systems" it really shouldn't... like VM guests and removable media.
Personally I find multi-boot through grub far more convenient than relying on "press continuously mash [different key on every motherboard] to select boot device" BIOS/firmware functionality.

[sunrat]

now we know why it is sensible for os-prober to be off.

os-prober works just fine, IIRC the main reason it was disabled by default was it's tendency to pick up "other operating systems" it really shouldn't... like VM guests and removable media.
Personally I find multi-boot through grub far more convenient than relying on "press continuously mash [different key on every motherboard] to select boot device" BIOS/firmware functionality.

os_prober has always worked fine for me too. I have about 8 OSs installed currently. Enabling os_prober is one of the first things I do when installing a new Linux.
UEFI boot is much less descriptive than GRUB about which partitions contain which OS. It is a guessing game to select the correct one when many options exist.

[pbear]

It's water under the bridge at this point, so I'll be brief. Sure, os-prober works fine in most cases. OTOH, custom.cfg has a few cool features. I recommended it here because I felt it would be easier than trying to talk the OP through enabling os-prober. As it uses chain boot, updates in secondary systems take effect immediately, i.e., aren't dependent on updating Grub in the primary OS. A custom.cfg file makes it easy to set order of entries in the boot list. And custom grub will work with Arch-based distros as secondary OS, where os-prober will not (or, at least, didn't last time I tested).

[steve_v]

custom.cfg has a few cool features.

It does, as does grub in general... Something which has both proponents and detractors (i.e. grub is too big and too complicated and "most people" just want a simple bootloader). Pretty good coverage of both this approach and usage of the actual 'chainloader' directive over here.
What os-prober brings to the table is automation, such that adding or removing entries for other operating systems requires no config modification, simply running 'update-grub'.