[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] resetting lost root password on a xen guest
On Tue, 30 Oct 2007, Liam Kirsher wrote: Steven, why do you write "being sure to fsck it afterwards" ? Is that important? I don't have much experience with Xen but I did see an error like you described below, and after making it a point to fsck domU file systems after I unmounted them from dom0 I haven't seen the problem again. Steve Timm The reason I ask is that I had a domU filesystem get corrupted, and I don't know how it happened. It was not all that important in that it was easy to recreate, being just my stock CentOS 5 template + bind. But, just the same, I'd like to know how it happened! Interestingly, Xen never had a problem creating the domU. However, my attempts to mount it (after shutting down the domU) failed because mount couldn't find a valid ext3 filesystem. Eventually I found a valid superblock, but virtually all the files ended up in lost+found. Steven Timm wrote:Darren--can you temporarily stop the xen guest and mount its root FS from dom0? if so, then just zero out the root passwd and shadow entry from there, unmount the client rootfs, being sure to fsck it afterwards, then start up the client again. Steve On Tue, 30 Oct 2007, Darren Jacobs wrote:Hi All, I need to get into a xenguest running linux for which the root password has been lost. I'm running xen 3.0.3 under RH 5. I'm trying to figure out how to get pygrub for this guest to load up the typical "init=/bin/sh" to get the console to come up at the command line prompt so I can reset the root password. Trolling though google I've see suggestions to add args = 'init=/bin/sh' or opts = 'init=/bin/sh' to the guest configuration file. None of them appeared to have worked. If I do a 'xen create echo11 -n' after making any of the above file mods I see that the args were not modified: -- (vm (name echo11) (memory 500) (on_reboot restart) (on_crash restart) (vcpus 1) (uuid cb855323-2867-b84a-d766-32a39d252bb7) (bootloader /usr/bin/pygrub) (image (linux (ramdisk /var/lib/xen/initrd.kIQYUw) (kernel /var/lib/xen/vmlinuz.Xwl81-) (args 'ro root=/dev/VolGroup00/LogVol00') ) ) (device (tap (uname tap:aio:/var/lib/xen/images/echo11) (dev xvda) (mode w)) ) (device (vif (bridge xenbr0) (mac 00:16:3e:69:69:90))) -- So I tried to bring the guest up manually from dom0 with " pygrub /var/lib/xen/images/echo11.dsk". When the menu comes up I edit the kernel line directly and insert "init=/bin/sh". You can see below that the init statement was indeed read: -- [root@dom0 xen]# pygrub /var/lib/xen/images/echo11 Going to boot Fedora (2.6.20-2925.13.fc7xen) kernel: /vmlinuz-2.6.20-2925.13.fc7xen initrd: /initrd-2.6.20-2925.13.fc7xen.img linux (kernel /var/lib/xen/vmlinuz.pBqWti)(ramdisk /var/lib/xen/initrd.9IdU7X)(args 'ro root=/dev/VolGroup00/LogVol00 init=/bin/bash') [root@dom0 xen]# -- However the guest did not start up :'( Its starts just fine if I issue a "xm create echo11". Any suggestions on where to look from here? -- ------------------------------------------------------------------ Steven C. Timm, Ph.D (630) 840-8525 timm@xxxxxxxx http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |