I’m using a backtrack Linux to recover a broken Ubuntu Linux, to fix this disastrous situation I’m using the Ubuntu Linux through chroot after mounting my /dev/sda1, where my Linux resides with:
linux-recovery:~# mkdir /mnt/test1
linux-recovery:~# mount /dev/sda1 /mnt/test1
linux-recovery:~# chroot /mnt/test1
I consequently needed to mount up the /proc and /dev partition inside the chroot environment.
Here is how I did it:
ubuntu:~# mount /proc
ubuntu:~# mount -a
Next I switched on on a different virtual console in the backtrack and to mount /dev issued the commands:
linux-recovery:~# mount --bind /dev /mnt/test1/dev
Now once again, I can use theapt-get inside the chroot to fix up the whole mess …
More helpful Articles
Tags: aNext, backtrack, backtrack linux, Bind, chroot, chroot environment, dev, devNow, disastrous situation, environment, Linux, mess, mkdir, mnt, mount dev, partition, proc, procubuntu, sda, situation, test, test1, Ubuntu, ubuntu linux
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Just a small update about Backtrack Linux which is no longer maintained.
Thanks to Lori for notifying me about this, below is the email I received from her:
I noticed you are linking to the Backtrack-Linux site on your page here: pc-freak.net/blog/tag/software/
I wanted to bring into your attention that Backtrack-Linux is no longer being maintained. It will be for the benefit of your users if you could update the link to kali.org
If you are doing so, it would also be helpful if you share (on this page) the free chapter from the book published here on Kali Linux and ethical hacking.
Thanks a lot,
LorisView CommentView Comment
Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
I suppose you could use either method mentioned below In host machine:View CommentView Comment
mount --bind /proc <chroot dir>/procand another syntax (in chroot environment):
mount -t proc none /procThey are both special file systems so they can be recreated any number of times (the bind mount method uses the exact same amount as the host system, whereas the other method uses a new mount). I've always seen the bind mount recommended in guides, so I'd use that. As far as I know, there is no real important difference. However, /dev is usually a tmpfs mount that is managed by udev, so it has to be the actual same file system as on the host machine. That means that you would need to use the bind mount method. If this chroot is going to be around for awhile, you can put these entries in /etc/fstab on the host system to simplify things.