Loading dm-mem-cache.ko module Loading dm-region_hash.ko module Loading dm-message.ko module Loading dm-raid45.ko module device-mapper: dm-raid45: initialized v0.25941 Waiting for driver initialization. Scanning and configuring dmraid supported devices Trying to resume from /dev/vg00/lvol00 Unable to access resume device (/dev/vg00/lovl00) Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Settting up other filesystems. Setting up a new root fs setuproot: moving /dev/ failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not sycing: Attempted to kill init!
So here's the last section of the boot log before it panics, I've also tried with 'noresume' in the kernel options, and that gets rid of the resume device error. So it looks like something's wrong at mkrootdev step. Is there a way to debug what devicemapper is doing to tell if it's picking up the logical volumes correctly?
echo "Loading dm-raid45.ko module" stabilized --hash --interval 1000 /proc/scsi/scsi mkblkdevs echo Scanning and configuring dmraid supported devices resume /dev/vg00/lvol00 echo Creating root device. mkrootdev -t ext4 -o defaults,ro /dev/vg00/lvol01 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot
-- Wyatt Zacharias
On Mon, Nov 30, 2015 at 2:19 PM, Adam Thompson athompso@athompso.net wrote:
What's the partition type set to? 0xFD or 0x8E, by any chance? Should probably be 0x83 for /boot, 0x8e for the PV. Otherwise, start from scratch instead of trying to "fix" it and you'll find the problem faster. VM boots? Yes. Loads boot sector? Yes. Loads GRUB? Yes. Loads kernel? Yes. Loads initrd? Maybe... probably. Can pivot_root? Maybe... probably not. Can achieve multi-user runlevel? No.
So somewhere between loading initrd (which probably worked) and pivot'ing root (probably) lies your problem. Extract your initrd and trace through the behaviour one line at a time.
Better yet, examine what modules are baked into the original initrd (from the original physical server) and compare with the P2V'd list of modules.
The loading of dm_raid is harmless; your problem is LVM modules or detection somehow.
-Adam
On 15-11-30 01:25 PM, Wyatt Zacharias wrote:
So I'm attempting to virtualize one of our Redhat 5 boxes using VMWare's P2V functionality, and it's copied all the data into the VM without any trouble, but now I can't seem to get the virtual machine to boot because it's not detecting the virtualized partitions correctly. The physical system was using LVM on top of dm-raid to local disks. When VMWare virtualized the disks, it created a single disk, and copied the LVM layout onto it, so I think what's happening is on boot, the system is looking for the RAID disks and can't find them. When I try to boot it, it says that it can't find the logical volumes and goes into a kernel panic.
I've booted with a rescue disk, and when I run a pvscan on the new virtual disk, all the volumes are there and can be mounted, so the problem must be that the system isn't looking for the volumes in the right place. I've tried changing the root device to /dev/sda in the device.map comfig file, and I rebuilt the initrd file with both the --force-lvm-probe and --omit-raid-modules and it still loads dm-raid on boot.
So how do I get the system to completely forget about RAID, and boot off the new virtual disk? Is there a RAID config somewhere that I'm missing?
-- Wyatt Zacharias
Roundtable mailing listRoundtable@muug.mb.cahttp://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable