similar to: CentOS-announce Digest, Vol 161, Issue 4

CentOS Errata and Bugfix Advisory 2018:2198 Upstream details at : https://access.redhat.com/errata/RHBA-2018:2198 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 95c2876aa8dd528ba7f788f27d7fdae5ea6e039c7714eae15330d741c0ec5316 kernel-3.10.0-862.9.1.el7.x86_64.rpm

Send CentOS mailing list submissions to centos at centos.org -----Original Message----- From: CentOS <centos-bounces at centos.org> On Behalf Of centos-request at centos.org Sent: Tuesday, July 31, 2018 5:30 PM To: centos at centos.org Subject: (EXT) CentOS Digest, Vol 162, Issue 29 Send CentOS mailing list submissions to centos at centos.org To subscribe or unsubscribe via the World

I'm attempting PCI-passthrough from host to guest on an HP ProLiant 380P, which has an outdated BIOS (2014), but it does support VT-d. I'm running CentOS 7, kernel 3.10.0-862.9.1.el7.x86_64. I have an Intel 82580 NIC installed with 4 ports. Each of these ports is in its own IOMMU group (I enabled SR-IOV at the BIOS, which might be the reason they show up separately) After detaching and

> > But, what happens if you let the kernel post install scripts do the work > or setting up the initrd things? Initially, I just rebooted from LiveCD and left Grub,kernel and dracut do their job with the defaults, but unfortunately, boot process stops at initrd (dracut) stage with the following error: [ 197.768159] localhost.localdomain dracut-initqueue[252]: Warning: Could > not

On 07/27/2018 11:51 AM, Quincy Wofford wrote: > I'm attempting PCI-passthrough from host to guest on an HP ProLiant > 380P, which has an outdated BIOS (2014), but it does support VT-d. I'm > running CentOS 7, kernel 3.10.0-862.9.1.el7.x86_64. > > I have an Intel 82580 NIC installed with 4 ports. Each of these ports is > in its own IOMMU group (I enabled SR-IOV at the

Yannis Milios wrote: >> But, what happens if you let the kernel post install scripts do the >> work or setting up the initrd things? > > Initially, I just rebooted from LiveCD and left Grub,kernel and dracut do > their job with the defaults, but unfortunately, boot process stops at > initrd (dracut) stage with the following error: > > [ 197.768159]

Hello, I'm having a strange problem booting a new centos7 installation. Below some background on this. [I have attached the tech details at the bottom of this message] I started a new CentOS7 installation on a VM, so far all good, o/s boots fine. Then I decided to increase VM disk size (initially was 10G) to 13G. Powered off the VM, increased the vhd via the hypervisor, booted from CentOS

Hi, > Hello, > > I'm having a strange problem booting a new centos7 installation. Below > some > background on this. [I have attached the tech details at the bottom of > this > message] > > I started a new CentOS7 installation on a VM, so far all good, o/s boots > fine. Then I decided to increase VM disk size (initially was 10G) to 13G. > Powered off the VM,

> Yannis Milios wrote: >>> But, what happens if you let the kernel post install scripts do the >>> work or setting up the initrd things? >> >> Initially, I just rebooted from LiveCD and left Grub,kernel and dracut >> do >> their job with the defaults, but unfortunately, boot process stops at >> initrd (dracut) stage with the following error:

http://bugzilla.mindrot.org/show_bug.cgi?id=161 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:30

From: Ard Biesheuvel <ardb at kernel.org> [ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ] Return -EINVAL for input sizes that are not a multiple of the AES block size, since they are not supported by our CBC chaining mode. While at it, remove the pr_err() that reports unsupported key sizes being used: we shouldn't spam the kernel log with that. Fixes: dbaf0624ffa5

From: Longpeng(Mike) <longpeng2 at huawei.com> commit d90ca42012db2863a9a30b564a2ace6016594bda upstream. The src/dst length is not aligned with AES_BLOCK_SIZE(which is 16) in some testcases in tcrypto.ko. For example, the src/dst length of one of cts(cbc(aes))'s testcase is 17, the crypto_virtio driver will set @src_data_len=16 but @dst_data_len=17 in this case and get a wrong at then

Send CentOS-announce mailing list submissions to centos-announce at 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-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Send CentOS-announce mailing list submissions to centos-announce at 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-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Dear List- This error is appearing in my log.winbindd log file. The full error is as follows: nsswitch/winbindd_user.c:winbindd_getpwnam(161) user 'RAID' does not exist nsswitch/winbindd_user.c:winbindd_getpwnam(161) user 'BAMBOO_LEAVES_SINGLE.TIF' does not exist To clarify, there is no user by those names (i.e. raid, BAMBOO_LEAVES_SINGLE.TIF) on our DC, but there are share

From: Longpeng(Mike) <longpeng2 at huawei.com> commit b02989f37fc5e865ceeee9070907e4493b3a21e2 upstream. The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by

From: Longpeng(Mike) <longpeng2 at huawei.com> commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee upstream. The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) +

Send CentOS-announce mailing list submissions to centos-announce at 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-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

After LLVM Weekly was removed from the LLVM blog, it's no longer accessible from LLVM.org. Shouldn't it be linked somewhere? For example, in the Useful Links section, right above the mailing list links. Or in the Site Map section, above the Blog link. On Mon, Jan 30, 2017 at 10:12 AM, Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote: > LLVM Weekly - #161, Jan 30th

Hello, I searched through the list archives for anything that appeared to be similar to this but I didn't find any good matches.? I apologize if this has been brought up before. Beginning with Dovecot 2.2.34, reported quota usage of a user's inbox can be doubled when the following criteria are met: 1) quota plugin is enabled 2) mailbox_list_index=yes 3) A sub-folder of the inbox