I have been learning Debian by using a virtual machine. After fine-tuning my installation procedure, I decided to copy that installation to my physical system. The hard drive already has another Linux based system installed. I plan to dual boot.

After copying files I updated fstab and menu.lst.

The partition scheme between the virtual and physical environments are similar, but the partitions are not mapped exactly the same.

Thus the Debian system on the physical hard drive fails to boot. I think the initrd created in the virtual machine is looking for the root file system on /dev/hda1 whereas on my physical drive the new location is /dev/sda7.

How can I rebuild the initrd on the physical system? Or how can I build an initrd in the virtual system that will function on the physical system.

I started to use the installation DVD in rescue mode, but I did not get too far.

Thanks again.

It's just a suggestion, but can't you boot a Linux system and chroot to /dev/sda7's mountpoint and run something like mkinitrd ?

Seems like a good idea. Unfortunately, /, /usr, and /var are on separate partitions. So I can chroot to the Debian / partition (/dev/sda7) but I don't know how to get /usr (dev/sda6) and /var (/dev/sda5) into the chroot environment. Possibly I need to get /dev manually populated and then I probably can manually mount the other two partitions?

try
mount -o bind /dev /media/sda7/dev
mount -t proc /proc /media/sda7/proc
mount -o bind /sys /media/sda7/sys
first, then mount /usr and /var and then chroot.

Thank you much j1alu. Very clever!

Original problem solved.

The problem was the initrd. The cure was modifying /etc/initramfs-tools/conf.d/driver-policy and then running update-initramfs -u -k all -v.

When I installed Debian to my virtual machine I selected the option to created a targeted/limited initrd for my (virtual) system. That decision resulted in the driver-policy configuration file establishing how to create subsequent initrds. By modifying the file from dep to most, I then created a more robust initrd that allowed me to boot on the physical system.

Without digging into details, I am reasonably sure the problem was a lack of support for SATA drives, which the virtual machine does not have.

Perhaps the update-initramfs script should list the current settings before creating a new initrd so users are modestly reminded of the current configuration options. Regardless, problem solved and lessons learned.