search for: lsinitrd

...nd instead just wrapped the full message so I could see it I would have been a much happier person. Turns out dracut was unable to mount the root file system. So I went back into the 3.10 kernel again to see if the mpt2sas or mpt3sas driver was in its initramfs file... and it wasn't: $ sudo lsinitrd -k 4.9.25-27.el7.x86_64 | grep mpt -rw-r--r-- 1 root root 0 May 16 12:39 etc/fstab.empty -rw-r--r-- 1 root root 22 Nov 5 2016 usr/lib/kbd/unimaps/empty.uni For comparison: $ sudo lsinitrd -k 3.10.0-514.16.1.el7.x86_64 | grep mpt -rw-r--r-- 1 root root...

...acker build, to append "add_drivers+=" sd_mod" to /etc/dracut.conf and re-building initramdisk by running "dracut -f". However, it does not boot either (on ESXi)! I can still boot using Rescue mode on VMWare, then, I can see that sd_mod is inside of initramfs as expected (lsinitrd FTW) but, dracut does not load it! I tried "force_drivers+=" sd_mod", doesn't work too... Weird is that, while during Rescue, if I run "dracut -f" again, then, it works! Normal boot proceeds... But this is unacceptable, because I can not ship a half-broken VMDK and te...

On 05/16/2017 09:04 PM, Jerry wrote: <snip> > > Turns out dracut was unable to mount the root file system. So I went back > into the 3.10 kernel again to see if the mpt2sas or mpt3sas driver was in > its initramfs file... and it wasn't: > > > $ sudo lsinitrd -k 4.9.25-27.el7.x86_64 | grep mpt > -rw-r--r-- 1 root root 0 May 16 12:39 etc/fstab.empty > -rw-r--r-- 1 root root 22 Nov 5 2016 > usr/lib/kbd/unimaps/empty.uni > > For comparison: > > $ sudo lsinitrd -k 3.10.0-514.16.1.el7.x86_64 | grep mp...

...ry wrote: > <snip> > > > > Turns out dracut was unable to mount the root file system. So I went > back > > into the 3.10 kernel again to see if the mpt2sas or mpt3sas driver was in > > its initramfs file... and it wasn't: > > > > > > $ sudo lsinitrd -k 4.9.25-27.el7.x86_64 | grep mpt > > -rw-r--r-- 1 root root 0 May 16 12:39 etc/fstab.empty > > -rw-r--r-- 1 root root 22 Nov 5 2016 > > usr/lib/kbd/unimaps/empty.uni > > > > For comparison: > > > > $ sudo lsinitrd -k 3.1...

...partition. > > For that I had to use maxCount settings to trigger fsck. > > I believe e2fsk happens both pre root mount, and post. You'll want to > rebuild your initramfs to make it take effect for the root volume I'd guess. agreed as I see the config is included there: # lsinitrd | grep e2fsck -rw-r--r-- 1 root root 112 Mar 5 2015 etc/e2fsck.conf -rwxr-xr-x 3 root root 0 Jun 25 06:56 usr/sbin/e2fsck I have to wait for the next maintenance downtime to verify. I will report the result then. Thanks again for your help :) Cheers, Gabriele

Hi Gordon, my dracut package is the latest available for Centos7 (this occur just after my "yum update" and reboot). It is dracut-033-568.el7.x86_64 in CentOS Linux release 7.8.2003 (Core) I'm going to rebuild my initrd as suggested with the snapshot setup. Thanks for the links. Patrick Le 19/08/2020 ? 17:31, Gordon Messmer a ?crit?: > On 8/19/20 1:02 AM, Patrick B?gou wrote:

On 02/03/2016 06:33 PM, Martinx - ????? wrote: > What am I missing? Use lsinitrd to compare the two initrds. Direct each output to two files and then use "diff -u" to see the difference.

..."add_drivers+=" > sd_mod" to /etc/dracut.conf and re-building initramdisk by running > "dracut -f". However, it does not boot either (on ESXi)! > > I can still boot using Rescue mode on VMWare, then, I can see that > sd_mod is inside of initramfs as expected (lsinitrd FTW) but, dracut > does not load it! I tried "force_drivers+=" sd_mod", doesn't work > too... > > Weird is that, while during Rescue, if I run "dracut -f" again, then, > it works! Normal boot proceeds... But this is unacceptable, because I > can not sh...

On Tue, 26 Jul 2016 16:21:00 +0100 (BST) John Hodrien <J.H.Hodrien at leeds.ac.uk> wrote: > On Tue, 26 Jul 2016, Gabriele Pohl wrote: > > > on all of my CentOS7 VMs on different hypervisors > > the config file e2fsck.conf contains the line > > > > broken_system_clock = 1 > > > > Do you see similiar /default/ settings on > > your machines? Is

yes the error is still the .90 I looked back, everything was working Friday... I did a yum update on Friday but did not reboot. I rebooted this morning and I have the issue. The kernel package before was NOT the 693.5.2 it was 692.2.2 Does that help at all ? my kernel is not yet supported or something ? Jerry On Mon, Nov 6, 2017 at 12:36 PM, Jerry Geis <jerry.geis at gmail.com> wrote:

On 11/15/2017 07:50 PM, Gordon Messmer wrote: > On 11/15/2017 10:35 AM, Frank Thommen wrote: >> >> I tried with the files >> /etc/modprobe.d/blacklist >> /etc/modprobe.d/blacklist.conf >> and with entries >> blacklist mlx5_core >> blacklist mlx5_ib > > The "blacklist" entries prevent a module being loaded by its alias >

I have NOUVEAU driver disabled however its "showing" in my X log file. [ 140.086] (II) NVIDIA dlloader X Driver 390.59 Wed May 9 21:30:06 PDT 2018 [ 140.086] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs [ 140.086] (II) NOUVEAU driver [ 140.087] (II) NOUVEAU driver for NVIDIA chipset families : [ 140.087] RIVA TNT (NV04) [ 140.087] RIVA TNT2

Hey all, I've just pushed out the initial Nouveau support for $subject \o/ As the atomic modesetting transition is basically a rewrite of the KMS portion of the driver, I would be very grateful for any additional testing that people could provide (even as simple as just booting and making sure you get a display is valuable). There's a Linux tree at

https://bugs.freedesktop.org/show_bug.cgi?id=92307 Bug ID: 92307 Summary: NV50: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]() Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW