CentOS - Mar 2019 - Setting GDM resolution without knowing the monitor specs

We had a complaint recently from a customer that received a server we shipped
out that their monitor just showed a black screen.  It turns out that they?d
hooked it up to an ancient POS with 800x600 as its best resolution, and gdm in
CentOS 7 apparently assumes at least 1024x768.  It was apparently a major hassle
for them to hunt down a reasonable monitor for us.

Since we almost never use the GUI on these things, we thought we?d solve that
problem going forward by shipping these boxes out to use a fixed 800x600, so
they?ll work on any monitor the user plugs in.

The first problem you run into is that the Settings > Devices > Display
GUI only affects the login you do it under.  GDM doesn?t pay attention to this,
not even to the configuration set as root!

Then you go web searching and find solutions involving xrandr and advice to just
put it in /etc/gdm/Init/Default, but that doesn?t seem to work.

I then got soooo close when I found the advice to set the monitor configuration
in the GUI, then copy ~/.config/monitors.xml to /var/lib/gdm/.config.  That
works?until you plug in a different monitor, because that file has a hard tie to
the monitor brand, model and *serial number*!

The monitors.xml file looks like this:

<monitors version="2">
  <configuration>
    <migrated/>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>VGA-1</connector>
          <vendor>SAM</vendor>
          <product>SyncMaster</product>
          <serial>H1AK500000</serial>
        </monitorspec>
        <mode>
          <width>800</width>
          <height>600</height>
          <rate>60</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>

I have tried:

1. Removing the <monitorspec> section entirely.  gdm then gives me a black
screen on ?systemctl restart gdm? from a text console.

2. Filling out all fields except <connector> with values like ?default?,
?generic?, ?any?, ?*?, etc.  GDM decides you couldn?t possibly mean for this
configuration to apply to that monitor, since it differs, so it ignores you and
does whatever it likes instead.

3. Lots and lots of web searching for documentation on the file format to see if
I can find out if there is a different way of specifying ?any monitor, I don?t
care?.

I was about to go reading the source code, but I thought I?d ask here first.

Keep in mind that we ship these systems out without knowing what monitor they?ll
plug in, and once the systems are out in the field, it?s often difficult to get
remote access to them.  That means we can?t just log in with SSH, probe it with
xrandr, and fix it remotely; we?re probably having the customer log in via the
GUI to fix the problem that prevents us from SSHing in in the first place!

It?s fine in our case to pin the configuration to ?VGA-1?, because we know what
connectors are on the server itself.  We just don?t know what the customer will
plug into it.

I assume there?s a minimum screen resolution for CentOS 7, probably 1024x768,
but we?re installing these systems with a reasonable screen.  We only need this
low resolution post-install, and then only so the customer can pull up a
terminal and maybe run the Network settings tool.  For that, 800x600 is fine. 
You do have to drag the Settings app around a bit to see everything, but it
works.

Our current fallback is Ctrl-Alt-F2 and nano, which is tolerable for some things
? ?Okay, type ?ifconfig??now find the line that has ?inet? in it, and read that
back to me?? ? but remotely talking someone through changing ifcfg-noisenoise
via nano is a minor nightmare, especially now that Confusing Network Device
Naming is the default.

On Thu, Feb 21, 2019 at 8:00 PM Warren Young <warren at etr-usa.com>
wrote:
> We had a complaint recently from a customer that received a server we
> shipped out that their monitor just showed a black screen.  It turns out
> that they?d hooked it up to an ancient POS with 800x600 as its best
> resolution, and gdm in CentOS 7 apparently assumes at least 1024x768.  It
> was apparently a major hassle for them to hunt down a reasonable monitor
> for us.
>
>
Hi, I would try the old days way at a lower level..

Create a file 00-monitor.conf under /etc/x11/xorg.conf.d

Something like this below, using conservative range values for horiz and
vert syncs

[root at desktop xorg.conf.d]# cat 00-monitor.conf
Section "Device"
    Identifier    "Default Video Device"
EndSection

Section "Monitor"
    Identifier    "Default Monitor"
    HorizSync       30.0-62.0
    VertRefresh     50.0-70.0
EndSection

Section "Screen"
    Identifier    "Default Screen"
    Monitor        "Default Monitor"
    Device        "Default Video Device"
    DefaultDepth    24
    SubSection "Display"
        Depth    24
        Modes     "800x600"
    EndSubSection
EndSection
[root at desktop xorg.conf.d]#

This way it should be forced to use 800x600 resolution, also because of
conservative values the vesa settings for higher resolutions should be out
of range.
I tried with a CentOS 7 VM in oVirt where by default it gets 1024x768 and
after these settings and reboot, both gdm and graphical sessions got 800x600

In Xorg.0.log I get

[    15.554] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    15.554] (==) Using system config directory
"/usr/share/X11/xorg.conf.d"
[    15.558] (==) No Layout section.  Using the first Screen section.
[    15.558] (**) |-->Screen "Default Screen" (0)
[    15.558] (**) |   |-->Monitor "Default Monitor"
[    15.559] (**) |   |-->Device "Default Video Device"
[    15.559] (==) Automatically adding devices
[    15.559] (==) Automatically enabling devices
[    15.559] (==) Automatically adding GPU devices
. . .
[    15.659] (II) qxl(0): Not using mode "1920x1200" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "1920x1080" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "1600x1200" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "1680x1050" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "1400x1050" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "1280x1024" (hsync out of
range)
[    15.659] (II) qxl(0): Not using mode "640x480" (hsync out of
range)
[    15.659] (II) qxl(0): Printing probed modes for output Virtual-0
[    15.659] (II) qxl(0): Modeline "800x600"x59.9   38.25  800 832 912
1024  600 603 607 624 -hsync +vsync (37.4 kHz UP)
[    15.659] (II) qxl(0): Modeline "1024x768"x59.9   63.50  1024 1072
1176
1328  768 771 775 798 -hsync +vsync (47.8 kHz P)
. . .
[    15.659] (--) Depth 24 pixmap format is 32 bpp
[    15.662] (II) UXA(0): Driver registered support for the following
operations:
[    15.662] (II)         solid
[    15.662] (II)         copy
[    15.662] (II)         composite (RENDER acceleration)
[    15.662] (II)         put_image
[    15.663] (II) qxl(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
[    15.664] resizing primary to 1024x768


HIH,
Gianluca

On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi <gianluca.cecchi at
gmail.com> wrote:
> 
> [root at desktop xorg.conf.d]# cat 00-monitor.conf
Thanks!  We?ll be building another server next week, so I?ll try this then.

On Feb 21, 2019, at 12:00 PM, Warren Young <warren at etr-usa.com>
wrote:
> 
> remotely talking someone through changing ifcfg-noisenoise via nano is a
minor nightmare, especially now that Confusing Network Device Naming is the
default.
A relevant war story might help here.

We were upgrading an old CentOS 5 box in the field.  They refused to ship it
back to us, and they refused to buy a whole new box, but they had to have the
newest software.

This being CentOS, ?yum upgrade? wasn?t going to get us to CentOS 7.  What to
do?

So, I logged into it remotely, poked around a bit, and got it to divulge the
motherboard, CPU, etc. that we?d used on it, and I found that we had a
nearly-identical box sitting around powered off locally, it having given us many
years of useful service and then been retired.  Same motherboard, same CPU, same
RAM, probably even bought within the same year.

So, I dropped a fresh system drive into that box, loaded CentOS 7 and all of our
stuff onto it, configured the network and everything else under /etc the same as
the box in the field, and shipped the drive out to the customer.

They put the drive in, booted it up, and it didn?t reappear on their network. 
No remote access, no presence on the LAN.  It wouldn?t even ping.

After a ridiculous amount of remote troubleshooting, it turned out that these
two motherboards ? despite having the same model number and EFI firmware version
? had a sliiiight difference: the first NIC appeared as enp2s0 and the second as
enp3s0 on one motherboard, but as enp3s0 and enp4s0 on the other!  So, one
network config wasn?t being applied, and the second was being applied to the
wrong NIC.

And here I thought the point of [CNDN][1] was to make such replacements more
reliable than the plug-and-pray logic behind ethN.

This is the sort of reason why I need non-Linux sysadmin types to be able to
change IPs in the field.


[1]: https://en.wikipedia.org/wiki/Consistent_Network_Device_Naming

> On Feb 21, 2019, at 12:00 PM, Warren Young <warren at etr-usa.com>
wrote:
>>
>> remotely talking someone through changing ifcfg-noisenoise via nano is
a
>> minor nightmare, especially now that Confusing Network Device Naming is
>> the default.
>
> A relevant war story might help here.
>
> We were upgrading an old CentOS 5 box in the field.  They refused to ship
> it back to us, and they refused to buy a whole new box, but they had to
> have the newest software.
>
> This being CentOS, ?yum upgrade? wasn?t going to get us to CentOS 7.  What
> to do?
>
> So, I logged into it remotely, poked around a bit, and got it to divulge
> the motherboard, CPU, etc. that we?d used on it, and I found that we had a
> nearly-identical box sitting around powered off locally, it having given
> us many years of useful service and then been retired.  Same motherboard,
> same CPU, same RAM, probably even bought within the same year.
>
> So, I dropped a fresh system drive into that box, loaded CentOS 7 and all
> of our stuff onto it, configured the network and everything else under
> /etc the same as the box in the field, and shipped the drive out to the
> customer.
>
> They put the drive in, booted it up, and it didn?t reappear on their
> network.  No remote access, no presence on the LAN.  It wouldn?t even
> ping.
>
> After a ridiculous amount of remote troubleshooting, it turned out that
> these two motherboards ? despite having the same model number and EFI
> firmware version ? had a sliiiight difference: the first NIC appeared as
> enp2s0 and the second as enp3s0 on one motherboard, but as enp3s0 and
> enp4s0 on the other!  So, one network config wasn?t being applied, and the
> second was being applied to the wrong NIC.
>
> And here I thought the point of [CNDN][1] was to make such replacements
> more reliable than the plug-and-pray logic behind ethN.
One of the reasons why I hate the new naming scheme. It was also easy in
the past to always monitor eth0, eth1 on a server, now you always have to
first find out how the devices are named. I don't see progress here, I see
a step back only. Maybe that's only me :-)

Regards,
Simon

Warren Young wrote:
> On Feb 21, 2019, at 12:00 PM, Warren Young <warren at etr-usa.com>
wrote:
<snip>
> So, I logged into it remotely, poked around a bit, and got it to divulge
> the motherboard, CPU, etc. that we?d used on it, and I found that we had
> a nearly-identical box sitting around powered off locally, it having
> given us many years of useful service and then been retired.  Same
> motherboard, same CPU, same RAM, probably even bought within the same
> year.
<snip>
> They put the drive in, booted it up, and it didn?t reappear on their
> network.  No remote access, no presence on the LAN.  It wouldn?t even
> ping.
>
> After a ridiculous amount of remote troubleshooting, it turned out that
> these two motherboards ? despite having the same model number and EFI
> firmware version ? had a sliiiight difference: the first NIC appeared as
> enp2s0 and the second as enp3s0 on one motherboard, but as enp3s0 and
> enp4s0 on the other!  So, one network config wasn?t being applied, and
> the second was being applied to the wrong NIC.
>
> And here I thought the point of [CNDN][1] was to make such replacements
> more reliable than the plug-and-pray logic behind ethN.
Oh, yeah, right, and those "consistant names" mean *ANYTHING* to an
ordinary sysadmin, dealing with systems from different vendors of varying
age, who's not an EE. I *loathe* them. Give me eth0 or em1, not some
random string. It was fine when Sun used it... but that was on *their*
hardware, not hardware from three or four different vendors.
<snip>
         mark

On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi <gianluca.cecchi at
gmail.com> wrote:
> 
> Create a file 00-monitor.conf under /etc/x11/xorg.conf.d
> 
> Something like this below, using conservative range values for horiz and
> vert syncs
This works fine here on our test monitors, with the exception that the first ?x?
needs to be capitalized.

Thanks again!