[CentOS] Setting GDM resolution without knowing the monitor specs

Simon Matter simon.matter at invoca.ch
Fri Feb 22 15:54:36 UTC 2019


>> 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 :-)

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



More information about the CentOS mailing list