I've got a SUSE instance running on a Hyper-V (Win Server 2008 R2) host. Initial install was fine. After setting up Apache, MySQL, etc... I shut down the VM and snapshotted it (So I could revert if something went wrong).
After the snapshot, the system won't boot.
Specifically I get....
If I choose "no" (do not attempt to use ...-part1
), it dumps me to a prompt I'm unfamiliar with ($
). If I answer yes, it waits for -part1
for a few seconds, fails and drops me to the same prompt.
in either case, I get:
sh: cannot set terminal process group (-1): Inappropriate ioctl for device
sh: no job control on this shell
I seem to have an extremely limited toolset (presumably the build-in shell commands?)
If I do an ls -al /dev/disk/by-id
I get the following:
I'm not sure how to proceed - as far as I can see, the HDD is being recognised by the VM (Otherwise, I wouldn't get this far), but the Id of the partition(s) its looking for to mount is incorrect (Note that the Ids listed vary after the 20202020
part).
How can I either tell Linux to use the new Ids or (failing that), change the Ids to match what Linux is expecting?
Addendum: After more Googling, it seems this might be due to a problem upgrading. I did use YAST to install an "Important" update pre-reboot, so this might also be the cause. Of course, now I'm not 100% sure what version is running. cat /proc/version
results in:
It looks like your snapshotting changed the device ids. Maybe you unintentionally cloned the system? Anyhow, this should help:
At the grub menue (thats where you choose which OS/Kernel you boot, often it also has a rescue option), move the cursor to stop it from automatically continueing with the default optin. Then choose the default option and add
root=/dev/sda1
. Hit Enter, this should boot. On my system I could then log in as root (in text mode). Edit the files/boot/grub/menu.list
and/etc/fstab
, replacing each occurence ofdisk/by/id[...]-part
withsda
. This should get you device names like/dev/sda1
. Reboot, and everything should be fine. You might want to consider checking your grub2 config, so that a kernelupdate would not destroy your menu.lst.