[SOLVED] A chroot expert in the mood to advise?

[Qqmike]

WTH ... at the risk--again--of acting stupid, I just have to ask. About chroot. Yeah, I've googled and read, in jail, outa jail, many times through the years. But I'm not expert enough to really get this.

Yet, I find it useful And I've used it by monkey-see-&-monkey-do. For example, re-installing GRUB to your root Kubuntu partition when the booting breaks. You can do this without chrooting, by simply mounting the root partition from a live CD. But you can not then also generate a new GRUB configuration boot file. You must exit your chroot, exit the live CD, re-boot into your OS, and fix the configuration file from within the OS.

For re-installing GRUB from a Live Kubuntu DVD ... This is the part I'm asking about, typically worded:
Mount the critical virtual filesystems:
/dev
/dev/pts
/proc
/sys
/run

... and to mount them using the bind option -B.

Now--thinking at the not-too-deep level of a Kubuntu how-to--for the purpose of using your Live Kubuntu DVD to do repairs (like re-install GRUB to your Kubuntu root filesystem),

(1) are those five "virtual" filesystems the filesystems and the only filesystems you should mount before chrooting? -- including newer systemd systems?; must you mount them all?
and
(2) the bind option -B: man mount says " ... the same contents is accessible in two places..."
What exactly does this mean in the present context?
and, finally,
(3) to exit the chroot, type exit, correct? What about ctrl-D, same thing? so first exit the chroot and then do the unmounting of all mounted filesystems: the Kubuntu root partition and those 5 virtual filesystems?

[verndog]

Here is the commands I've used in the past. I haven't the need for quite a while. I even used it in a script:

#!/bin/bash
## copy 7 commands below then paste:
sudo mount /dev/sdaX /mnt/
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt/ /bin/bash
=============
Remove CHROOT
=============
#!/bin/bash
## Ctrl+d to exit chroot,
## copy 6 commands below then paste.
sudo umount /mnt/etc/resolv.conf
sudo umount /mnt/dev/pts
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt

edit: _Of course the 'sdaX' needs to be a real partition.

Now I just boot with livecd of any variety and issue the following:

sudo mount -t ext4 /dev/sdaX /mnt
sudo grub-install --recheck --root-directory=/mnt /dev/sda

I have 'mbr' and not efi.

[Qqmike]

Except for your /etc/resolv.conf (used, I think, for graphical considerations) and my /run (no clue), they're about the same. I guess understanding it isn't too important, but I wish I did sort of understand it better. Looks like a few 'experts' write these recipes and they get around the Internet Help sections, but not much else said. For example, what exactly must you mount -B and what isn't necessary?, and a "why" would be nice. I've used a few different versions of this basic formula, and they all seemed to work (i.e., it did result in grub being fixed).

Thanks, verndog for looking.

[Qqmike]

Ok, I think I get this now, well enough for my application. The key is understanding --bind. And I see an experiment one could do (and I hope to find time to do) to find the minimal set of filesystems to bind for the chroot in Post #1). The chroot is no more than what it says it is, setting up a "root" environment under some directory. I think I'll mark this Solved, but if anyone wishes to add some more plain English, feel free.

(Btw, verndog, I think your /etc/resolv.conf is for DNS, not graphical support as I thought above.)

[SteveRiley]

Bind mounts: https://docs.1h.com/Bind_mounts

[Qqmike]

Yes, that's one I found, and a good one at that. Thanks.

[Qqmike]

GRUB-EFI re-install, chroot, commentary and questions

Well, I did explore this business of chrooting and bind-mounting. In the context of working from a live DVD/USB/CD to run a program (e.g., grub-install), the average user can understand it well enough [to be dangerous]. It's not that complicated.

As it turns out, this was the easy part of a project I'm working on: re-installing GRUB-EFI from a live DVD/USB using chroot. here, with some explanations:
Re-install GRUB2 from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017

How about using the live Kubuntu DVD/USB to re-install GRUB2-EFI by NOT using chroot? This should be easy, common sense, but the "easy" part may be the "hard" part of the experiment.

(This is where the question comes in ... )

I just finished the above, am still working on this stuff, but I did notice something either strange or interesting or perplexing (or maybe I'm just tired).

This: When trying to re-install GRUB-EFI (using grub-install) from a live DVD/USB, not by chrooting, but simply by mounting (which is the usual way we have done it with GRUB), the live UEFI-DVD/USB wasn't acting like it would do EFI GRUB work; it appeared to assume the GRUB re-install was for Legacy GRUB (grub-pc). I checked /usr/lib/grub (in the DVD/USB filesystem) and didn't find anything EFI as I expected I should find; however, check around the live DVD/USB session (in, e.g., /sys, /proc), and you'll find EFI stuff. I even found a Grub-installer, which is probably the executable used in the live Kubuntu installer DVD/USB to install GRUB (I didn't try to run it on my own, in my user space). The how-to's on the subject do not appear to address this issue with EFI. (The grub-install commands they use are for Legacy GRUB+BIOS, using a /dev/sdx[y] as a target for grub-install -- something you wouldn't do for GRUB-EFI; in fact, in the live DVD/USB session, I got the Legacy error message that I did not specify a device target for installation, indicating the live Kubuntu was expecting a GRUB Legacy re-install, not a GRUB-EFI re-install to an ESP). When you chroot into a damaged partition, you don't have this issue, as grub-install uses the GRUB-EFI files in the chrooted partition environment.

To be clear on this open issue:
Can you use a live Kubuntu installer UEFI-DVD/USB to re-install GRUB-EFI simply by mounting the damaged partition (i.e., NOT by chrooting into the damaged partition)?

I'm still working on this, somewhat casually, though. If you come across anything, or experiment, I'd be interested in what you know.


I do have some opinions about all this GRUB work I'm doing lately:

When possible, simply use Boot Repair to repair GRUB 2[-EFI].
https://help.ubuntu.com/community/Boot-Repair
http://sourceforge.net/p/boot-repair/home/Home/

Whatever your boot setup, install the boot manager rEFInd, even if it is done so alongside GRUB.
https://www.kubuntuforums.net/showth...l=1#post372221

When doing some of this repair yourself, anything can happen. I'm convinced that for some of this stuff, only someone like a kernel developer really knows what she/he's doing (e.g., with chroot, bind-mounts, fixing GRUB, virtual filesystems, and such). The rest of it is cookbook recipes that you hope will either work or not cause too much damage. For example, today, re-installing GRUB by chrooting, everything went well, it worked fine, but, somehow, I wiped out the firmware NVRAM variable for rEFInd, somehow--it was nowhere to be found, not even upon re-booting or using efibootmgr for a listing. (I simply re-installed rEFInd; but I'm sure you can cook up an efibootmgr command to register it again with the firmware, and I'm sure Rod Smith has written one for you.)

And, I'm not being negative. Just reporting some experiments. This stuff is fun.

[Qqmike]

Booted (again) using the 15.04 live USB, explored the installed programs, found only /usr/lib/grub/i386-pc files, modules, binaries. Nothing for grub-efi-amd64 (it is not installed--as shown also by Muon Package Manager, which I installed live).

This flash drive is 64-bit, it runs in UEFI mode, I used it to install 15.04 in UEFI mode along with the GRUB-EFI, grub-efi-amd64. Somewhere in the iso package there are the GRUB-EFI files.

So, in the 15.04 live environment (ditto for 14.04), it appears that only the GRUB legacy is available to use when making repairs by mounting a broken partition. When you install GRUB that way to a broken system, the GRUB files from the DVD are copied to the broken system: GRUB Legacy only. As I said above, the 14.04 & 15.04 live sessions do not recognize the GRUB-EFI commands.

Maybe an expert could somehow extract the GRUB-EFI files from the DVD filesystem in a live session and use them for rescue, but that is not how we have done this before, not how the average user would think to access the newer GRUB-EFI files for rescue purposes.

I conclude, so far, that if you use your live DVD/USB to re-install GRUB to a broken system, you can do so but you must chroot into the broken system partition (where you then have access to your Kubuntu GRUB-EFI files in its /usr/lib/grub).

[SteveRiley]

IIRC, the live images are missing efibootmgr. Without this, GRUB-EFI really can't fully complete its job.

[Qqmike]

Just for kicks, I booted with the UEFI live Kubuntu 14.04 USB and installed efibootmgr in the live session, which worked to enumerate the BootOrder, as it should. But its presence had no effect on the ability to mount a partition and re-install GRUB-EFI to that partition (using the mounted ESP, also). Basically, the live Kubuntu environment did not recognize the GRUB-EFI command, couldn't find --target=x86_64-efi, couldn't find modules in /use/lib/grub/x86_64-efi, basically nothing. It did indicate it was trying to install grub-pc (Legacy) but it needed a device target! Which, of course, indicates it is the wrong grub-install command for a UEFI installation.

Basically, unless I'm really overlooking something obvious, the live Kubuntu UEFI DVD/USB will not by itself install GRUB-EFI to a broken partition. The only way, it seems, is to chroot into the broken partition and use the UEFI resources that are already there (in the broken partition, like the EFI libraries and binaries). Nothing wrong with chrooting, except when helping a user on a forum do it -- and explaining it and risking that he/she might do very bad things as root in the mounted partition. Boot Repair to the rescue, I suppose. The devs must have a reason for building the live install media this way. Again, my little chrooting how-to on this is here, it's pretty simple, really, but you do have to do the details carefully, and you must not forget to mount (at /boot/efi) and point at your ESP, in addition to your Kubuntu root partition (if that's where your /boot/grub is):
https://www.kubuntuforums.net/showth...l=1#post374017

Again, if anyone hears or reads anything on this, please post it. Thanks.

[SteveRiley]

Do these Debian steps work in Ubuntu?

https://wiki.debian.org/GrubEFIReinstall

[Qqmike]

I saw that, and I would guess it would work with K(U)buntu. I should try that next as a little experiment. But ... they are cheating They are using a rEFInd CD, which I am sure Rod S. made right for the UEFI job. So, one could also use Boot Repair, which works with UEFI, and I'm sure there must be other ready-to-go UEFI rescue CDs. I was just curious what could be done a your handy live Kubuntu installation media for rescue, which is how I got into this issue. Thanks for the reminder, though. I've got Boot Repair, but I'd be curious what this rEFInd disk is all about.

[SteveRiley]

True. But there is this bit:

if you boot from a live media, you should start a chroot shell instead, as explained in https://help.ubuntu.com/community/Gr...ing#via_ChRoot

which summarizes as:

This method of installation uses the chroot command to gain access to the broken system's files. Once the chroot command is issued, the LiveCD treats the broken system's / as its own. Commands run in a chroot environment will affect the broken systems filesystems and not those of the LiveCD.

So here, the LiveCD is sort of "taking over." You would stop after step #11, and resume the steps in the Debian guide.

[Qqmike]

Hmm, the Debian link, the steps there ... interesting. He says you should create a chroot shell if booting by live media. But that is exactly what I did with the Kubuntu live media (either DVD or USB, both work fine). Doing this by chrooting works fine in Kubuntu, no issues.

His steps are familiar, but this one is a funny one:

grub-install /dev/sda

That's what K(U)buntu has been using for GRUB legacy (grub-pc).
For GRUB-EFI, you do not need to, nor should you, specify a device (dev/sda) for the
grub-install command (as we do for grub-install with BIOS systems). If it is the ESP, you should specify it this way:
grub-install --efi-directory=DIR
where DIR is the mount point for your ESP-- usually /dev/sda1 mounted at /boot/efi, for example; so if you are chrooted into your broken OS, you could simply write:
mount /dev/sda1 /boot/efi
grub-install --efi-directory=/boot/efi
But then that is the default for grub-install anyway, so you can omit it.
I would not write
grub-install /dev/sda
as the how-to shows, though. But apparently, it must work in Debian.
I may try this, play with it; but in a way, I already have done a lot of this stuff.

So, again, if you don't mind chrooting from live media, your Kubuntu DVD/USB already works fine.

[Qqmike]

We cross-posted!