chroot question [SOLVED]

Questions about applications and software
Forum rules
Before you post please read how to get help
Post Reply
User avatar
Flemur
Level 18
Level 18
Posts: 8609
Joined: Mon Aug 20, 2012 9:41 pm
Location: Potemkin Village

chroot question [SOLVED]

Post by Flemur »

I wanted to see if I could "do stuff" on my Mint 20 install while logged into a graphical session on my Ubuntu 18 install, using chroot rather than booting Mint 20 since that would take a few valuable seconds.

Following the arch wiki on chroot wiki.archlinux.org/index.php/Chroot I did

Code: Select all

$ su - 
# mount /mnt/MT20
(fstab line = [c]LABEL=MT20  /mnt/MT20  ext4 defaults,noauto,user,noatime   0 2)[/c]
# cd /mnt/MT20
# mount -t proc /proc proc/
# mount --rbind /sys sys/
# mount --rbind /dev dev/
# chroot /mnt/MT20 /bin/bash
chroot: failed to run command ‘/bin/bash’: Permission denied
# mount -o remount,exec /mnt/MT20
# chroot /mnt/MT20 /bin/bash
# pwd 
/
# ls  [returned the files under Mint 20's normal "/" ]
# dpkg -l "*wine*" | grep ^ii
(returned the Mint 20 wine files, which are different than the ones on Ubuntu)
#
# synaptic
No protocol specified
Unable to init server: Could not connect: Connection refused
Failed to initialize GTK.
Probably you're running Synaptic on Wayland with root permission.
Please restart your session without Wayland, or run Synaptic without root permission
#
# xfce4-terminal
No protocol specified
Unable to init server: Could not connect: Connection refused
(xfce4-terminal:3880): Gtk-WARNING **: 11:06:13.470: cannot open display: :0.0
#
Q1: Can I do "everything!" that's doable from a terminal that was started in ubuntu, like install software with apt and dpkg? Any "gotchas"?

Edit - Thanks AndyMH and rene!
Edit - A1: Pretty much, and no.

Q2: A quick internet search indicates that you can't run GUI programs in chroot - is that correct?
Edit - A2: Perhaps you can. I'll try rene's suggestion.

Edit Q3: When I exit chroot, and type exit until the terminal disappears, then open another terminal and then

Code: Select all

# umount /mnt/MT20
umount: /mnt/MT20: target is busy.
How to make it not busy? lsof doesn't return any MT20 files....

Edit - A3: probably because of mounting /proc, etc.
Last edited by Flemur on Mon Aug 03, 2020 4:11 pm, edited 1 time in total.
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
User avatar
AndyMH
Level 13
Level 13
Posts: 4511
Joined: Fri Mar 04, 2016 5:23 pm
Location: Wiltshire

Re: chroot question

Post by AndyMH »

Can't help with much of it, never tried a GUI program on chroot, but on Q3 had a similar but different problem - couldn't delete the system I'd built under chroot without a reboot. Found out I had /sys and a couple of others mounted inside the chroot. Something inside /mnt/MT20 is still mounted. Do a df to find out what it is. Once I knew what it was, I amended my build scripts.
Homebrew i5-8400+GTX1080 Cinnamon 19.0, 3 x Thinkpad T430 Cinnamon 19.0, i7-3632 , i5-3320, i5-3210, Thinkpad T60 19.0 Mate
rene
Level 16
Level 16
Posts: 6681
Joined: Sun Mar 27, 2016 6:58 pm

Re: chroot question

Post by rene »

A1: Not that I can think of. Believe you'd need to get creative to find something not work right.

A2: Running GUI programs will actually be possible, certainly if your user on Ubuntu and Mint is the same, i.e., same UID and (maybe, probably not necessary) name. The issue is that you on your "host" OS run the X server as said user, so (unless you want to arrange for specific X11 authorization, also possible, but it's been so long I'd need to dig up how) what you want to do is is within the chroot additionally "chuser" to your user. I.e., if said user would be flemur you'd inside of the chroot say

Code: Select all

sudo -u flemur -i
and should then likely be able to open up e.g. xed or what have you without issue. Can again not really think of many gotcha's; you're chrooted after all, so dire consequences seem unlikely.

Both for A1 and A2 take me not being able to think of issues for what that's worth: I haven't extensive experience playing around with chroots or containers or the like.

A3: That I believe can be more of an issue. It seems to be /mnt/MT20/dev that is kept busy even if you manually unmount /mnt/MT20/{proc,sys,dev/pts} and even if you use simple --bind rather than --rbind. Although not in the situation of doing this from Ubuntu I just tried for a bit and whatever I do it seems the chroot's /dev directory is kept busy by some part of systemd vulturing down upon it as soon as it appears. Have not managed yet...
rene
Level 16
Level 16
Posts: 6681
Joined: Sun Mar 27, 2016 6:58 pm

Re: chroot question

Post by rene »

rene wrote:
Mon Aug 03, 2020 3:28 pm
A3: [ ... ] Have not managed yet...
It's D-Bus. I.e.,

Code: Select all

$ sudo -i
# mount /dev/<mint> /mnt
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# mount --bind /dev /mnt/dev
# mount --bind /dev/pts /mnt/dev/pts
# chroot /mnt
# sudo -u rene -i
$ xed
<close it again>
# exit
# exit
# ps ax
<identify the by eventually xed lauched copy of dbus-launch>
# kill <said copy of dbus-launch>
# umount /mnt/dev/pts
# umount /mnt/dev
# umount /mnt/sys
# umount /mnt/proc
... works well. As to automating killing the dbus-launch thing... I believe you can look in the chroot /home/flemur/.dbus for a PID. Not sure, would need to test again.
User avatar
Flemur
Level 18
Level 18
Posts: 8609
Joined: Mon Aug 20, 2012 9:41 pm
Location: Potemkin Village

Re: chroot question

Post by Flemur »

rene wrote:
Mon Aug 03, 2020 3:55 pm
... works well. As to automating killing the dbus-launch thing... I believe you can look in the chroot /home/flemur/.dbus for a PID. Not sure, would need to test again.
After all the chroot stuff in the OP, I did

Code: Select all

sudo -u username -i
and could start thunar and a terminal, but on the rooted system

Code: Select all

$ sudo synaptic
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
and also (after sudo -u username -i)

Code: Select all

$ whoami
username
/ : su -
Password: 
su: Authentication failure
$ sudo synaptic
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
and, as root,

Code: Select all

# umount /proc
umount: /proc: target is busy.
...same for /sys and /dev
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
rene
Level 16
Level 16
Posts: 6681
Joined: Sun Mar 27, 2016 6:58 pm

Re: chroot question

Post by rene »

Flemur wrote:
Mon Aug 03, 2020 4:26 pm

Code: Select all

$ sudo synaptic
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
Quite. You in your fstab line have "user" which option implies "noexec, nosuid, and nodev" (see man mount). You already remounted "exec" but if you want to keep that "user" option it should be "user,exec,suid,dev".

At that point though you will undoubtedly run into a subsequent problem regarding authorization on the (host) X server. For native access it's arranged through .Xauthority files to (mostly) Just Work but you will in this case either have to explicitly provide an .Xauthority cookie from some host-specific place, or it will probably work if you as your user do simply xhost + (inside the chroot, or supposedly before even entering it) so as to stop the X server from complaining.

Those two together probably make it work.
Flemur wrote:
Mon Aug 03, 2020 4:26 pm
and, as root,

Code: Select all

# umount /proc
umount: /proc: target is busy.
...same for /sys and /dev
Certainly. You need to unmount the bound instances. I.e., after having left the chroot, as root on the host system that is,

Code: Select all

umount /mnt/MT20/proc
and same for sys and dev --- in which case I note that you may need to unmount /mnt/MT20/dev/pts before /mnt/MT20/dev itself, and same for anything else that got mounted under /mnt/MT20/dev as a result of that --rbind that you use (it's probably only dev/pts, but check from the output of mount on the host system).
User avatar
Flemur
Level 18
Level 18
Posts: 8609
Joined: Mon Aug 20, 2012 9:41 pm
Location: Potemkin Village

Re: chroot question

Post by Flemur »

rene wrote:
Mon Aug 03, 2020 5:16 pm
You already remounted "exec" but if you want to keep that "user" option it should be "user,exec,suid,dev".
That didn't seem to make a difference.
...
Certainly. You need to unmount the bound instances. I.e., after having left the chroot, as root on the host system that is,

Code: Select all

umount /mnt/MT20/proc
and same for sys and dev --- in which case I note that you may need to unmount /mnt/MT20/dev/pts before /mnt/MT20/dev itself, and same for anything else that got mounted under /mnt/MT20/dev as a result of that --rbind that you use (it's probably only dev/pts, but check from the output of mount on the host system).
First time I tried those umounts before exiting chroot, but it makes sense to exit first since they were mounted first; after exiting the chroot but still as root, I got

Code: Select all

# umount /mnt/MT20/dev/pts 
umount: /mnt/MT20/dev/pts: target is busy.
#
# umount /mnt/MT20/proc
# 
# umount /mnt/MT20/sys
umount: /mnt/MT20/sys: target is busy.
(same for dev)
but that's OK, the main and only real problem is solved, namely chroot-ing and running the apt/dpkg programs.

Thanks again for the help and info!
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
rene
Level 16
Level 16
Posts: 6681
Joined: Sun Mar 27, 2016 6:58 pm

Re: chroot question

Post by rene »

Flemur wrote:
Mon Aug 03, 2020 6:22 pm
That didn't seem to make a difference.
I know you are/seem done with this, but thing is that I took the opportunity to in fact install Ubuntu 20.04 onto an external drive and have by now booted it and explicitly tested the above: it's all working fine.

If "no difference" includes sudo complaining about not being to suid then certainly the "user" thing implying "nosuid" is the culprit there. I'd try simply mounting from the command line as sudo mount LABEL=MT20 /mnt/MT20.

Together with as "rene" xhost +, sudo synaptic works fine from a Mint 19.3 chroot. OK, I know you there have conversely Ubuntu 18.04 and Mint 20 but that shouldn't be a difference. Also the unmounting stuff is fine here, of course after leaving the chroot and in the dev case as said killing the dbus-launch process that was started from inside the chroot.

Never mind if not interested any more, but this was technically interesting so slightly unsatisfying if left hanging :)
linux-rox
Level 4
Level 4
Posts: 395
Joined: Sun Jul 19, 2020 9:17 pm

Re: chroot question

Post by linux-rox »

rene wrote:
Mon Aug 03, 2020 5:16 pm
Certainly. You need to unmount the bound instances
Let's say, that's the usual way. :) ArchWiki mentions another I've not run into before. Turns out, it also works: sudo umount --recursive /mnt (i.e., whatever the chroot mount point). Or, per umount man page, can use -R, i.e., sudo umount -R /mnt. FWIW, I generally do the bind mounts in one line: for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done. Same effect as doing them separately, just faster and easier.

Also, maybe I don't understand the issue, as I've never tried to run GUI apps in chroot, but the ArchWiki procedure seemed to work fine. Opened Synaptic for Mint even though running chroot from Ubuntu, able to remove a package, and indeed package gone when boot into Mint.
rene
Level 16
Level 16
Posts: 6681
Joined: Sun Mar 27, 2016 6:58 pm

Re: chroot question

Post by rene »

linux-rox wrote:
Tue Aug 04, 2020 6:16 pm
Also, maybe I don't understand the issue, as I've never tried to run GUI apps in chroot, but the ArchWiki procedure seemed to work fine.
Yes, he had mounted the Mint 20 partition nosuid which is to say that sudo failed: it being a setuid executable is exactly from where it derives its power. After that indeed the above xhost + or as per that Arch link xhost +local: has all well. Hadn't seen the umount --recursive before; handy.
Post Reply

Return to “Software & Applications”