chroot for grub recovering

chroot Ubuntu using a LiveCD [Excerpts adapted for my convenience]
First to know!
You can only chroot within the same architecture
also a 64 bit OS requires a 64 bit Live CD /DVD and the correspondent with a 32 bit architecture
Ctrl + Alt + T for use of a terminal emulation window
in other case you will become

failed to run command `/bin/bash`: exec format error

Only valid for a fakeRAID

If you have a fakeRAID1 use the disk mapper module:

sudo modprobe -q dm-mod

sudo modprobe -q dm-mirror

sudo /sbin/dmraid -ay

then list the partitions:

fdisk -l

fdisk /dev/dm-0

Or (depends on the liveCD)
fdisk /dev/mapper/nvidia_edabbdgc
------------------

sudo mkdir /mnt/myroot  

sudo mount /dev/mapper/nvidia_edabbdgc7 /mnt/myroot 

sudo mount /dev/mapper/nvidia_edabbdgc2 /mnt/myroot/boot 

sudo mount /dev/mapper/nvidia_edabbdgc8 /mnt/myroot/home  

In a fakeraid installation /dev/dm-1 ist the first partition 

• /dev/dm-7  the root partition (/dev/mapper/nvidia_edabbdgc7) 
• /dev/dm-2 the boot partition (separated partition) (/dev/mapper/nvidia_edabbdgc2) 
• /dev/dm-8 the home partition (separated partition) (/dev/mapper/nvidia_edabbdgc8)

------------------
To export the pseudo file system of Live CD to "your would be" root file system:
sudo mount ‐‐bind /dev /mnt/myroot/dev
sudo mount ‐‐bind /proc /mnt/myroot/proc
sudo mount ‐‐bind /sys /mnt/myroot/sys

   Note that
   # mount --bind /foo /bar
  works as expected! (/foo is rw)

================================= 

=================================
Another arguments for other distro
(/dev/mapper/nvidia_edabbdgc7 the root and boot and home directory) 
$ sudo passwd
...
$ su -
 .....
# mkdir /mnt/myroot
# mount /dev/mapper/nvidia_edabbdgc7 /mnt/myroot
# mount -t proc /proc /mnt/myroot/proc 
# mount --bind  /dev /mnt/myroot/dev 

# mount --bind  /sys /mnt/myroot/sys
# chroot /mnt/myroot/ 
==================================

================================== 

Change the root file system of live system to your hard disk installed root file system.
sudo chroot /mnt/myroot/ 
--------------------
Install GRUB Boot record in Master Boot record of the hard disk.
As example hard disk is /dev/dm-0  or
/dev/mapper/nvidia_edabbdgc
(Replace with your hard disk device name)
sudo grub-install /dev/mapper/nvidia_edabbdgc
Perhaps necessary before reboot:

sudo update-grub
Reboot the Live Ubuntu. Eject the CD.

=========================

Normal one disk (no fakeRAID)

fdisk -l

sudo fdisk /dev/sda
sudo mkdir /mnt/myroot  
sudo mount /dev/sda7 /mnt/myroot 

sudo mount /dev/sda2 /mnt/myroot/boot

sudo mount /dev/sda8 /mnt/myroot/home

where
/dev/sda7 is the root partition
/dev/sda2 the boot partition (separated partition) and
/dev/sda8 the home partition (separated partition)
--------------------
To export the pseudo file system of Live CD to "your would be" root file system:
sudo mount ‐‐bind /dev /mnt/myroot/dev
sudo mount ‐‐bind /proc /mnt/myroot/proc
sudo mount ‐‐bind /sys /mnt/myroot/sys

   Note that
   # mount --bind /foo /bar
  works as expected! (/foo is rw)

================================= 
=================================
Another arguments for other distro
(sda2 the root directory) 
Become root priviledges
$ sudo passwd
...
$ su -
 .....
# mkdir /mnt/myroot
# mount /dev/sda2 /mnt/myroot
# mount -t proc /proc /mnt/myroot/proc 
# mount --bind /dev /mnt/myroot/dev 

# mount --bind /sys /mnt/myroot/sys 
# chroot /mnt/myroot/ 
==================================
================================== 

Change the root file system of live system to the hard disk installed root file system.
sudo chroot /mnt/myroot/ 
Install GRUB Boot record in Master Boot record of your hard disk.
As example hard disk is sda
(Replace with your hard disk device name)
sudo grub-install /dev/sda

Perhaps necessary before reboot:

sudo update-grub
Perhaps is necessary to unmount the devices???

Reboot the Live Ubuntu. Eject the CD.

Source

A Rescue Example (warning!) Booting into a live CD is a great way to fix problems on a broken machine. But what if you need to do more than just edit a file or two.
Many times when you are fixing a machine, you need to chroot into it. Many of those times the programs you run (such as grub-install) will need the /proc, /dev, and /sys directories to be alive and well. This is when you need to use bind.
For this example, we will try to run "grub-install" to try to fix a machine who's grub didn't install properly.
You might notice, that when we bind /proc, /dev, and /sys, they do not show up when you do a "df". To see them you have to do a "mount" command.

# mount /dev/hda5 /mnt/hda5
# chroot /mnt/hda5/
[chroot]# grub-install /dev/hda
/dev/hda: Not found or not a block device.
[chroot]# exit
exit
# mount -o bind /proc /mnt/hda5/proc/
# mount -o bind /dev /mnt/hda5/dev/
# mount -o bind /sys /mnt/hda5/sys
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda3             9.5G  3.9G  5.1G  44% /
tmpfs                 311M     0  311M   0% /dev/shm
AFS                   8.6G     0  8.6G   0% /afs
/dev/hda1             9.7G  5.0G  4.2G  55% /mnt/hda1
/dev/hda5             9.5G  3.8G  5.3G  42% /mnt/hda5
# chroot /mnt/hda5
[chroot]# grub-install /dev/hda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

# this device map was generated by anaconda
(hd0)     /dev/hda
[chroot]# exit
exit
# 

=====================  ==================== 
Recuperar GRUB2

Cada partition tiene su uuid, al reformatear una partición suele cambiar.
Nombre asignado por linux a la partición de Windows:
sudo fdisk -l
Para ver el uuid de esta partición:

• vol_id (versiones antiguas de ubuntu)
• blkid.

sudo blkid /dev/sdaX Siendo la X el número de la partición de Windows.
Ahora solo toca comparar el uuid de nuestro fichero /boot/grub/grub.cfg con el que nos ha dado blkid.
sudo update-grub2
Información  grub2
Copiar (o mover) los ficheros del tipo "initrd.img-2.6.31-14-generic" y el "vmlinuz-2.6.31-14-generic" correspondiente a una carpeta creada dentro del mismo directorio "boot"  -*WTF??
sudo update-grub2
me ha generado un nuevo "grub.cfg" y las entradas del menú de arranque se me han quedado limitadas a:
"Ubuntu, Linux 2.6.31-17-generic"
"Ubuntu, Linux 2.6.31-17-generic (recovery mode)"
"Windows"
====================
Recuperar GRUB con el RescueCd

# mount -t ext3 /dev/sda1 /mnt/myroot

# mount -t proc proc /mnt/myroot/proc

# mount -t sysfs sys /mnt/myroot/sys

# mount -o bind /dev /mnt/myroot/dev

# chroot /mnt /bin/bash

- Suponiendo que grub esté instalado en el mbr:
# grub-mkconfig -o /mnt/boot/grub/grub.cfg
#reboot

============================== 

chroot guide 

=====================

Source

It is well known that --bind -o ro fails silently resulting in a mount
that is read and write rw
$ touch a
$ touch b
$ mount --bind -o ro a b
$ mount
<...snip...>
/home/tez/a on /home/tez/b type none (ro,bind)         # <---- Appears
as ro, but is rw
$ echo abc > b
$ cat a
abc
This is dangerous enough. However, it is totally insane to incorrectly
update mtab to indicate that a mount is ro when it is in fact rw so
that mount then reports bogus options.

This situation has now persisted for more than 18 months and is
undoubtedly resulting in security issues for some users.

----------------------

note that 
   # mount --bind /foo /bar
   # mount -o remount,ro /bar
works as expected (/foo is rw and /bar is ro). 

Source 

Most Linux and Unix file systems don't allow hard links to directories (except for the . and .. entries that mkdir creates itself). The reasons are are pretty obvious: you could really confuse programs like ls (ls -R), find and of course fsck if you created links that recursed back to themselves. If there was a compelling reason to allow directory hard links, you'd need to rewrite any program that wants to walk a file system tree to be aware of the possible problems..

So instead we have symlinks. You've probably used them for things like shifting around disk space or to give more convenient access to a directory. For example, Mac OS X creates /tmp as a symbolic link to "private/tmp". We use symlinks to make other directories visible under Apache's htdocs directory (though the same thing can be accomplished with Apache's configuration files).

One problem with symbolic links is that really they are just files. A special kind of file, yes, but a symlink only points at a directory - it doesn't act like one. So, for example, if you put a symlink to /xyz in a users home directory, and the user has write permission to his home (as he ordinarily would), he can remove your symlink. Nothing you can do with ordinary permissions can prevent that. You can do a "chattr +i" on your symlink, but because it is a symlink, that passes through to the actual directory, making it unusable. If you use "+u" (undeletable), that again passes through, and the user still can delete your symlink.

This can be extremely annoying, especially when users accidentally delete a symlink they need to have. Of course your real directory is still safe, but you need to recreate the symlink. In the mean time, your user is confused or maybe even broken.

There is at least one way around this. If the thing you want to link to is a mounted file system, you can use the "--bind" option of mount to create an unbreakable link.

If the thing to link to it isn't a separate fs, you can almost always make it be one.

Here's how it works. Let's say we have /dev/foo mounted at /foo and I want a "link" to that under /home/fred. All I have to do is:

mount --bind /foo /home/fred/foo

Fred can have full write permissions on /foo if he needs it, but he will not be able to remove /home/fred/foo. Not even root can:

# rm -rf /home/fred/foo
rm: cannot remove directory '/home/fred/foo': Device or resource busy

A warning

Do NOT use this just for silly convenience because you want "/etc" to be "/etcetera". See, for example, Yet another warning about mount --bind and rm -rf.

Use it for the things that make sense: putting a directory into a users home directory that refers to some shared resource that you always want them to have access to without having to cd somewhere. That's a place that makes perfect sense. Mounting a system filesystem somewhere probably does not.

Some related links you might find interesting:
lwn.net/Articles/159077/
linuxgazette.net/issue93/tag/2.html
====================   ====================

Read-only bind mounts

By Jonathan Corbet May 6, 2008

Bind mounts can be thought of as a sort of symbolic link at the filesystem level. Using mount --bind, it is possible to create a second mount point for an existing filesystem, making that filesystem visible at a different spot in the namespace. Bind mounts are thus useful for creating specific views of the filesystem namespace; one can, for example, create a bind mount which makes a piece of a filesystem visible within an environment which is otherwise closed off with chroot().

There is one constraint to be found with bind mounts as implemented in kernels through 2.6.25, though: they have the same mount options as the primary mount. So a command like:

    mount --bind -o ro /vital_data /untrusted_container/vital_data

will fail to make /vital_data read-only under /untrusted_container if it was mounted writable initially. On your editor's 2.6.25 system, the failure is silent - the bind mount will be made writable despite the read-only request and no error message will be generated (the mount man page does document that options cannot be changed).

There is clear value in the ability to make bind mounts read-only, though. Containers are one example: an administrator may wish to create a container in which processes may be running as root. It may be useful for that container to have access to filesystems on the host, but the container should not necessarily have write access to those filesystems. As of 2.6.26, this sort of configuration will be possible, thanks to the merging of the read-only bind mounts patches by Dave Hansen.

As it happens, it's still not possible to create a read-only bind mount with the command shown above; the read-only attribute can only be added with a remount operation afterward. So the necessary sequence is something like:

    mount --bind /vital_data /untrusted_container/vital_data
    mount -o remount,ro /untrusted_container/vital_data

This example raises an interesting question: what if some process opens a file for write access between the two mount operations? A system administrator has the right to expect that a read-only mount will, in fact, only be used for read operations. The 2.6.26 patch is designed to live up to that expectation, though the amount of work required turned out to be more than the developers might have expected.

Filesystems normally track which files are opened for write access, so an attempt to remount a filesystem read-only can be passed to the low-level filesystem code for approval. But the low-level filesystem knows nothing about bind mounts, which are implemented entirely within the virtual filesystem (VFS) layer. So making read-only access for bind mounts work requires that the VFS keep track of all files which have been opened for write access. Or, more precisely, the VFS really only needs to keep track of how many files are open for write access. Read more at source...