On Mon, 17 Aug 2015, jfmxl wrote: > but no joy. When I rebooted the machine I saw the grub and a bunch of > initializations whizzed by ... but the kernel failed to mount root.
Sounds pretty much like grub is passing the wrong root parameter. > I opened a shell and looked at /etc/fstab, but found a /dev/ram0 and a > /proc and nothing like what I'd entered ... I'd followed the program in > the handbook. Would that be the rescue shell within the initramfs? In that case that's fine, I see the same thing in a genkernel initramfs. > When I tried to unmount the /mnt/gentoo (formerly) chroot partition at > the end the complaint was that something using it ... I couldn't > discover what that was, If you did mount --rbind on sys and dev and then tried to umount than I can tell you I always fail to unmount these properly. Rebooting (software reboot) is fine. > after waiting an retrying several times, I just > shut the vm down and restarted ... with the result above. Is there any > hope of rescuing this? Should be entirely salvageable. > Since I installed the whole system to a qemu 'partition' inside a binary file > I have no access to what I've done or failed to do. So I guess I'm just out of > luck? You can simply reboot the livecd within the VM and just go to the 'chroot` step. You could also mount the binary disk image on the host; depending on what type of image you're using the instructions are both here https://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host The only thing you're missing is the proper bootloader/initramfs configuration, so go back to this part. > To install an initramfs, install sys-kernel/genkernel first, then have it > generate an initramfs: > root #emerge genkernel > root #genkernel --install initramfs > > So yes, that's what I did, apparently. Without knowing the specifics of your setup, here's the steps I would take to fix it: 1. regenerate genkernel initramfs; you can try to specify a default real_root by executing genkernel --real-root, or in /etc/genkernel.conf. But it seems to me that if the correct root parameter from grub is passed then things should work. 2. grub2-mkconfig again; check the created grub.cfg to see that sane flags are being passed to the kernel. 3. try booting 4. if you don't have a freaky partition setup and the filesystem/block device controller modules are built-into the kernel, you can try to launch the kernel directly from grub-cmdline. Something like set root='hd0,2' linux /boot/vmlinuz-whatever root=/dev/sda4 boot should work (plug in the right partition numbers). This is actually what I would do, initramfs only as a last resort. if these don't work then you still have step 5: 5. generate a dracut initramfs and redo steps 2 and 3. Dracut can generate and save a kernel cmdline within itself which should fix any problems. > ... Ill give it another shot, but I won't stick around on this damn list any > longer. Seems pretty rash to run away after one email, don't you think?
