Re: [CentOS] systemd override.conf question
On 04/24/2017 07:37 PM, Jonathan Billings wrote: On Mon, Apr 24, 2017 at 06:35:38PM +0200, Robert Moskowitz wrote: Does the override.conf file need the section headers? For example: # cat /etc/systemd/system/postfix.service.d/override.conf [Unit] After=syslog.target network.target time-sync.target Will it work with just the After line, or is the [Unit] line needed to control the merge function. It needs to know what section (such as [Unit], [Service] and [Install]) the configuration option is in, so yes, it needs the [Unit] line. thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-virt] Issues with exposing USB serial dongle to guest VM
Hi. I have Centos 7 (updated) running as my host, and I’m using Qemu and KVM, version 2.0.0 and 2.6.0. I have a Trendnet TU-S9 USB serial dongle attached to the host, which uses the Prolific 2303 chipset. I blacklisted the pl2303 driver so the host doesn’t grab the device, and want to expose it to the guest. On the client, I see 2 USB hubs (3.0 and 2.0), and I see 2 USB endpoints (even though 3 are configured). So the USB CF card readers are visible, but not the USB dongle, even though it’s plugged in. Here’s what I see on the host: [philipp@kvm1 ~]$ ps -f -p13468 UIDPID PPID C STIME TTY TIME CMD qemu 13468 1 2 14:51 ?00:02:39 /usr/libexec/qemu-kvm -name guest=ubuntu16.04-2,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-ubuntu16.04-2/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off -cpu Broadwell,+vme,+ds,+acpi,+ss,+ht,+tm,+pbe,+dtes64,+monitor,+ds_cpl,+vmx,+smx,+est,+tm2,+xtpr,+pdcm,+dca,+osxsave,+f16c,+rdrand,+arat,+tsc_adjust,+xsaveopt,+pdpe1gb,+abm,+rtm,+hle -m 8192 -realtime mlock=off -smp 8,maxcpus=12,sockets=12,cores=1,threads=1 -uuid a9590ac8-e532-4dce-b6ef-d3b35c0db865 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-ubuntu16.04-2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0xa.0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/ubuntu16.04-2.img,format=raw,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device usb-host,hostbus=3,hostaddr=13,id=hostdev1,bus=usb.0,port=3 -device usb-host,hostbus=3,hostaddr=12,id=hostdev2,bus=usb.0,port=4 -device usb-host,hostbus=3,hostaddr=15,id=hostdev3,bus=usb1.0,port=1 -device vfio-pci,host=07:10.0,id=hostdev0,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on [philipp@kvm1 ~]$ sudo lsof -p 13468 -n -P COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME qemu-kvm 13468 qemu cwd DIR 253,0 242 64 / qemu-kvm 13468 qemu rtd DIR 253,0 242 64 / qemu-kvm 13468 qemu txt REG 253,0 8883768 100834619 /usr/libexec/qemu-kvm qemu-kvm 13468 qemu mem REG 253,019984 34091991 /usr/lib64/sasl2/libplain.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,019984 34091988 /usr/lib64/sasl2/liblogin.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,057888 33916680 /usr/lib64/sasl2/libdigestmd5.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,024160 33916677 /usr/lib64/sasl2/libcrammd5.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,0 1846280 100701718 /usr/lib64/libdb-5.3.so qemu-kvm 13468 qemu mem REG 253,028200 33627120 /usr/lib64/sasl2/libsasldb.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,019952 33627117 /usr/lib64/sasl2/libanonymous.so.3.0.0 qemu-kvm 13468 qemu mem REG 253,062184 100664409 /usr/lib64/libnss_files-2.17.so qemu-kvm 13468 qemu mem REG 253,068192 100701681 /usr/lib64/libbz2.so.1.0.6 qemu-kvm 13468 qemu mem REG 253,099952 100701712 /usr/lib64/libelf-0.166.so qemu-kvm 13468 qemu mem REG 253,0 398264 100701630 /usr/lib64/libpcre.so.1.2.0 qemu-kvm 13468 qemu mem REG 253,028360 100702508 /usr/lib64/libogg.so.0.8.0 qemu-kvm 13468 qemu mem REG 253,0 189256 100882393 /usr/lib64/libvorbis.so.0.4.6
[CentOS] kickstart: dracut-initqueue fails due to unresolvable hostname even though network config looks perfectly ok
Hi, kickstarting fails due to problems with host resolution, even though the network seems to be properly configured through DHCP. eno1 and eno2 are both attached to the network, but only eno1 gets an IP via DHCP. Still `curl` cannot resolve the mirror host and the kickstart host during dracut-initqueue: rdsosreport.txt [...] [ 14.780428] localhost kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [ 19.977052] localhost kernel: tg3 :0b:00.0 eno1: Link is up at 1000 Mbps, full duplex [ 19.977118] localhost kernel: tg3 :0b:00.0 eno1: Flow control is off for TX and off for RX [ 19.978880] localhost kernel: tg3 :0b:00.0 eno1: EEE is disabled [ 19.980693] localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready [ 19.829468] localhost dracut-initqueue[992]: dhcp: PREINIT eno1 up [ 19.853734] localhost dhclient[1393]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 6 (xid=0x4df19201) [ 26.030151] localhost dhclient[1393]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 13 (xid=0x4df19201) [ 26.033472] localhost dhclient[1393]: DHCPREQUEST on eno1 to 255.255.255.255 port 67 (xid=0x4df19201) [ 26.033668] localhost dhclient[1393]: DHCPOFFER from 10.128.196.98 [ 26.038851] localhost dhclient[1393]: DHCPACK from 10.128.196.98 (xid=0x4df19201) [ 26.067534] localhost dracut-initqueue[992]: dhcp: BOND setting eno1 [ 28.082735] localhost dhclient[1393]: bound to 10.128.196.20 -- renewal in 21301 seconds. [ 28.456131] localhost kernel: tg3 :0b:00.1: irq 153 for MSI/MSI-X [ 28.456149] localhost kernel: tg3 :0b:00.1: irq 154 for MSI/MSI-X [ 28.456165] localhost kernel: tg3 :0b:00.1: irq 155 for MSI/MSI-X [ 28.456180] localhost kernel: tg3 :0b:00.1: irq 156 for MSI/MSI-X [ 28.456196] localhost kernel: tg3 :0b:00.1: irq 157 for MSI/MSI-X [ 28.570450] localhost kernel: IPv6: ADDRCONF(NETDEV_UP): eno2: link is not ready [ 34.024621] localhost kernel: tg3 :0b:00.1 eno2: Link is up at 1000 Mbps, full duplex [ 34.026347] localhost kernel: tg3 :0b:00.1 eno2: Flow control is off for TX and off for RX [ 34.028069] localhost kernel: tg3 :0b:00.1 eno2: EEE is disabled [ 34.029776] localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready [ 33.803606] localhost dracut-initqueue[992]: dhcp: PREINIT eno2 up [ 33.827664] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 7 (xid=0x1e8bdc4b) [ 41.000199] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 15 (xid=0x1e8bdc4b) [ 55.588353] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 18 (xid=0x1e8bdc4b) [ 74.172423] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 12 (xid=0x1e8bdc4b) [ 86.446514] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 9 (xid=0x1e8bdc4b) [ 95.253443] localhost dhclient[1570]: No DHCPOFFERS received. [ 95.253648] localhost dhclient[1570]: No working leases in persistent database - sleeping. [ 95.282175] localhost dracut-initqueue[992]: dhcp: FAIL [ 95.353255] localhost dracut-initqueue[992]: RTNETLINK answers: File exists [ 102.502688] localhost dracut-initqueue[992]: Warning: can't find installer mainimage path in .treeinfo [ 102.517568] localhost dracut-initqueue[992]: % Total% Received % Xferd Average Speed TimeTime Time Current [ 102.525942] localhost dracut-initqueue[992]: Dload Upload Total SpentLeft Speed [ 102.534277] localhost dracut-initqueue[992]: 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left. [ 103.527190] localhost dracut-initqueue[992]: 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left. [ 105.533677] localhost dracut-initqueue[992]: 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left. [ 109.542329] localhost dracut-initqueue[992]: 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: our.centos.mirror; Unknown error [ 109.551613] localhost dracut-initqueue[992]: Warning: Downloading 'http://our.centos.mirror/7.2.1511/os/x86_64/LiveOS/squashfs.img' failed! [ 109.615143] localhost dracut-initqueue[992]: % Total% Received % Xferd Average Speed TimeTime Time Current [ 109.624698] localhost dracut-initqueue[992]: Dload Upload Total SpentLeft Speed [ 109.625018] localhost dracut-initqueue[992]: 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry
Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.
On 04/24/2017 11:52 AM, Warren Young wrote: On Apr 24, 2017, at 7:53 AM, Lamar Owenwrote: James' point isn't the hardware cost, it's the people cost for retraining. Unless you’ve hired monkeys so that you must train them to do their tasks by rote, that is a soft cost, not a hard cost. Dollars are dollars. An hour spent in training as one hour less to 'do work.' (I'm intentionally playing devil's advocate here; I personally don't have a problem with the changes other than I now have to remember to check the OS type and version every time I log in to a server prior to issuing commands). Note also that Byrne’s solution was to move to an entirely different OS, but we don’t hear about the “retraining cost” involved with that. Surely it was a larger jump from C6 or C7 to FreeBSD 10 than from C6 to C7? Guaranteed that it was a much larger jump. Although I am tangentially reminded of Apollo Domain/OS 10 where the SysV/BSD/Aegis behavior was settable by changing an environment variable. It’ll be interesting to see how much change FreeBSD gets in the next 7 years. What is interesting to me, having just worked on a 20-year-old server stack last week, is how much hasn't changed as well as how much of what gets used a lot has changed (remember life before yum? How about early yum that needed to download individual headers?). But 90% of what I learned 30 years ago on Xenix System 3 for the Tandy 6000 still works (mainly because I still use vi :-) ). That depends on the organization and its goals. Very much true. My IT department that I run has a bit of a reputation; our 'stock' answer to any IT question is rumored to be 'it depends.' YMMV, etc. ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once installed, works great... That doesn’t really contradict my point. First, I said “most” hardware, but you’ve gone and cherry-picked uncommonly durable hardware here; you’re probably out in +3 sigma territory. Hey, I just picked what I have here, that's all. I could also talk about our 2007, 2009, and 2010-vintage donated EMC Clariion hardware. We have gotten many Dell PowerEdge servers and Optiplex/Precision desktops donated to us; got 19 Dell PE1950's donated in a lot three years ago, and those are some of our best servers. The last servers we actually bought were a pair of Dell PE6950's in 2007; a grant funded two of them plus VMware VI3 and a couple of EMC Clariion CX3-10c SANs. (All of those are still running and still doing their jobs.) I'd rather have a five-year-old Precision than a 2017-model generic desktop. A bit slower, but it's going to last a whole lot longer. For my own personal use I never buy new; I'll take the same money that would buy a low-end current-year marvel and buy a three to five year-old Precision that will run faster and much longer. My current laptop is a Precision M6700 with a Core i7-3740QM. It was $600 and will run rings around anything built today at that price point (and even twice or thrice that price point I dare say!). But we're talking servers here, and the LS20 blade for the BladeCenter is middle-of-the-road as far as server hardware is concerned. The PE1950 is on the lower side of MOR. A lot of commodity PC-grade SOHO “server” hardware won’t even last the 3 years between major CentOS upgrades before dying of something. There was a period where I’d budget 1-2 years for a Netgear switch, for example. (They appear to be lasting longer now.) I haven't looked at the lower end of the server hardware scale in a long time, although we did get some older low-end Dell PE SC1425's donated to us a while back. They run C7 quite well, too. I'd rather buy a used higher-end box than a new low-end box, which is going to both cost more and wear out sooner. But that's just SOP for a non-profit. Second, the application of my quoted opinion to your situation is that you should run that hardware with CentOS 7 through the EOL of the hardware or software, whichever comes first. That is, I’m advising the change-adverse members of the audience to opt into the second group above, taking OS changes in big lumps when it’s time to move to new hardware anyway. There is no easy solution. The sysadmin's work and continuing education is never done. I don't mind learning new things nor is my budgeted time so tight that I can't spend company time getting familiar with newer admin paradigms. I understand that everyone is not like me (which is probably a good thing). The sysadmin 'political landscape' is not too different from the 'regular' political landscape, really. You have conservatives, and you have progressives. They both think they're right, and they both tend to demonize those who disagree. And both are growing more extremist with time. Is there no middle ground to be had (in the sysadmin world, at least)? I certainly understand and sympathize with James'
Re: [CentOS] sha256sum a dvd
On Mon, Apr 24, 2017 at 12:53:36PM -0400, James B. Byrne wrote: > > CentOS-6.9 > > I am trying to verify a locally created dvd. I am using sha256sum in > this fashion: > sha256sum /dev/sr0 > > Which gave this result: > > sha256sum: /dev/sr0: Input/output error > > > So I tried this: > sha256sum /dev/cdrom > > Which, after some time, also produces: > > sha256sum: /dev/cdrom: Input/output error > > What does this mean and how do I fix it? It means that you're getting an error while reading one of the sectors of the DVD. It might be a problem with the disc, but it could also be a problem with the hardware. Try doing a dd to copy all the bits to a local file, and pay attention to see if it has a problem reading the disc. Then run a sha256sum on the file it created. -- Jonathan Billings___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd override.conf question
On Mon, Apr 24, 2017 at 06:35:38PM +0200, Robert Moskowitz wrote: > Does the override.conf file need the section headers? > > For example: > > # cat /etc/systemd/system/postfix.service.d/override.conf > [Unit] > After=syslog.target network.target time-sync.target > > Will it work with just the After line, or is the [Unit] line needed to > control the merge function. It needs to know what section (such as [Unit], [Service] and [Install]) the configuration option is in, so yes, it needs the [Unit] line. -- Jonathan Billings___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.
On Mon, April 24, 2017 10:52 am, Warren Young wrote: > On Apr 24, 2017, at 7:53 AM, Lamar Owenwrote: >> James' point isn't the hardware cost, it's the people cost for >> retraining. > > Unless youâve hired monkeys so that you must train them to do their tasks by rote, that is a soft cost, not a hard cost. If youâve hired competent IT staff, they will indeed need some time to work out the differences, but they will do that on their own if only given that time. I've been through that, I agree almost on all counts with James Byrne, so I can give some comments from my chair here. Yes, I do consider myself a notch more intelligent sysadmin than a monkey, and it does cost me time to adjust to the differences, and it is annoying, and most annoying is to adjust to some changes in philosophy (whoever considers the last non-existent is allowed to re-qualify me back to the level of monkey ;-) > > Note also that Byrneâs solution was to move to an entirely different OS, > but we donât hear about the âretraining costâ involved with that. Surely it was a larger jump from C6 or C7 to FreeBSD 10 than from C6 to C7? Yes and no. Maybe it is just my case, as I stared migrating servers to FreeBSD even before C7 was released. FreeBSD feels closer to C5, whereas difference between C5 and C7 is more dramatic (in my by no means objective feeling). So, everyone who maintained C5 after quick "jump start" may feel at hone with FreeBSD. My case may be even simpler as as many older sysadmins I maintained a few UNIXes in the past, including FreeBSD. > > He also seems to be sweeping aside the fact that FreeBSD major releases generally stay in support for about half the span of RHEL and its derivatives. True, but keeping your system incrementing in smaller steps that happen more often is not a big deal. But this is a question of taste: both long support life like RHEL and CentOS and shorter but smoother changes like FreeBSD or some Linuxes (Debian and its clone Ubuntu come to mind) - they both have their advantages and their place where they shine. > If he wants to stay on a supported OS the whole time that C7 > remains in support, heâs probably looking at 2 major OS version upgrades. I've been through several FreeBSD major version upgrades on servers I migrated to FreeBSD earliest, and they went smoothly, requiring just 3 reboots in the process. They all had a bunch of jails that were upgraded as well. Not a single major issue that I had to resolve in a process (call me lucky... knocking on wood ;-) > > Itâll be interesting to see how much change FreeBSD gets in the next 7 years. It really is. Unless my usual luck in choosing what I expect to be in a future fails me, not much change will happen to FreeBSD. I was thanking my luck big time for choosing RedHat (and continuing to Fedora, then CentOS) instead of Debian once when big flop in Debian (and all clones) was discovered that was sitting there for over two years (search for Debian predictable keys). My Debian friend was re-creating all his certificates, re-generating ssh keys, rebuilding systems from scratch (as you don't know who might have had root access to your box). And I was repeating myself, that RedHat never had such a big flop. So I hope, I will be the same lucky with my choice of FreeBSD as I was with my choice of RedHat (and clones) back then. And while we are here: My big thanks to RedHat, and big thanks to CentOS team for the great job you guys are doing!! I wish I could help you more than just maintaining CentOS and centosvault public mirrors. Valeri > >> In many ways the Fedora treadmill is easier, being that there are many more smaller jumps than the huge leap from C6 to C7. > > That depends on the organization and its goals. > > If you have a true IT staff that exists just to keep servers up to date and working properly, then yes, youâre right, smaller upgrades every 3-6 > months are often easier to handle than trying to choke down 2-10 years of > changes all at once, depending on the LTS release strategy and how many major upgrades you skip. > > If youâre trying to treat the OS as a base atop which you do something else, and you just need something that will keep working for 2-10 years despite being continually patched, then choking that big ball of changes down every 2-10 years might be preferable. > > My main point is that if youâre going to take the second path, donât cry about how much change there is to choke down when youâre finally forced to move forward. You choose to put off dealing with it for many years; the chickens have come back home to roost, so there will of course > be a lot of work to do. > >> ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once installed, works great... > > That doesnât really contradict my point. > > First, I said âmostâ hardware, but youâve gone and cherry-picked uncommonly durable hardware here; youâre probably out in +3 sigma territory. A lot
[CentOS] sha256sum a dvd
CentOS-6.9 I am trying to verify a locally created dvd. I am using sha256sum in this fashion: sha256sum /dev/sr0 Which gave this result: sha256sum: /dev/sr0: Input/output error So I tried this: sha256sum /dev/cdrom Which, after some time, also produces: sha256sum: /dev/cdrom: Input/output error What does this mean and how do I fix it? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] systemd override.conf question
Does the override.conf file need the section headers? For example: # cat /etc/systemd/system/postfix.service.d/override.conf [Unit] After=syslog.target network.target time-sync.target Will it work with just the After line, or is the [Unit] line needed to control the merge function. thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to PXE kickstart hosts with little memory (Error: "Warning: /dev/root does not exist")?
On 04/21/2017 10:25 PM, Gordon Messmer wrote: On 04/21/2017 12:49 PM, Frank Thommen wrote: It seems, that this is not related to local disk space - as I initally thought - but to too small memory. It only happens with VMs with little RAM (1024 MB). As soon as we raise the available memory to 2048 MB, kickstarting works fine. The RHEL 7 installation guide states, that the minimal memory requirement is 1 GB, so the network installation /should/ work. Yeah, I filed a bug report against the documentation some time ago. https://bugzilla.redhat.com/show_bug.cgi?id=1410948 ...though bugzilla is currently down. Is there a way to install such hosts w/o having to temporarily raise the available memory? None that I'm aware of, as of 7.3. If you have a 7.2 install tree, you can boot the older installer and then update the installed system. Seems easier to boost the memory, typically. I gave it a try with 7.2.1511 and that works fine as long as I have "ip=eth0:dhcp" in my PXE config. As soon as I expand it to "ip=eth0:dhcp ip=eno1:dhcp rd.neednet=1" (I do that to make sure kickstart works independently from the name of the network interface), kickstart enters into emergency mode w/o any error message after a lot of timeout warnings. However that's something we can work around. Thanks for the 7.2 hint. frank ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.
On Apr 24, 2017, at 7:53 AM, Lamar Owenwrote: > > James' point isn't the hardware cost, it's the people cost for retraining. Unless you’ve hired monkeys so that you must train them to do their tasks by rote, that is a soft cost, not a hard cost. If you’ve hired competent IT staff, they will indeed need some time to work out the differences, but they will do that on their own if only given that time. Note also that Byrne’s solution was to move to an entirely different OS, but we don’t hear about the “retraining cost” involved with that. Surely it was a larger jump from C6 or C7 to FreeBSD 10 than from C6 to C7? He also seems to be sweeping aside the fact that FreeBSD major releases generally stay in support for about half the span of RHEL and its derivatives. If he wants to stay on a supported OS the whole time that C7 remains in support, he’s probably looking at 2 major OS version upgrades. It’ll be interesting to see how much change FreeBSD gets in the next 7 years. > In many ways the Fedora treadmill is easier, being that there are many more > smaller jumps than the huge leap from C6 to C7. That depends on the organization and its goals. If you have a true IT staff that exists just to keep servers up to date and working properly, then yes, you’re right, smaller upgrades every 3-6 months are often easier to handle than trying to choke down 2-10 years of changes all at once, depending on the LTS release strategy and how many major upgrades you skip. If you’re trying to treat the OS as a base atop which you do something else, and you just need something that will keep working for 2-10 years despite being continually patched, then choking that big ball of changes down every 2-10 years might be preferable. My main point is that if you’re going to take the second path, don’t cry about how much change there is to choke down when you’re finally forced to move forward. You choose to put off dealing with it for many years; the chickens have come back home to roost, so there will of course be a lot of work to do. > ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once > installed, works great... That doesn’t really contradict my point. First, I said “most” hardware, but you’ve gone and cherry-picked uncommonly durable hardware here; you’re probably out in +3 sigma territory. A lot of commodity PC-grade SOHO “server” hardware won’t even last the 3 years between major CentOS upgrades before dying of something. There was a period where I’d budget 1-2 years for a Netgear switch, for example. (They appear to be lasting longer now.) Second, the application of my quoted opinion to your situation is that you should run that hardware with CentOS 7 through the EOL of the hardware or software, whichever comes first. That is, I’m advising the change-adverse members of the audience to opt into the second group above, taking OS changes in big lumps when it’s time to move to new hardware anyway. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Need a bit of 'archeocomputing' help on CentOS 7.
On Apr 21, 2017, at 10:11 AM, Lamar Owenwrote: > > 1.) Run Red Hat Linux 5.2 (or similar vintage) on KVM on CentOS 7; For what it’s worth, I couldn’t get it working under a modern flavor of VMware, either. I find that telling because VMware tends to have the best driver support of all the VM systems, if only because it’s been around the longest. Unfortunately, current VMware appears to have dropped Linux 2.0 support entirely, along with other contemporaneous things. For instance, even the “legacy Linux” version of its VMware Tools package contains Perl scripts that are written with the assumption that they’re running on at least Perl 5.8, which is contemporaneous with RHL 7.3 and kernel 2.4.18. I spent some time trying to backport those scripts to the Perl 5.004 that ships with RHL 5.2, but gave up after making over a dozen changes with no obvious end in sight. The way I see it, your solution involving CentOS 2.1 and the libc5 compatibility libraries just bought you the last upgrade to your software that you are likely to pull off without heroic efforts. I advise you to use CentOS 7’s remaining supported lifetime to get off this old software somehow. You say there is no open source alternative, yet clearly the software was useful to at least you, and probably others, given that it appears to be commercial software. It might be prudent to sponsor the development of an open source replacement system. > e1000 drivers are not likely available (I couldn't find any). That series of adapters didn’t get Linux support until about 2 years after RHL 5 shipped, according to the sources: http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e1000/e1000_main.c That would make the e1000 driver about ~3 years too late for you. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.
On 04/20/2017 05:55 PM, Warren Young wrote: ... I find that most hardware is ready to fall over by the time the CentOS that was installed on it drops out of support anyway. ... James' point isn't the hardware cost, it's the people cost for retraining. In many ways the Fedora treadmill is easier, being that there are many more smaller jumps than the huge leap from C6 to C7. For the most part, however, I agree with most of your post. I strongly disagree with the paragraph above, though. I have worked for non-profits for most of my career thus far, which spans almost 30 years. Non-profits by their very nature live on the slimmest of margins, and donations of hardware by individuals and companies have been in my experience the bread and butter for obtaining server-quality hardware. The typical donation will be at least one or two generations old before the non-profit gets it; my current employer is just putting in production some IBM BladeCenters with the dual-socket Opteron LS20 blades (10+ years old). Given the spiky workload, these blades are suitable for the targeted use, and the electrical requirements aren't a problem (I've done the math; it would take ten years or more to justify the purchase price of a new blade based on power savings alone, and our power is quite inexpensive here). At least I can use very recent blades, and the eBay prices for 5-year-old blades are pretty good, so when I need that much more power I can get it. Oh, and the LS20 blades are built like tanks. We have a couple hundred of them that were donated, and we're going to use them. For what it's worth, CentOS 7, once installed, works great as long as the lack of a GUI console isn't a problem (something with the BladeCenter's KVM switch and C7's kernel keeps the keyboard from working properly). And don't even get me started on networking equipment, where I still have Catalyst 5500-series hardware in production. (going on 20 years old and still trucking!) And having said that, I just pulled out of service a server for another non-profit that had a power supply fan seize. I posted about moving its application Friday. It is an AMD K6-2/400 with a Western Digital 6GB boot drive and a Maxtor 30GB data drive, running Red Hat Linux 5.2. The Antec power supply was put into service in 1999. It stopped working Friday, and could have probably been put back into operation with a new power supply without a huge amount of work, but I decided it was time. Heh, it was time ten years ago! The 6GB WD drive was only 19 years old; while I honestly wanted to see it turn 20, it was time (power supply glitches caused by overheating of the power supply; worst-case for hard disk death in my experience). Yeah, 24x7 operation for 19 years with minimal downtime. I'm going to personally put it back into service for hysterical raisins, since the VA-503+ board doesn't need re-cap and it runs very well for what it is. I'm not sure what I'm going to run on it yet. (It will be in service for the same reasons I'm going to put a Reh CPU280 running UZI280 into service.). And that’s why I use *all* the major OSes and several weird ones besides. None of it is perfect, yet it all has its place. I couldn't agree more. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-virt] qemu-kvm-ev update
How long does last week's security update remain in the test repo before it gets moved to release? Rgs Neil Wilson ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt