'sudo iiab' reboot if any file/dir modified in /boot since boot [as /var/run/reboot-required and 'needrestart' command were NOT reliable]

[holta]

Proposed fix for situations like:

• WiFi Country Code confusion during IIAB installation [IIAB should check for mismatched kernel e.g. if apt updates were applied w/o reboot] iiab#2975

Also tidies up the PR below, using apt install perl to deal with "distro junkies" running anomalous OS's:

• PR Include 'yescrypt' among /etc/shadow hashing methods #183

Related:

• PR add kernel warning for RaspOS #133
• PR kernel check #189
• Implementers R Us: quick wins allowing rapid-fire installation by almost anyone iiab#1028

[holta]

@darkenvy @jvonau & All:

Just a clarificastion that some versions of Ubuntu and Debian (used to?) touch the files /var/run/reboot-required and /var/run/reboot-required.pkgs but this proved highly unreliable in my testing. Certainly Raspberry Pi OS does not support it.

Ubuntu and others are recently moving to use the needrestart command alongside apt so this seems far more wise. For several of these reasons, I went with the output of needrestart -b instead, which is a bit slower[*] but should be much more reliable/sustainable/supportable. Rather than a hacky/flaky (and hence much more costly) approach.

[*] Yes installing needstart and its 8-second runtime on Raspberry Pi 4 are annoying, but this serves to avoid implementers shooting themselves in the foot — in so many different ways (unattended-upgrades, spontaneous apt update of a kernel, booting weeks later, etc) — so it seems well worth the cost in the end.

RECAP: Reliability may be painfully boring but we all benefit from it down the road, so I believe we should go for it. Finally, while waiting 8+ sec during an RPi install is a bit annoying, this same code also offers a dramatic new speedup when a reboot due to kernel mismatch is not necessary. So again, this seems very much worth it overall. (Linux support is not at all pretty business, dealing with "distro junkies" of every different kind and all their eccentric demands, so we definitely need more rock-solid implementations to navigate this and avoid pulling our hair out ;-)

• Implementers R Us: quick wins allowing rapid-fire installation by almost anyone iiab#1028

[holta]

Uh-Oh! The needrestart -b command falsely claims Raspberry Pi OS always needs a reboot — due to its inability to make sense of the 4 kernel architectures included by this unique OS, as summarized 15 months ago and reconfirmed here:

root@raspberrypi:~# needrestart -b
NEEDRESTART-VER: 3.4
NEEDRESTART-KCUR: 5.10.17-v7l+
NEEDRESTART-KEXP: 5.10.60-v8+
NEEDRESTART-KSTA: 3
NEEDRESTART-UCSTA: 0
NEEDRESTART-SVC: dbus.service
NEEDRESTART-SVC: systemd-logind.service
NEEDRESTART-SVC: wpa_supplicant.service

root@raspberrypi:~# ls -l /boot/kernel*
-rwxr-xr-x 1 root root 6353624 Sep  2 20:15 /boot/kernel7.img
-rwxr-xr-x 1 root root 6779080 Sep  2 20:15 /boot/kernel7l.img
-rwxr-xr-x 1 root root 7904106 Sep  2 20:15 /boot/kernel8.img
-rwxr-xr-x 1 root root 6006608 Sep  2 20:15 /boot/kernel.img

So it looks like an entirely new strategy is...likely necessary.

This is unfortunate as the output of needrestart -v can be incredibly useful to assess kernels on any given Linux machine!

BUT it has its failings too — e.g. needrestart -b does not parse Ubuntu's /etc/grub/grub.cfg leading it to false conclusions on occasion — as on this pre-release Ubuntu Server 21.10:

root@u2110-srv:~# needrestart -b
NEEDRESTART-VER: 3.5
NEEDRESTART-KCUR: 5.11.0-20-generic
NEEDRESTART-KEXP: 5.13.0-14-generic
NEEDRESTART-KSTA: 3

root@u2110-srv:~# ls -l /boot/vmlinuz*
lrwxrwxrwx 1 root root       25 Aug 23 09:03 /boot/vmlinuz -> vmlinuz-5.13.0-14-generic
-rw------- 1 root root 14852032 Jun  8 13:59 /boot/vmlinuz-5.11.0-20-generic
-rw------- 1 root root 10296832 Aug  2 08:29 /boot/vmlinuz-5.13.0-14-generic
lrwxrwxrwx 1 root root       25 Jun 25 14:45 /boot/vmlinuz.old -> vmlinuz-5.11.0-20-generic

root@u2110-srv:~# grep vml /boot/grub/grub.cfg
        linux   /vmlinuz-5.11.0-20-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
                linux   /vmlinuz-5.11.0-20-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
                linux   /vmlinuz-5.11.0-20-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro recovery nomodeset dis_ucode_ldr

root@u2110-srv:~# uname -a
Linux u2110-srv 5.11.0-20-generic #21+21.10.1-Ubuntu SMP Wed Jun 9 15:08:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[jvonau]

if $(apt list --upgradable' | grep -q raspberrypi-kernel); then
needs_reboot=1
echo "display warning"
fi
then make the reboot conditional on needs_reboot?
might be less cumbersome than trying to make needrestart work.

[holta]

It's time to push this effort to the wider public for broader community testing.

Thank you @darkenvy and @jvonau for all the many contributions over the past several days that made this possible, and any ongoing insights in case further corner cases might have been missed.

FYI I've tested it quite carefully in eccentric conditions and it works very well — e.g. when apt has installed all sorts of things into /boot since the machine was booted — with my testing so far focused on these 3 systems especially:

1. 32-bit Raspberry Pi OS Lite on RPi 4
2. Ubuntu Server 21.10 VM
3. Debian 11 (server) VM

[holta]

FWIW I guess the variable name bootDirLastModFile isn't 100% accurate.

As a directory within /boot can also be modified — just like a file can be modified within /boot (either way forcing a reboot, if the modification happened since the machine was booted!)

But the above var name gets the idea across concisely — and seems good enough for now (:

[holta]

Postscript: If some nutcase wants to force a future timestamp onto anything /boot they can of course break this scheme.

The lack-of-RTC situation is handled well, as explained here:

iiab-factory/iiab

Lines 258 to 268 in fa75d23

	# 2021-09-03 #2975: Is a reboot needed? We check after reboot too, safeguarding
	# against users (or apt above, or unattended-upgrades) spontaneously AGAIN apt
	# updating /boot e.g. kernel AT ANYTIME -- also many weeks could have passed.
	bootupTime=$(($(date +%s) - $(cut -d. -f1 /proc/uptime))) # Seconds since...
	bootDirLastModFile=$(date +%s -r "/boot/$(ls -t /boot | head -1)") # 1970-01-01
	# Works w/o RTC (real-time clock, i.e. battery) because:
	# Both 'apt' installs to /boot and IIAB installs require Internet (e.g. NTP).
	if (( bootupTime < bootDirLastModFile )); then
	reboot
	exit 0 # Nec to avoid bogus continuation & misleading output below
	fi

So I'm not too worried about active sabotage. As long as 99.99% of regular users don't end up in a "reboot loop" when trying to install IIAB.

In any case: these are the kind of things to watch for — e.g. just in case any particularly weird distros or /boot-modifying behaviors show up in the wild, over future years.

[jvonau]

You know Ubuntu doesn't use /boot but rather /boot/firmware as the mount point for the first partition on ARM right? I don't see an issue using $(ls -t /boot | head -1) as apt mass updates the files present but really the focus is on /boot/vmlinuz, that I know is present on RasPiOS as a file and Ubuntu as a symlink. The unknown for me is Debian, but I suspect that /boot/vmlinuz is present also. If present on Debian consider using $(date +%s -r /boot/vmlinuz)

[jvonau]

Just thinking about Ubuntu where the initrd.img is generated on the machine locally, I've seen apt updates that regenerate the initrd.img without a newer kernel being installed which would require a reboot to load the new initrd.img. Maybe initrd.img would be a better target than vmlinuz.

[holta]

You know Ubuntu doesn't use /boot but rather /boot/firmware as the mount point for the first partition on ARM right?

I wasn't aware. So the key will be to watch that situation, making sure that the lastmod time changes on the dir /boot/firmware itself (i.e. when apt installs a new kernel in there).

FYI Debian 11 doesn't use /boot/vmlinuz but rather points to particular kernels.

Ubuntu 21.10 likewise. Even if /boot/vmlinuz exists, it ignores that and uses /boot/grub/grub.cfg to point to a particular kernel.

These are some of the reasons I (tried) hard to avoid getting involved with the many different (evolving) filename particulars within /boot. Hopefully this future-proof KISS strategy is more cross-platform, and will work out. But we will need to keep an eye on it for sure.

[holta]

You know Ubuntu doesn't use /boot but rather /boot/firmware as the mount point for the first partition on ARM right?

I wasn't aware. So the key will be to watch that situation, making sure that the lastmod time changes on the dir /boot/firmware itself (i.e. when apt installs a new kernel in there).

Worst case if Ubuntu-on-ARM does not modify the lastmod time on dir /boot/firmware then we should consider some kind of recursive ls -t that checks for the very most recently modified file, across all subdirs within /boot.

Not hard to do. Anyway something to keep in our back pocket, if nec!

[jvonau]

You know Ubuntu doesn't use /boot but rather /boot/firmware as the mount point for the first partition on ARM right?

I wasn't aware. So the key will be to watch that situation, making sure that the lastmod time changes on the dir /boot/firmware itself (i.e. when apt installs a new kernel in there).

If making a change to any file lets say cmdline.txt under /boot/firmware/ is suppose to update the time of /boot/firmware it does not.

FYI Debian 11 doesn't use /boot/vmlinuz but rather points to particular kernels.

As in that is really a symlink pointing to the real kernel or not present at all?

Ubuntu 21.10 likewise. Even if /boot/vmlinuz exists, it ignores that and uses /boot/grub/grub.cfg to point to a particular kernel.

Ubuntu doesn't really use /boot/vmlinuz either but link is changed to point to the latest kernel and the ARM platform is using uboot as the boot loader.

These are some of the reasons I (tried) hard to avoid getting involved with the many different (evolving) filename particulars within /boot. Hopefully this future-proof KISS strategy is more cross-platform, and will work out. But we will need to keep an eye on it for sure.

Might what to test on Ubuntu ARM.

[holta]

I wasn't aware. So the key will be to watch that situation, making sure that the lastmod time changes on the dir /boot/firmware itself (i.e. when apt installs a new kernel in there).

If making a change to any file lets say cmdline.txt under /boot/firmware/ is suppose to update the time of /boot/firmware it does not.

Indeed https://stackoverflow.com/a/3620704 says:

The mtime (modification time) on the directory itself changes when a file or a subdirectory is added, removed or renamed.

Modifying the contents of a file within the directory does not change the directory itself, nor does updating the modified
times of a file or a subdirectory. If you change the permissions on the directory, the ctime changes but the mtime does not.

So if indeed Ubuntu-on-ARM's apt adds unique new kernel-like files into /boot/firmware/, then this PR's current code already works.

FYI Debian 11 doesn't use /boot/vmlinuz but rather points to particular kernels.

As in that is really a symlink pointing to the real kernel or not present at all?

/boot/vmlinuz is not present at all.

[jvonau]

The whole reboot to avoid the kernel module mismatch in network is only really applicable to RasPiOS as they sort of misuse /lib/modules to support the 4 kernels offered.

pi@raspberrypi:/opt/iiab/iiab-factory $ ls /lib/modules
5.10.60+ 5.10.60-v7+ 5.10.60-v7l+ 5.10.60-v8+

The rest of the distros allow side by side kernels to exist and could be bootable because the modules are preserved within /lib/modules/

jv@desktop:~$ ls /lib/modules/
5.11.0-1015-raspi 5.11.0-1016-raspi 5.8.0-1006-raspi

[holta]

RasPiOS [...] sort of misuse /lib/modules to support the 4 kernels offered.

That is interesting.

The whole reboot to avoid the kernel module mismatch in network is only really applicable to RasPiOS

I'm not sure.

Forcing sloppy implementers to reboot their machine could be very wise and precautionary in other circumstances as well.

The rational would be: IIAB should not install if they (or apt, or unattended-upgrades, etc) are still fussing around making changes within /boot — much better to mandate a reboot across all these mysterious circumstances — which acts an insurance policy that IIAB really installs/works at that moment in time (i.e. with that set of kernel/firmware/grub/etc files as they stand within /boot, at that moment in time).

[jvonau]

I wasn't aware. So the key will be to watch that situation, making sure that the lastmod time changes on the dir /boot/firmware itself (i.e. when apt installs a new kernel in there).

If making a change to any file lets say cmdline.txt under /boot/firmware/ is suppose to update the time of /boot/firmware it does not.

Indeed https://stackoverflow.com/a/3620704 says:

The mtime (modification time) on the directory itself changes when a file or a subdirectory is added, removed or renamed.

Modifying the contents of a file within the directory does not change the directory itself, nor does updating the modified
times of a file or a subdirectory. If you change the permissions on the directory, the ctime changes but the mtime does not.

Um, not really, the first changed file is the trigger

jvonau@jvonau-desktop:~$ ls -lt /boot
total 88420
lrwxrwxrwx 1 root root       44 Sep  1 06:20 dtb -> dtbs/5.11.0-1016-raspi/./bcm2711-rpi-4-b.dtb
lrwxrwxrwx 1 root root       44 Sep  1 06:20 dtb-5.11.0-1016-raspi -> dtbs/5.11.0-1016-raspi/./bcm2711-rpi-4-b.dtb
-rw-r--r-- 1 root root 30412495 Sep  1 06:20 initrd.img-5.11.0-1016-raspi
lrwxrwxrwx 1 root root       44 Aug 25 23:25 dtb-5.11.0-1015-raspi -> dtbs/5.11.0-1015-raspi/./bcm2711-rpi-4-b.dtb
-rw-r--r-- 1 root root 30411457 Aug 25 23:25 initrd.img-5.11.0-1015-raspi
lrwxrwxrwx 1 root root       28 Aug 25 23:23 initrd.img -> initrd.img-5.11.0-1016-raspi
lrwxrwxrwx 1 root root       28 Aug 25 23:23 initrd.img.old -> initrd.img-5.11.0-1015-raspi
lrwxrwxrwx 1 root root       25 Aug 25 23:23 vmlinuz -> vmlinuz-5.11.0-1016-raspi
lrwxrwxrwx 1 root root       25 Aug 25 23:23 vmlinuz.old -> vmlinuz-5.11.0-1015-raspi
drwxr-xr-x 5 root root     4096 Aug 25 23:21 dtbs
drwxr-xr-x 2 root root     4096 Aug 25 19:14 grub
-rw-r--r-- 1 root root   233853 Jul 29 09:43 config-5.11.0-1016-raspi
-rw------- 1 root root  5114349 Jul 29 09:43 System.map-5.11.0-1016-raspi
-rw------- 1 root root  9521261 Jul 29 09:43 vmlinuz-5.11.0-1016-raspi
-rw-r--r-- 1 root root   233778 Jul 14 05:29 config-5.11.0-1015-raspi
-rw------- 1 root root  5101272 Jul 14 05:29 System.map-5.11.0-1015-raspi
-rw------- 1 root root  9471603 Jul 14 05:29 vmlinuz-5.11.0-1015-raspi
drwxr-xr-x 3 root root    16384 Dec 31  1969 firmware

when you use head -1

 ls -t /boot | head -1
dtb

So if indeed Ubuntu-on-ARM's apt adds unique new kernel-like files into /boot/firmware/, then this PR's current code already works.

The code never gets to /boot/firmware, but I don't think that matters.

FYI Debian 11 doesn't use /boot/vmlinuz but rather points to particular kernels.

As in that is really a symlink pointing to the real kernel or not present at all?

/boot/vmlinuz is not present at all.

Think code should be fine, it actually covers the regeneration of the initrd.img and there is duplication between /boot and /boot/firmware as these are different partitions anyway.

[jvonau]

RasPiOS [...] sort of misuse /lib/modules to support the 4 kernels offered.

That is interesting.

The whole reboot to avoid the kernel module mismatch in network is only really applicable to RasPiOS

I'm not sure.

Must not of recalled iiab/iiab#482, from a time before iiab #33 lived in git 8229bee

Forcing sloppy implementers to reboot their machine could be very wise and precautionary in other circumstances as well.

Sure major libraries being replaced should be a red flag for a reboot and the code does just that, reboot if any apt packages are updated.

The rational would be: IIAB should not install if they (or apt, or unattended-upgrades, etc) are still fussing around making changes within /boot — much better to mandate a reboot across all these mysterious circumstances — which acts an insurance policy that IIAB really installs/works at that moment in time (i.e. with that set of kernel/firmware/grub/etc files as they stand within /boot, at that moment in time).

What needed to be guarded against is 'short-cutters' on RasPiOS as the kernel has an unusual layout, think what is implemented should be good enough. Dealing with unattended-upgrades that might be running just as the user is starting the curl routine is problematic as that process should lock apt's database as the update is in progress, the user can receive message as such and stops the install. Forget where the lockfile lives off the top of my head, but should be pretty easy to pause the install while unattended-upgrades finishes up.

[holta]

Dealing with unattended-upgrades that might be running just as the user is starting the curl routine is problematic as that process should lock apt's database as the update is in progress, the user can receive message as such and stops the install. Forget where the lockfile lives off the top of my head, but should be pretty easy to pause the install while unattended-upgrades finishes up.

Great question.

Currently the output of apt -qq update is parsed for many such similar apt failures/situations:

iiab-factory/iiab

Line 234 in fa75d23

$APTPATH/apt -qq update > /tmp/apt.stdout 2> /tmp/apt.stderr || true # Overrides 'set -e'

But there's room for improvement for sure, as common pain points are identified.

[holta]

code does just that, reboot if any apt packages are updated

Clarif: 'sudo iiab' no longer does that.

Now it reboots only if any mod-since-boot is detected within /boot.

So this is an experiment to see if new IIAB community folk can avoid some of these very annoying reboots — during those first days/weeks after each OS ISO (distro image) is released — until apt inevitably mandates a kernel/bootloader/etc upgrade patch a few weeks later.

[jvonau]

I'll have to check the behavior in a builder environment where the 'kernel package installed by apt' might have later dates than what the host's own uptime calculation suggests when in the builder's chroot environment.

[jvonau]

I'll have to check the behavior in a builder environment where the 'kernel package installed by apt' might have later dates than what the host's own uptime calculation suggests when in the builder's chroot environment.

Circling around, https://github.com/iiab/iiab-factory/blob/master/iiab#L258-L268 prevents execution in any chroot build environment, could that be changed to:

if (( bootupTime < bootDirLastModFile )) && ! ($FAST); then
or
if (( bootupTime < bootDirLastModFile )) && ! ($MFABT); then

[holta]

if (( bootupTime < bootDirLastModFile )) && ! ($MFABT); then

The above might be plausible.

Whereas nudging testers to reboot is critical (among testers who generally use sudo iiab -f to set FAST=true).

Question: might there be another way to (auto-)detect a chroot environment? (Instead of manually using sudo iiab -F to set MFABT=true ?)

[jvonau]

Ready to write /etc/iiab/kiwix_catalog.json
Finished writing to /etc/iiab/kiwix_catalog.json
SUCCESSTraceback (most recent call last):
  File "/opt/admin/cmdsrv/scripts/get_oer2go_catalog", line 183, in <module>
    main()
  File "/opt/admin/cmdsrv/scripts/get_oer2go_catalog", line 85, in main
    err_num, err_str, oer2go_catalog = get_oer2go_cat()
  File "/opt/admin/cmdsrv/scripts/get_oer2go_catalog", line 157, in get_oer2go_cat
    url_handle = urllib.request.urlopen(adm.CONST.oer2go_cat_url)
  File "/usr/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.9/urllib/request.py", line 517, in open
    response = self._open(req, data)
  File "/usr/lib/python3.9/urllib/request.py", line 534, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "/usr/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.9/urllib/request.py", line 1375, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.9/urllib/request.py", line 1350, in do_open
    r = h.getresponse()
  File "/usr/lib/python3.9/http/client.py", line 1371, in getresponse
    response.begin()
  File "/usr/lib/python3.9/http/client.py", line 319, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.9/http/client.py", line 288, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
Getting the OER2Go/RACHEL Catalog Failed.
Please run iiab-get-oer2go-cat again later.
Waiting to run iiab-make-kiwix-lib.py
Now running iiab-make-kiwix-lib.py

Seems this one has been seen before when the upstream catalog is unavailable. Is that correct?

[INFO] [2021-11-16 15:31:52,792] kalite: Annotating content for language: en, channel: khan
This may take several minutes depending on system resources...

[INFO] [2021-11-16 15:31:56,217] kalite: Annotation complete for language: en, channel: khan
Running in chroot, ignoring command 'is-active'
STARTING BITTORRENT DOWNLOAD(S) for KA Lite...Please Monitor: http://box:9091

/usr/bin/iiab: line 496: transmission-remote: command not found

Given https://github.com/iiab/iiab/blob/master/vars/local_vars_min.yml#L293-L294 for a min install I take this as being expected? Now you don't get the nice summary at the end, just dropped to a prompt. Even if there is a summary the prompt for Y for the reboot at the end is not needed in the chroot, that could be conditional under ($MFABT) or ($FAST) if systemctl -q is-active transmission-daemon; then doesn't like matching is_active would is_enabled suffice here as that works correctly under a chroot? Guess that would depend on the intent of when to start the download pre-reboot or post reboot but the keyword enabled should point to the intention to use the client or not as set in local_vars.

[tim-moody]

Is this from /opt/iiab/iiab-admin-console/install?

[holta]

if systemctl -q is-active transmission-daemon; then doesn't like matching is_active [...] under a chroot

Is there an error message...or incorrect exit status from systemctl?

(Any idea why...this apparently behaves very differently under a chroot?)

[jvonau]

systemctl is-active transmission-daemon

Running in chroot, ignoring command 'is-active'

Out right refuses to run the command, just like it does with restart, start or anything running state related command, just the way it is.

systemctl is-enabled transmission-daemon

Failed to get unit file state for transmission-daemon.service: No such file or directory

This is what I would expect for something the is not installed vs the below installed service
systemctl is-enabled nginx

enabled

Is this from /opt/iiab/iiab-admin-console/install?

Yes, looks like during iiab-get-oer2go-cat. FWIW this has been working, think it's a transient issue with the web site.

[holta]

systemctl is-active transmission-daemon

Running in chroot, ignoring command 'is-active'

Out right refuses to run the command, just like it does with restart, start or anything running state related command, just the way it is.

systemctl is-enabled transmission-daemon

Failed to get unit file state for transmission-daemon.service: No such file or directory

This is what I would expect for something the is not installed vs the below installed service systemctl is-enabled nginx

enabled

Thanks much for explaining.

Can we consider using something like How do I tell I'm running in a chroot?

Example:

if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
  echo "We are chrooted!"
else
  echo "Business as usual"
fi

[jvonau]

root@jvonau-desktop:/# stat -c %d:%i /  
66306:2
root@jvonau-desktop:/# stat -c %d:%i /proc/1/root/.
45826:2

The 2 sides of the conditional test return different values, seems to be a reliable test. FWIW ischroot farther down the above url found in debianutils is installed on Ubuntu.

[jvonau]

apt-cache rdepends debianutils tells me both Debian and Ubuntu have bash pulling in debianutils so ischroot should be available out of the box on both distros.

[holta]

apt-cache rdepends debianutils tells me both Debian and Ubuntu have bash pulling in debianutils so ischroot should be available out of the box on both distros.

This looks very promising. FWIW on 32-bit Raspberry Pi OS Bullseye on RPi 4:

root@box:~# ischroot

root@box:~# echo $?
1

root@box:~# ischroot --help
Usage: ischroot [OPTION]
  -f, --default-false return false if detection fails
  -t, --default-true  return true if detection fails
  -V, --version       output version information and exit.
  -h, --help          display this help and exit.

root@box:~# ischroot --version
Debian ischroot, version 4.11Copyright (C) 2011 Aurelien Jarno
This is free software; see the GNU General Public License version 2
or later for copying conditions.  There is NO warranty.

[jvonau]

The '-f -t' options don't appear to work, I always see '0' returned for a chroot environment and '1' for a normal environment despite whether f or t was passed on the command line in either environment.