Debian installers' issues with its GRUB parts...

[ant]

Hello.

I downloaded, mounted, and booted Debian's net installer ISO (e.g., https://gemmei.ftp.acc.umu.se/debian-cd ... etinst.iso and https://gemmei.ftp.acc.umu.se/cdimage/u ... etinst.iso) in an old 64-bit W7 HPE SP1 VirtualBox v6.1 VM with a brand new virtual SSD (2 virtual drives = 1 old W7 HDD + 1 new blank SSD). I'm trying it
before doing it virtually instead of my real physical PC to learn and practice (don't want to hose my 12 yrs. old real hardware production PC!). I picked most of Debian's defaults (no GUI packages to install for now). I'm currently having problems with its GRUB bootloader part. It detected Vista, but I don't have Vista as shown in my https://i.ibb.co/ctfV40c/Grub-Vista.gif screen shot/capture. I have W7!

I told it no to its "Install the GRUB boot loader to your primary drive." and picked /dev/sdb (new virtual SSD) as shown in https://i.ibb.co/pRKBjBZ/2SDs.gif. I do NOT want to use its GRUB for dual booting. I will manually boot the specific drive to boot its specific OS from BIOS. Anyways, it completed. I told BIOS to boot the new SSD with Debian, but it got stuck with a blank black screen with its blinking _ cursor: https://i.ibb.co/v4xWdMP/rebooted-Stuck.gif. My 64-bit W7's drive still boots though.

I tried again with Buster v10.10, but got the same exact results. What's wrong? Thank you for reading and hopefully answering soon.

[p.H]

From GRUB's point of view, Windows Vista and 7 are the same.

Is the GRUB menu displayed ?
If yes, what happens when you launch Debian in recovery mode ?

[CwF]

and picked /dev/sdb (new virtual SSD) as shown in https://i.ibb.co/pRKBjBZ/2SDs.gif. I do NOT want to use its GRUB for dual booting. I will manually boot the specific drive to boot its specific OS from BIOS.

You need to ensure grub is using the disk uuid and not the /sdx designations.

If you complicate things much more then maybe invest is a drive cage so you have a power switch on each bootable drive then no need for the bios visit on each boot.

[ant]

From GRUB's point of view, Windows Vista and 7 are the same.

Is the GRUB menu displayed ?
If yes, what happens when you launch Debian in recovery mode ?

Oh, it seems like a comestic bug. How can I report it since there's no reportbug during installer? submit@bugs.debian.org wants a package name.

I only get the black blank screen with the blinking cursor in the top left corner as shown in my screen shot/capture earlier. I don't know if that is part of the GRUB screen. I remember in older Debian versions (e.g., Jessie v8), I would get a GUI boot menu with options like Kernel versions and memtest86.

[ant]

and picked /dev/sdb (new virtual SSD) as shown in https://i.ibb.co/pRKBjBZ/2SDs.gif. I do NOT want to use its GRUB for dual booting. I will manually boot the specific drive to boot its specific OS from BIOS.

You need to ensure grub is using the disk uuid and not the /sdx designations.

If you complicate things much more then maybe invest is a drive cage so you have a power switch on each bootable drive then no need for the bios visit on each boot.

Why not sdx designations and use BIOS' boot disk menu? That is how I did it before. I could boot up either Windows or Linux from BIOS directly. Drive cages sound more complex when a simple BIOS' boot menu is easy to me. If not sdx, then how do I know which disk UUID? Is that the enter manual one with sdx options?

[CwF]

Drive cages sound more complex

yes, I said if you get more complex...I have 3-5 choices in a box.

I only get the black blank screen with the blinking cursor

Then check the tty's <Ctrl><ALT><F1> and login and fix whatever other issue is preventing getting to the desktop. Your boot config may be fine, and something else...

[ant]

I only get the black blank screen with its blinking cursor

Then check the tty's <Ctrl><ALT><F1> and login and fix whatever other issue is preventing getting to the desktop. Your boot config may be fine, and something else...

<Ctrl><ALT><F1> does nothing. FYI. It boots up to this stuck screen right away.

[CwF]

<Ctrl><ALT><F1> does nothing.

tty's is plural, check F2 and F4, and I often say check them all! A blinking cursor is not dead, it's confused...

If I understand this right you are getting past grub?
If so, it is acting like a broken install. If I heard you say you build it up in a vm, then return it to the vm and check. For VB I have no information. For qemu/kvm/vmm I know the images transit vm -bare metal without issue if you do it right.

If there is a question about where grub is going, during the grub screen press 'e', and check. You can enter the uuid there (need to 3 times, very long, very annoying). You find your uuid while under vm control.

in cross post timing...

It boots up to this stuck screen right away.

Then you do not have a viable image. Get it into initramfs recovery or grub rescue or better yet get it back into vm mode and start over.

[ant]

<Ctrl><ALT><F1> does nothing.

tty's is plural, check F2 and F4, and I often say check them all! A blinking cursor is not dead, it's confused...

If I understand this right you are getting past grub?
If so, it is acting like a broken install. If I heard you say you build it up in a vm, then return it to the vm and check. For VB I have no information. For qemu/kvm/vmm I know the images transit vm -bare metal without issue if you do it right.

If there is a question about where grub is going, during the grub screen press 'e', and check. You can enter the uuid there (need to 3 times, very long, very annoying). You find your uuid while under vm control.

in cross post timing...

It boots up to this stuck screen right away.

Then you do not have a viable image. Get it into initramfs recovery or grub rescue or better yet get it back into vm mode and start over.

I tried all function keys (F1 to F12). I don't know if it passed or at GRUB. I know the installer installed it into /dev/sdb (second virtual drive). As for pressing E during GRUB screen, that doesn't do anything. Or did you mean during installer's GRUB screen?

Since this is a VM, I can revert and retry but what should I try next? Thanks God that this is not a real hardware PC for me to practice before doing my real production PC.

[CwF]

As for pressing E during GRUB screen

..yes, during grubs display, maybe "-e", been awhile. I have done that on occasion knowing the uuid changed, then update grub within the OS.

installer installed it into /dev/sdb (second virtual drive)

This is bad practice. Moved to bare metal it may not be...Grub should be on the OS partition within the image. This can become an issue when it is designated as something not consistent, check with "dpkg-reconfigure grub-pc" so future updates have the right info.

Since this is a VM,

I can't address how virtual box does whatever it does. I don't know your methods of passing the real disk -or converting images etc, and how this is to produce a viable image for bare metal...
Frankly, dump VB and learn the real thing! I have many post on here explaining qcow2 images and passing entire disk, and the transfer from image to raw. I can offer nothing on VB's abilities and suspect you are not producing a viable image?

I have posted on using qemu-img and believe it can convert VB images. Moving your existing image into qemu cow's may be a worthwhile exercise. From there moving the image to a physical disk, and then passing that disk properly to a operate as a vm, and then arranging a foreign grub to boot from all of the choices.

I will confirm my images will run as the only disk bare metal on any of my machines or as a VM without reconfiguring anything. So the goal is possible. My windows VM's were created years ago and still run in my current setup - I'm not sure VB is so easy like that...

[ant]

As for pressing E during GRUB screen

..yes, during grubs display, maybe "-e", been awhile. I have done that on occasion knowing the uuid changed, then update grub within the OS.

installer installed it into /dev/sdb (second virtual drive)

This is bad practice. Moved to bare metal it may not be...Grub should be on the OS partition within the image. This can become an issue when it is designated as something not consistent, check with "dpkg-reconfigure grub-pc" so future updates have the right info.

Since this is a VM,

I can't address how virtual box does whatever it does. I don't know your methods of passing the real disk -or converting images etc, and how this is to produce a viable image for bare metal...
Frankly, dump VB and learn the real thing! I have many post on here explaining qcow2 images and passing entire disk, and the transfer from image to raw. I can offer nothing on VB's abilities and suspect you are not producing a viable image?

I have posted on using qemu-img and believe it can convert VB images. Moving your existing image into qemu cow's may be a worthwhile exercise. From there moving the image to a physical disk, and then passing that disk properly to a operate as a vm, and then arranging a foreign grub to boot from all of the choices.

I will confirm my images will run as the only disk bare metal on any of my machines or as a VM without reconfiguring anything. So the goal is possible. My windows VM's were created years ago and still run in my current setup - I'm not sure VB is so easy like that...

So, how do I tell it to use the second drive (newly installed Debian) instead of primary drive (64-bit W7 HPE SP1) through its GUI net installer? Are you saying the real PC won't have this problem? I just don't want Debian installer to touch my 64-bit W7 HPE SP1 drive at all. No dual boot from its GRUB.

[CwF]

I'm not positive I'm grasping your point.
Whatever method needs to duplicate reality.
If you want debian to boot with a windows disk visible, then the vm should duplicate that. This means the windows disk should be IN THE VM.
Lots of foo to make that happen, the vm needs at least a copy of something occupying sda.
Better yet, you said bios control, so each OS should be set up as if they are alone - so actually make them alone - that's the power switch point - remove the disk if needed. After things are set then only the bios selection is needed with both disk online.

[ant]

I'm not positive I'm grasping your point.
Whatever method needs to duplicate reality.
If you want debian to boot with a windows disk visible, then the vm should duplicate that. This means the windows disk should be IN THE VM.
Lots of foo to make that happen, the vm needs at least a copy of something occupying sda.
Better yet, you said bios control, so each OS should be set up as if they are alone - so actually make them alone - that's the power switch point - remove the disk if needed. After things are set then only the bios selection is needed with both disk online.

Are you saying to physically disconnect the other drive while installing Debian? FYI. https://i.postimg.cc/JhDyRQxZ/w10vm-Ins ... Loader.gif from my month old 64-bit W10 Pro 21H1 VM. Also, it showed the same issues that I saw with the old 64-bit W7 HPE SP1 VM.

[CwF]

physically disconnect the other drive while installing Debian?

I think so, yes!

I see you did duplicate the disk setup in the vm. If I'm understanding your goal, the grub on the Debian disk does not need any idea of the windows if you'll not be using it's grub to boot. The bios selection is enough. Debian does not need to care about enumerated sdx's, it doesn't need to care - it CAN, but shouldn't. Windows should be the first seen disk and it may have issues if not the first disk, or if its disk order is changed after install, but I don't speak W10 so ?
So, windows on controller first post, debian second post as you have it. When the bios points to the second drive, it will boot debian and be sdb without you telling it. So the windows disk does not need to be present. On most bare metal, hook the disk to port 4 and it will boot all the same and non-mysteriously be sdd, without any other disk installed. Once you occupy ports a,b, and c, even e or f - Debian will be unaffected booting by bios on sdd....

[ant]

physically disconnect the other drive while installing Debian?

I think so, yes!

I see you did duplicate the disk setup in the vm. If I'm understanding your goal, the grub on the Debian disk does not need any idea of the windows if you'll not be using it's grub to boot. The bios selection is enough. Debian does not need to care about enumerated sdx's, it doesn't need to care - it CAN, but shouldn't. Windows should be the first seen disk and it may have issues if not the first disk, or if its disk order is changed after install, but I don't speak W10 so ?
So, windows on controller first post, debian second post as you have it. When the bios points to the second drive, it will boot debian and be sdb without you telling it. So the windows disk does not need to be present. On most bare metal, hook the disk to port 4 and it will boot all the same and non-mysteriously be sdd, without any other disk installed. Once you occupy ports a,b, and c, even e or f - Debian will be unaffected booting by bios on sdd....

Duplicate as in clone? No. I added a new clean drive to install Debian into without touching the old Windows drive. And yes, I just to use BIOS' boot menu to boot what drive I want. Say, I want to boot the new drive with Debian. Or boot the old Windows drive. I don't need a software boot loader. From what I read GRUB is required for Debian even if not using it to boot different OSes.

I just tried removing the old Windows drive and installing Debian into the new drive. Booting it up worked. So, I shut down and readded the old Windows drive. I can boot either drive with its OS from BIOS' boot menu. Boot Windows, no problems. Boot Debian, no problems. I'm still confused why I can't have the old drive (sda) connected during installation when I told GRUB to install into the new Debian drive (sdb). So, you guys are saying not to use sdX. So, how do I install GRUB without it with the old Windows drive still connected?

[CwF]

So, how do I install GRUB without it with the old Windows drive still connected?

If the bios points to drive 2, grub is on drive 2, grub knows the uuid of the disk it's on - done
IT DOES NOT CARE what is on disk 1 or if it exist!!!
It does not need to know, UNLESS you want to use grub to boot Windows!

sdx designations are the human readable part of the program.

I mentioned dpkg... in the future upgrades may ask you to confirm where is grub - pay attention.

Me, I would install debian (or image the disk!) and confirm that it works on PORT 2, the put the windows disk back at port 1, and enjoy.

[ant]

So, how do I install GRUB without it with the old Windows drive still connected?

If the bios points to drive 2, grub is on drive 2, grub knows the uuid of the disk it's on - done
IT DOES NOT CARE what is on disk 1 or if it exist!!!
It does not need to know, UNLESS you want to use grub to boot Windows!

sdx designations are the human readable part of the program.

I mentioned dpkg... in the future upgrades may ask you to confirm where is grub - pay attention.

Me, I would install debian (or image the disk!) and confirm that it works on PORT 2, the put the windows disk back at port 1, and enjoy.

So, you're saying I have to physically disconnect the Windows drive to install Debian?

[CwF]

and enjoy.

So, you're saying I have to physically disconnect the Windows drive to install Debian?

Ah, no. It would not occur to me! I would disconnect it out of best practice.
I'm a bottom liner. I'm saying I'd be done already. There are direct, and indirect ways. Direct is to simplify - I don't get the misunderstanding. If you don't want to involve windows, why are you?

[ant]

and enjoy.

So, you're saying I have to physically disconnect the Windows drive to install Debian?

Ah, no. It would not occur to me! I would disconnect it out of best practice.
I'm a bottom liner. I'm saying I'd be done already. There are direct, and indirect ways. Direct is to simplify - I don't get the misunderstanding. If you don't want to involve windows, why are you?

I still want the old 64-bit W7 in the real PC in case I need it.

[CwF]

I still want the old 64-bit W7 in the real PC in case I need it.

Yes.
You can put it there at any time, that's my point.

You should be able to install debian to any disk with any disk pre-existing. That's not in my ways, so I don't know what's not working for you. I do know you can mix and match after the fact.

And power switches for drives make things simpler after the complexity of the initial install.
I have slapped a debian in a windows box as a second drive and booted it under bios choice many times without issue. Don't create a dependency where there is none! Just put the drive after windows, if that still matters.

Once the debian is booting with the windows drive in place, any update to debians grub will include the windows drive. If you'd like to prevent that a power switch is the most effective way. Sure you can set up os-prober or just push the lit button...or let it be and bios boot to the debian drive and use grub to select windows - I thought that works...