Thanks for the reply
> Machine HP Proliant ML150 with 5GB RAM and currently a single HDD. I
normally
> use a netinst CD created locally from the jigdo image (amd64).
> I have tried to install both basic bullseye rc1 and bullseye rc2 with SSH
> server several times over the last few days, using different netinst CD's,
and
> each time the installation appears to be faultless until I try to boot the
new
> installation. I just want to be able to login locally, do a small amount of
> configuration, and then login remotely over the network. The GRUB display is
> normal, but then the SVGA monitor only shows a single message about
> VMX outside text (disabled by BIOS)
> before the monitor complains that the video is out of range and gives up....
> Is firmware for your graphics device installed?
I always use the "unofficial" installer with firmware, so it was
firmware-bullseye-DI-rc2-amd64-netinst.iso
and
firmware-bullseye-DI-rc2-amd64-i386-netinst.iso
> Try working around the immediate problem by appending nomodeset to the
> kernel command line via E key at Grub menu. For most graphics chips,
> nomodeset blocks a requirement of most AMD, Intel and NVidia GPUs X
> drivers, enabled KMS, so using it is little but a crutch to enable
> reconfiguration and troubleshooting [1].
> What is output from
> lspci -nnk | grep -A3 VGA
This is the output from the working buster 10.10.0 installation:
lspci -nnk | grep -A3 VGA
0a:02.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA
G200e [Pilot] ServerEngines (SEP1) [102b:0522] (rev 02)
Subsystem: Hewlett-Packard Company ProLiant DL140 G3 [103c:31fa]
Kernel driver in use: mgag200
Kernel modules: mgag200
I am not desperate to get bullseye installed at the moment as I can still use
buster 10.10.0, but the release team want to prepare the full release soon.
I see that someone has already reported an issue with (I think) a virtual
different HP machine, which may not be identical.
I have full access (from the running buster 10.10.0 installation) to / for the
rc2 installation, including all the logs from the boot attempt, but all I
could do at the time was to select a Ctl-Alt-f3 terminal, login blind as root,
and do a shutdown.
I can even swap discs and re-install 10.10.0 to use the machine to avoid re-
formatting any of the current partitions, which would change UUID's for the
current 10.10.0, swapping the discs back for further testing.
