similar to: (EXT) CentOS Digest, Vol 162, Issue 29

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]

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

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

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

This problem still bites us. I've tried to play around with DHCP settings (rd.net.timeout.dhcp, rd.net.dhcp.retry) to no avail. I'm happy about /any/ hint. Cheers frank On 04/24/2017 11:57 PM, Frank Thommen wrote: > Hi, > > kickstarting fails due to problems with host resolution, even though the > network seems to be properly configured through DHCP. eno1 and eno2 are

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]

Yannis Milios wrote: > Suggestion: once it's up, rebuild the initramfs. >> > I tried that already, but still the same problem. > Aparently dracut does not want to activate the LVs required to boot to the > root filesystem, for some reason ... > At this point, I'd start wondering about the grub2 defaults, and the kernel command line. mark

Suggestion: once it's up, rebuild the initramfs. > > I tried that already, but still the same problem. Aparently dracut does not want to activate the LVs required to boot to the root filesystem, for some reason ... Yannis -- Sent from Gmail Mobile

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,

Finally, I was able to find a solution for this. I'm posting the result here, just in case that it's useful for someone else in the future ... The problem was not in initramfs (dracut), but on the fact that /dev/sda2 partition(PV), after I resized it, somehow got 2 partition table signatures. One was set as a "dos" partition with an offset "0x1fe" and second set as

I'm trying to set-up a ContOS 7 DomU server. I have used the PXE set-up images like I normally would for earlier versions of CentOS. Here is my config file:- name      = "centos7" memory    = 2048 disk      = ['phy:/dev/xen6/centos7,xvda,w' ] vif = [ 'mac=xx:xx:xx:xx:xx:xx' ] kernel    = "/root/xen/centos7-64/vmlinuz" ramdisk   =

Hi Everyone, I have a server that I recently applied all updates to to bring it to 1804. After rebooting the server, it would no longer boot and is instead dropping into a dracut shell. Here's a snippet of the output printed to the console (lines will likely wrap): [ 184.163787] dracut-initqueue[256]: Warning: dracut-initqueue timeout - starting timeout scripts [ 184.672525]

On Mon, Mar 20, 2017 at 10:18:35AM +0100, Daniel Pocock wrote: > >I migrated a CentOS7 VM (the fedrtc.org site) from an XCP environment to >a libvirt/KVM environment. > >This involved using qemu-img to convert the image from VHD to qcow2 and >then using virt-install --import to define the VM in libvirt. > I have little to no idea how to help with the rest, but have you tried

I migrated a CentOS7 VM (the fedrtc.org site) from an XCP environment to a libvirt/KVM environment. This involved using qemu-img to convert the image from VHD to qcow2 and then using virt-install --import to define the VM in libvirt. Three problems occurred during boot: a) on the first boot, the BIOS screen and grub screen don't appear at all, the screen is blank for a couple of seconds and

And when you did so, did you remove the "rd.shell" from GRUB_CMDLINE_LINUX > before? > > Yes, basically that option was not there by default, I added it during the troubleshootig steps. Normally, rd.lvm.lv=centos/root and rd.lvm.lv=centos/swap are the kernel parameters which are parsed to dracut for enablig the two LVs, but somehow dracut does not. I've copied the log from

I've install a CentOS Stream 9 system from a kickstart file that specified (among other things) several logical volumes: logvol / --fstype="ext4" --size=10240 --name=lv_root --vgname=VolGroup logvol /var --fstype="ext4" --size=4096 --name=lv_var --vgname=VolGroup logvol swap --fstype="swap" --size=2048 --name=lv_swap --vgname=VolGroup When that system rebooted,

On 1/9/22 15:37, Gordon Messmer wrote: > 1: The system also includes a volume group named "BackupGroup" and > that group activates on boot (post-dracut).? Why are those LVs > activated when rd.lvm.lv is specified? As far as I can tell, this is because in the dracut boot process, the device backing VolGroup is activated, but the device backing BackupGroup is not.? As a

Howdy, I hit a snag trying to install Xen4CentOS on a Supermicro based system (X9DRD-7LN4F with the Broadcom/LSI 2308 chipset). I spent a few hours on this today, I'm posting this here in case it helps anyone else and saves them the frustration I dealt with. On this system I did a fresh install of CentOS 7, updated it, rebooted it, then installed Xen. The system was booting fine using the

Hello after a lvm snapshot creation and a reboot are all logical volumes are missing, only swap is present. lvcreate -L 5000M -s -n centos_h1-root_snap /dev/mapper/centos_h1-root lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert centos_h1-root_snap centos_h1 swi-a-s--- 4,88g root 0,00 home

sorry: centos7 "fresh" minimal with a actual update cat proc/cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-229.20.1.el7.x86_64 root=/dev/mapper/centos_root ro rd.lvm.lv=centos/root rd.lvm.lv=centos/swap crashkernel=auto rhgb quiet LANG=de_DE.UTF-8 systemd.debug ls /dev/mapper: centos-swap control Zitat von Gordon Messmer <gordon.messmer at gmail.com>: > On 12/02/2015 11:09 AM,