Warren Young
2019-Feb-21 19:00 UTC
[CentOS] 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.
Gianluca Cecchi
2019-Feb-21 23:42 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
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
Warren Young
2019-Feb-22 00:28 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
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.confThanks! We?ll be building another server next week, so I?ll try this then.
Warren Young
2019-Feb-22 14:22 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
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
Simon Matter
2019-Feb-22 15:24 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
> 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
mark
2019-Feb-22 16:31 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
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
Warren Young
2019-Mar-01 16:27 UTC
[CentOS] Setting GDM resolution without knowing the monitor specs
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 syncsThis works fine here on our test monitors, with the exception that the first ?x? needs to be capitalized. Thanks again!
Possibly Parallel Threads
- Setting GDM resolution without knowing the monitor specs
- Setting GDM resolution without knowing the monitor specs
- Setting GDM resolution without knowing the monitor specs
- Setting GDM resolution without knowing the monitor specs
- Setting GDM resolution without knowing the monitor specs