[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] resetting lost root password on a xen guest


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Liam Kirsher <liamk@xxxxxxxxxxx>
  • Date: Tue, 30 Oct 2007 10:50:34 -0700
  • Delivery-date: Tue, 30 Oct 2007 10:56:26 -0700
  • Domainkey-signature: a=rsa-sha1; b=P6CqQaKYQ510YWnB1kJnPZuvhlHIjFjYUuLOpx+GRDEhayUFBxL/vXa97eZW83imp8Q0oiugx5XZPHTNSbnLt6Vcyl6PyZaEHVkOpkOx07sUBOX4oCpXFis/6J331Y+2BYA89+hlgBOouYrw5/+fDANL/jwTgJ52AI51DScqBD4=; c=nofws; d=numenet.com; q=dns; s=selector1
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Openpgp: id=7011F7B7; url=http://liam.numenet.com/pgp/

Steven, why do you write "being sure to fsck it afterwards" ? Is that
important?
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?
>>
>>
>>
>

-- 
Liam Kirsher
PGP: http://liam.numenet.com/pgp/


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.