[CentOS] CentOS-announce Digest, Vol 155, Issue 8
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CEBA-2018:0177 CentOS 6 ntp BugFix Update (Johnny Hughes)
2. CEBA-2018:0175 CentOS 6 util-linux-ng BugFix Update
(Johnny Hughes)
3. CEBA-2018:0172 CentOS 6 xorg-x11-server BugFixUpdate
(Johnny Hughes)
4. CEBA-2018:0174 CentOS 6 python-setuptools BugFix Update
(Johnny Hughes)
5. CEBA-2018:0171 CentOS 6 sysstat BugFix Update (Johnny Hughes)
6. CEBA-2018:0173 CentOS 6 copy-jdk-configs BugFix Update
(Johnny Hughes)
7. CEBA-2018:0170 CentOS 6 samba BugFix Update (Johnny Hughes)
8. CEBA-2018:0176 CentOS 6 selinux-policy BugFix Update
(Johnny Hughes)
9. CESA-2018:0169 Important CentOS 6 kernel Security Update
(Johnny Hughes)
10. CEEA-2018:0232 CentOS 6 tzdata Enhancement Update (Johnny Hughes)
11. CEEA-2018:0232 CentOS 7 tzdata Enhancement Update (Johnny Hughes)
12. CEBA-2018-C001 CentOS 7 yum BugFix Update (Johnny Hughes)
--
Message: 1
Date: Wed, 31 Jan 2018 11:23:09 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2018:0177 CentOS 6 ntp BugFix Update
Message-ID: <20180131112309.ga8...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2018:0177
Upstream details at : https://access.redhat.com/errata/RHBA-2018:0177
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
a34e894b7f4d0f1611c1aef3120d9984831eba0dcbf32925f2dc97746ca8d627
ntp-4.2.6p5-12.el6.centos.2.i686.rpm
4bd52de4c9cd68a8c64bdcbdba4731ab6484acbd40dab301e902b158f1ee8c0b
ntpdate-4.2.6p5-12.el6.centos.2.i686.rpm
aace480a03173bdb8427b6921e3e5778dd8d643aa4060e202a1b86e7b1b32b09
ntp-doc-4.2.6p5-12.el6.centos.2.noarch.rpm
7ab32cb504682ac0037c1ea2a57f4bacd1a1a53374d71124c99117d304fc4775
ntp-perl-4.2.6p5-12.el6.centos.2.i686.rpm
x86_64:
a6b75849dc4500708abf7e3e9cb4eb9a24fb63ed38101785f036f73383252bd9
ntp-4.2.6p5-12.el6.centos.2.x86_64.rpm
fb9b356d5254d9fd8dfc11ca809d855159e2cb69e558434c9845f673f346a45c
ntpdate-4.2.6p5-12.el6.centos.2.x86_64.rpm
aace480a03173bdb8427b6921e3e5778dd8d643aa4060e202a1b86e7b1b32b09
ntp-doc-4.2.6p5-12.el6.centos.2.noarch.rpm
b740b9a6b0ea834c5fba43d209c4eae2d46f6167d5d67b28a19c27dc420edfb0
ntp-perl-4.2.6p5-12.el6.centos.2.x86_64.rpm
Source:
840ea6a27d64a6c775bd744aa7d6084cdb3775242328002fc804fa7aecb471f5
ntp-4.2.6p5-12.el6.centos.2.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 2
Date: Wed, 31 Jan 2018 11:24:03 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2018:0175 CentOS 6 util-linux-ng
BugFix Update
Message-ID: <20180131112403.ga8...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2018:0175
Upstream details at : https://access.redhat.com/errata/RHBA-2018:0175
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
02a1b72b703e58c2a83ad1fb82f0a349e13d43d95abddc434b6cbf08832c3f5e
libblkid-2.17.2-12.28.el6_9.2.i686.rpm
1308e912cb45f1ee2020c9139905a026a70b902108c8a1c650a99979756e96aa
libblkid-devel-2.17.2-12.28.el6_9.2.i686.rpm
437e0faf436d7831351fc225dfde87744ecea4f70d893e3de5c18c85724e00b0
libuuid-2.17.2-12.28.el6_9.2.i686.rpm
1a8a63e9b6015f526f4c3eed02439eab19d7d51d4da7c3b0a89dfb027f5773ba
libuuid-devel-2.17.2-12.28.el6_9.2.i686.rpm
7bf41e121d136ed0033198719c36c2227350f06b88178ae66f5dac01e63cd19e
util-linux-ng-2.17.2-12.28.el6_9.2.i686.rpm
40d4855e55bd1f307ec2bf444323c35a72327fdf55729ab3affcfb07986125d9
uuidd-2.17.2-12.28.el6_9.2.i686.rpm
x86_64:
02a1b72b703e58c2a83ad1fb82f0a349e13d43d95abddc434b6cbf08832c3f5e
libblkid-2.17.2-12.28.el6_9.2.i686.rpm
8bf0d4450653616485eb509fa3d646f80b4606ca110a18d87ed4aa57dcb355a2
libblkid-2.17.2-12.28.el6_9.2.x86_64.rpm
1308e912cb45f1ee2020c9139905a026a70b902108c8a1c650a99979756e96aa
libblkid-devel-2.17.2-12.28.el6_9.2.i686.rpm
653fba9367a034e48a75cdb78a2d3d1c02018cfc786a8b636f978ead98094bcf
libblkid-devel-2.17.2-12.28.el6_9.2.x86_64.rpm
437e0faf436d7831351fc225dfde87744ecea4f70d893e3de5c18c85724e00b0
libuuid-2.17.2-12.28.el6_9.2.i686.rpm
78e538ffb30ae1c33ed276d803c4a82db1cb43c856a7ca0227ee11371d450d15
libuuid-2.17.
Re: [CentOS] Xen hypervisor on CentOS 7.4 with modern UEFI server not booting from grub
On 01/30/2018 04:23 PM, John Naggets wrote: > Hi, > > I installed CentOS 7.4 on a modern Lenovo ThinkSystem SR630 server > which uses UEFI. So far so good CentOS 7.4 works fine so then I went > on to install the Xen hypervisor by following the instructions from > the wiki (https://wiki.centos.org/HowTos/Xen/Xen4QuickStart). > > Unfortunately when I reboot after having installed the xen package the > system does not boot into "CentOS Linux, with Xen hypervisor" from the > grub menu prompt. I get the following error: > > Loading Xen 4.6.6-8.el7 ... > error: can't find command `multiboot'. > Loading Linux 4.9.75-29.el7.x86_64 ... > error: can't find command `module'. > Loading initial ramdisk ... > error: can't find command `module'. > > Press any key to continue... > > The problem which I encounter here is exactly the same issue as > described for Fedora in the RedHat bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=1286317 with the exception > that for me it's CentOS 7.4 and that the workarounds as described in > that bug do not work. > > Does anyone know how I can make my CentOS boot with the Xen hypervisor > using UEFI? > > Thank you very much for your help. > Usually not an issue with UEFI .. but with Secure Boot You need to make sure Secure Boot is off. It is sometimes called Legacy Booting turned on, etc. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen hypervisor on CentOS 7.4 with modern UEFI server not booting from grub
On Tue, Jan 30, 2018 at 11:51:48PM +, Mikhail Utin wrote: > Why do you need UEFI? It does not add to security "a lot" but was > designed to block booting software like a "hypervisor". I used my > Dell notebooks to test our hypervisor identification software > (HyperCatcher if you are interested) which is bootable > image. However, I was unable to boot it until I disabled UEFI. As I > understand it, it will block anything from booting excepting > original OS. Your Xen and our HyperCatcher are outsiders for UEFI. You're thinking of Secure Boot, not all of UEFI. For what its worth, UEFI is what we're stuck with, all modern hardware uses it (and legacy boot is just a special UEFI bootloader). Intel plans to phase out the legacy bootloader in future releases of their chipsets as well, so it wouldn't hurt to learn how to use UEFI. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-announce Digest, Vol 155, Issue 8
centos-announce-requ...@centos.org wrote: > > Message: 9 > Date: Wed, 31 Jan 2018 11:35:03 + > From: Johnny Hughes > To: centos-annou...@centos.org > Subject: [CentOS-announce] CESA-2018:0169 Important CentOS 6 kernel > SecurityUpdate > Message-ID: <20180131113503.ga9...@n04.lon1.karan.org> > Content-Type: text/plain; charset=us-ascii > > > CentOS Errata and Security Advisory 2018:0169 Important > > Upstream details at : https://access.redhat.com/errata/RHBA-2018:0169 That link doesn't exist - I believe it should be: https://access.redhat.com/errata/RHSA-2018:0169 James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] What is best way of managing isolated network environment?
Hello, We need to manage isolated network environment so that even though host name and ip address could be same, but they are located in isolated network environment so that’s not a problem. However, that would be very challenging to build a server in such an isolated environment. For example, we could do kickstart to build a server in non-isolated network environment, but for isolated one, we don’t have such a kickstart server. If we had such one, that would mean we consume more resources for building server. What is best way of managing such isolated environment in terms of easily building servers? Thank you, - xinhuan ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How is initrd.img packed and compressed?
Hi, In order to work around a known upstream bug I needed to add a udev rule to pxeboot initrd.img on CentOS 7. The process is straightforward: 1 - extract the pxeboot initrd.img to a new directory 2 - add the udev rule needed to fix the bug 3 - pack and compress it back in initrd.img format The resulting updated image works, it fixes the upstream bug and life is good. But although it works, it's not the same format as the original initrd.img that ships with the distro. I would like to know the proper incantation used to package initrd.img Now for the specifics. The original image: http://mirror.steadfast.net/ centos/7.4.1708/os/x86_64/isolinux/initrd.img is extracted: /usr/lib/dracut/skipcpio initrd.img | xzcat | cpio -i -d and after adding the needed udev rule, it gets packed and compressed as follows: find . 2>/dev/null | cpio --quiet -c -o | xz -9 --format=lzma >"~/patched-initrd.img" Now for the difference. FIrst the original distro image: # file initrd.img initrd.img: xz compressed data # file patched-initrd.img patched-initrd.img: LZMA compressed data, streamed Without the --format=lzma flag it fails to boot. Does anyone know how this is done properly ? Thanks, -Mike ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd-udevd not applying ATTR to block device at boot
I suppose it would help if I posted relevant version info (sorry about that...)
CentOS Linux release 7.4.1708 (Core) @ 3.10.0-693.11.6.el7.x86_64
systemd-219-42.el7_4.4.x86_64
$ modinfo virtio_scsi
filename:
/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko.xz
license:GPL
description:Virtio SCSI HBA driver
rhelversion:7.4
srcversion: A80DAE9007C7FCF3DDD1501
alias: virtio:d0008v*
depends:virtio,virtio_ring
intree: Y
vermagic: 3.10.0-693.11.6.el7.x86_64 SMP mod_unload modversions
signer: CentOS Linux kernel signing key
sig_key:2C:BC:98:70:54:63:43:CA:3A:E1:20:C2:BC:EB:98:44:01:95:59:62
sig_hashalgo: sha256
I'm happy to provide any other relevant info if needed! Thanks again!
Nick
On 1/31/18, 12:49 AM, "CentOS on behalf of Nick.Jacques"
wrote:
Hi everyone,
I have a udev rule file that contains a singular rule:
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_VENDOR}=="*Google*",
ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}:="noop"
When I use a Google Cloud instance and boot it, things work as expected and
/dev/sda (a persistent disk) uses the noop scheduler. If the instance also has
a Local SSD type disk, however, the change in scheduler is not applied. This is
a bit academic, because the Local SSD device uses noop by default (somehow, I
don’t see any udev rules for setting this outside of my own). But, for
instance, if I set the scheduler in the udev rules to “cfq,” at boot, /dev/sda
will use cfq and /dev/sdb will use noop.
If I run udevadm trigger after boot, then /dev/sdb will use cfq. So, it
appears that at boot time, for some reason, my scheduler is not being applied
to /dev/sdb.
I’ve tried a handful of things:
- changing the order of my udev rule file: I’ve tried 10-, 90-, and 99-
prefixes. My rule file is in /etc/udev/rules.d/.
- using ATTR{queue/scheduler}:="noop" and ATTR{queue/scheduler}="noop"
(both the = and := operator)
- searching the internet for all kinds of variations on “udev rule not
applying at boot”
but so far, I’ve come up empty-handed. The only thing I can think of is
that I am hitting some sort of race condition and udev is unable to set the
ATTR in /sys, but I’m not sure how I can confirm this.
Below are dumps from udevadm of the block devices, /dev/sda (a Google Cloud
persistent disk that is my root partition) and /dev/sdb (a Google Cloud
ephemeral disk [local SSD] that is mounted at /local-ssd).
Thanks in advance for any assistance!
Nick
< trimmed udevadm output>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How is initrd.img packed and compressed?
Don't archive as lzma if you don't want lzma, remove the "--format=lzma" parameter. hth Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Mircea Husz" > To: "CentOS mailing list" > Sent: Wednesday, 31 January, 2018 16:51:20 > Subject: [CentOS] How is initrd.img packed and compressed? > Hi, > > In order to work around a known upstream bug I needed to add a udev > rule to pxeboot initrd.img on CentOS 7. > > The process is straightforward: > 1 - extract the pxeboot initrd.img to a new directory > 2 - add the udev rule needed to fix the bug > 3 - pack and compress it back in initrd.img format > > The resulting updated image works, it fixes the upstream bug and life > is good. But although it works, it's not > the same format as the original initrd.img that ships with the distro. > I would like to know the proper incantation > used to package initrd.img > > Now for the specifics. The original image: http://mirror.steadfast.net/ > centos/7.4.1708/os/x86_64/isolinux/initrd.img > is extracted: /usr/lib/dracut/skipcpio initrd.img | xzcat | cpio -i -d > and after adding the needed udev rule, it gets packed and compressed as > follows: > > find . 2>/dev/null | cpio --quiet -c -o | xz -9 > --format=lzma >"~/patched-initrd.img" > > Now for the difference. FIrst the original distro image: > # file initrd.img > initrd.img: xz compressed data > > # file patched-initrd.img > patched-initrd.img: LZMA compressed data, streamed > Without the --format=lzma flag it fails to boot. > > Does anyone know how this is done properly ? > > Thanks, > -Mike > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen hypervisor on CentOS 7.4 with modern UEFI server not booting from grub
I checked and secure boot is turned off. Jonathan brings it exactly to the point: we have to face UEFI because legacy mode is fading out, if I enable legacy mode I can't even boot anymore through the network (PXE) as these newer network cards can only boot PXE with UEFI. In the mean time I have installed Ubuntu 17.10 with Xen and I was lucky to see that this combination works with UEFI even Xen. On Wed, Jan 31, 2018 at 2:12 PM, Johnny Hughes wrote: > On 01/30/2018 04:23 PM, John Naggets wrote: >> Hi, >> >> I installed CentOS 7.4 on a modern Lenovo ThinkSystem SR630 server >> which uses UEFI. So far so good CentOS 7.4 works fine so then I went >> on to install the Xen hypervisor by following the instructions from >> the wiki (https://wiki.centos.org/HowTos/Xen/Xen4QuickStart). >> >> Unfortunately when I reboot after having installed the xen package the >> system does not boot into "CentOS Linux, with Xen hypervisor" from the >> grub menu prompt. I get the following error: >> >> Loading Xen 4.6.6-8.el7 ... >> error: can't find command `multiboot'. >> Loading Linux 4.9.75-29.el7.x86_64 ... >> error: can't find command `module'. >> Loading initial ramdisk ... >> error: can't find command `module'. >> >> Press any key to continue... >> >> The problem which I encounter here is exactly the same issue as >> described for Fedora in the RedHat bugs: >> https://bugzilla.redhat.com/show_bug.cgi?id=1286317 with the exception >> that for me it's CentOS 7.4 and that the workarounds as described in >> that bug do not work. >> >> Does anyone know how I can make my CentOS boot with the Xen hypervisor >> using UEFI? >> >> Thank you very much for your help. >> > > Usually not an issue with UEFI .. but with Secure Boot > > You need to make sure Secure Boot is off. It is sometimes called Legacy > Booting turned on, etc. > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How is initrd.img packed and compressed?
I have already tried, without --format=lzma it fails to boot. -Mike On Wed, 2018-01-31 at 17:10 +, Nux! wrote: > Don't archive as lzma if you don't want lzma, remove the " > --format=lzma" parameter. > > hth > Lucian > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > - Original Message - > > From: "Mircea Husz" > > To: "CentOS mailing list" > > Sent: Wednesday, 31 January, 2018 16:51:20 > > Subject: [CentOS] How is initrd.img packed and compressed? > > Hi, > > > > In order to work around a known upstream bug I needed to add a udev > > rule to pxeboot initrd.img on CentOS 7. > > > > The process is straightforward: > > 1 - extract the pxeboot initrd.img to a new directory > > 2 - add the udev rule needed to fix the bug > > 3 - pack and compress it back in initrd.img format > > > > The resulting updated image works, it fixes the upstream bug and > > life > > is good. But although it works, it's not > > the same format as the original initrd.img that ships with the > > distro. > > I would like to know the proper incantation > > used to package initrd.img > > > > Now for the specifics. The original image: http://mirror.steadfast. > > net/ > > centos/7.4.1708/os/x86_64/isolinux/initrd.img > > is extracted: /usr/lib/dracut/skipcpio initrd.img | xzcat | cpio > > -i -d > > and after adding the needed udev rule, it gets packed and > > compressed as > > follows: > > > > find . 2>/dev/null | cpio --quiet -c -o | xz -9 > > --format=lzma >"~/patched-initrd.img" > > > > Now for the difference. FIrst the original distro image: > > # file initrd.img > > initrd.img: xz compressed data > > > > # file patched-initrd.img > > patched-initrd.img: LZMA compressed data, streamed > > Without the --format=lzma flag it fails to boot. > > > > Does anyone know how this is done properly ? > > > > Thanks, > > -Mike > > > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How is initrd.img packed and compressed?
Mircea Husz wrote: > > In order to work around a known upstream bug I needed to add a udev > rule to pxeboot initrd.img on CentOS 7. > > The process is straightforward: > 1 - extract the pxeboot initrd.img to a new directory > 2 - add the udev rule needed to fix the bug > 3 - pack and compress it back in initrd.img format Instead of re-creating a new initrd.img, why not just create an 'updates' image that contains your new udev rule and use the 'inst.updates=' pxeboot cmdline option? I use this to add things to the install image - no need to alter the existing initrd image - if you need more info, let me know James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen hypervisor on CentOS 7.4 with modern UEFI server not booting from grub
Once upon a time, John Naggets said: > Jonathan brings it exactly to the point: we have to face UEFI because > legacy mode is fading out, if I enable legacy mode I can't even boot > anymore through the network (PXE) as these newer network cards can > only boot PXE with UEFI. UEFI PXE is different than BIOS PXE and needs to download different software from the TFTP server. I use syslinux for BIOS PXE, but it doesn't seem to work with UEFI PXE so I use grub2 (I use the secure boot shim from Fedora to support as many setups as practical). You can have both available at the same time (takes a DHCP tweak). Just like the early days of BIOS PXE however, UEFI PXE clients don't always seem to do the right thing. I have an Intel NUC (7th gen), and it always fails with UEFI PXE. -- Chris Adams ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How is initrd.img packed and compressed?
On Wed, 2018-01-31 at 19:46 +, James Pearson wrote: > Mircea Husz wrote: > > In order to work around a known upstream bug I needed to add a udev > > rule to pxeboot initrd.img on CentOS 7. > > > > The process is straightforward: > > 1 - extract the pxeboot initrd.img to a new directory > > 2 - add the udev rule needed to fix the bug > > 3 - pack and compress it back in initrd.img format > > Instead of re-creating a new initrd.img, why not just create an > 'updates' image that contains your new udev rule and use the > 'inst.updates=' pxeboot cmdline option? > > I use this to add things to the install image - no need to alter the > existing initrd image - if you need more info, let me know > > James Pearson I would very much like your idea to work for us. I just tried it and found that inst.updates gets loaded later in the boot process than when it's in initrd.img, and for this particular bug that's too late. The udev rule we're adding deals with renaming the network interface, which happens earlier in the boot process. -Mike ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] best centos server setup for graphics intensive kvm vms?
Nux, thanks for you help. I've been following and adapting this guide as necessary: http://kodi.wiki/view/HOW-TO:Install_Kodi_on_Fedora_25_using_RPMFusion_packages Until the point where it says to install kodi... There is no kodi in RPMFusion repo for Centos, only Fedora... But, I see that you are wrapping kodi for centos. After a little searching I came across your repos here: http://mirrors.coreix.net/li.nux.ro/nux/tmp/kodi717/ My questions - can I use your repo as a drop in for the Fedora kodi repo at RPM Fusion? - what's the difference between kodi7/ and kodi717/ ? Many thanks Morgan. On 24/01/18 08:23, Nux! wrote: Yes -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: "Morgan Read" To: "CentOS mailing list" Sent: Tuesday, 23 January, 2018 23:30:57 Subject: Re: [CentOS] best centos server setup for graphics intensive kvm vms? Hmm, So - I guess the best I can hope for is running the host as a full workstation GUI with kodi installed - forget about Libreelec - and then running the rest of appliances as VMs headless? Many thanks for helping clear my thoughts on this. M On 23/01/18 19:01, Nux! wrote: Running a VM with something graphical on top of something else graphical is one thing. What you want is to dedicate the GPU to the Libreelec VM, so it displays directly to the screen (gpu) so it can properly use hardware acceleration and so on, but you can't do that without VT-d/AMD-Vi afaik. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: "Morgan Read" To: "CentOS mailing list" Sent: Tuesday, 23 January, 2018 18:49:58 Subject: Re: [CentOS] best centos server setup for graphics intensive kvm vms? Thanks Nux for the follow up! On 22/01/18 08:54, Nux! wrote: You'd need to run virt-manager GUI somehow to manage the VMs. If you run Fedora already on another machine then you can just yum install it and use it from there. That's what I figured - I already run an XP and W7 virt machines as well as sometimes RemixOS just for fun on my everyday machine and thought I could remote control. You might run into a problem though with your Libreelec VM as you'd need to enable GPU passthrough for it and for that you need Intel VT-d or AMD-Vi enabled in the BIOS. If your laptop is old it may not have that feature.I wondered about that - the laptop is VT-x, but not VT-d. But, as I run the above GUI machines on my laptop without VT-d, then shouldn't I be able to run Libreelec? Or, is it that I will just need the server/host setup with a gui? And, if that's the case, then perhaps I run Libreelec on the server/host and not as a VM and the rest as VM? Owncloud has been obsoleted by Nextcloud btw. Can't keep up - getting old... Many thanks Morgan. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen hypervisor on CentOS 7.4 with modern UEFI server not booting from grub
Hi Chris, For completeness just wanted to mention that it is the first time I see in newer servers that it is not possible to PXE boot from the network using legacy mode (BIOS). It seems like the NICs are missing the required piece of code for that as all 4 NICs of that server fail to boot legacy PXE with the following message: !PXE structure was not found in UNDI driver code segment. Best, J. On Wed, Jan 31, 2018 at 9:06 PM, Chris Adams wrote: > Once upon a time, John Naggets said: >> Jonathan brings it exactly to the point: we have to face UEFI because >> legacy mode is fading out, if I enable legacy mode I can't even boot >> anymore through the network (PXE) as these newer network cards can >> only boot PXE with UEFI. > > UEFI PXE is different than BIOS PXE and needs to download different > software from the TFTP server. I use syslinux for BIOS PXE, but it > doesn't seem to work with UEFI PXE so I use grub2 (I use the secure boot > shim from Fedora to support as many setups as practical). You can have > both available at the same time (takes a DHCP tweak). > > Just like the early days of BIOS PXE however, UEFI PXE clients don't > always seem to do the right thing. I have an Intel NUC (7th gen), and > it always fails with UEFI PXE. > > -- > Chris Adams > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
