Re: [CentOS] Setting GDM resolution without knowing the monitor specs
Il Ven 1 Mar 2019, 17:28 Warren Young ha scritto: > On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi > 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! > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos Great! Yes it was a typo. Well done, Gianluca ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi 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! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
Warren Young wrote: > On Feb 21, 2019, at 12:00 PM, Warren Young wrote: > 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. > 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 slght 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. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
Simon Matter via CentOS wrote: > > 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 :-) I always use the following install/boot cmdline options to disable CNDN: biosdevname=0 net.ifnames=0 e.g see https://access.redhat.com/discussions/916973 James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
>> On Feb 21, 2019, at 12:00 PM, Warren Young 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 slght 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 :-) I'd like to add here that the reason for not having /dev files for network devices was a historical "accident" in Unix development. Would be nice to have them to make Linux more consistent and then it could be handled similar to disk devices by udev or other means. I'm just dreaming... Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
> On Feb 21, 2019, at 12:00 PM, Warren Young 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 slght 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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
On Feb 21, 2019, at 12:00 PM, Warren Young 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 slght 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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
On Feb 21, 2019, at 11:13 PM, Simon Matter via CentOS wrote: > >> On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi >> wrote: >>> >>> [root@desktop xorg.conf.d]# cat 00-monitor.conf > > Why not just ship it with text mode login and get rid of all the video > problems? With a 800x600 resolution I doubt they can do a lot with the GUI > anyway. Because I can talk a Windows admin through an IP change over the phone easier via Settings > Network than with nano in /etc/sysconfig/network-scripts. I’ve tried it both ways several times, and it’s not even a close thing. Once I’ve got remote access, the screen gets turned back off, never to turn back on for perhaps years at a time. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
> On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi > wrote: >> >> [root@desktop xorg.conf.d]# cat 00-monitor.conf Why not just ship it with text mode login and get rid of all the video problems? With a 800x600 resolution I doubt they can do a lot with the GUI anyway. Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
On Feb 21, 2019, at 4:42 PM, Gianluca Cecchi wrote: > > [root@desktop xorg.conf.d]# cat 00-monitor.conf Thanks! We’ll be building another server next week, so I’ll try this then. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Setting GDM resolution without knowing the monitor specs
On Thu, Feb 21, 2019 at 8:00 PM Warren Young 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@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" DefaultDepth24 SubSection "Display" Depth24 Modes "800x600" EndSubSection EndSection [root@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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[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 s 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: 0 0 yes VGA-1 SAM SyncMaster H1AK50 800 600 60 I have tried: 1. Removing the section entirely. gdm then gives me a black screen on “systemctl restart gdm” from a text console. 2. Filling out all fields except 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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
