Upgrading 8.0 to 8.1 fails: "find: illegal option -- t"

P

PF92_

I'm trying to upgrade FreeBSD 8.0 to 8.1. I'm following instructions from the 8.1 release announcement. When I run freebsd-update upgrade -r 8.1-RELEASE, it asks some questions, shows some diffs of configuration files and at the end it shows a list of files that will be updated. The command returns exit code 0 and so far there are no errors. But then I run:

Code: 
[root@localhost ~]# freebsd-update install
Installing updates...find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e
find: f: No such file or directory

Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

The kernel in /boot/kernel is still 8.0, it hasn't been upgraded. /boot/kernel.old is an almost empty directory with only .freebsd-update file inside.

At this point, when I run /usr/sbin/freebsd-update install, it completes without errors and the userland is upgraded to 8.1, but the resulting system is a mix of 8.0 kernel and 8.1 userland.
 
SirDice said:
Both are seriously outdated (FreeBSD 8.1 has been EoL for ~13 years now). I suggest doing a clean install with a supported version.
Click to expand...
I know that. I could delete this old installation, but I want to experiment with upgrading it. If it can't be upgraded by 1 minor release, then I doubt any other upgrade path will work.
 
Don't recommend doing the upgrade all the way to 14.x anyway, too big of a difference. I suspect this system still uses the old partitioning scheme too, so you're very likely going to run out of disk space at some point. Just wipe it, and do a clean install of a supported version.
 
SirDice said:
Don't recommend doing the upgrade all the way to 14.x anyway, too big of a difference. I suspect this system still uses the old partitioning scheme too, so you're very likely going to run out of disk space at some point. Just wipe it, and do a clean install of a supported version.
Click to expand...
You're right that disk space could be an issue after some upgrades are done, but on this system I don't use an old partitioning scheme. I have root on ZFS (with compression on) and /boot on UFS. I can enlarge them both easily when needed.

As for the upgrade, there are a few things I'm going to try when I have more time:
1) Start the upgrade with freebsd-update fetch and freebsd-update install, before running freebsd-update upgrade ..., and see if it makes a difference (commands taken from installation instructions of FreeBSD 9.0 and later).
2) Check if FreeBSD 8.1 installation CD can be used to do an upgrade, although it's unlikely to work with my filesystem setup.
3) Do a source upgrade, although it will probably take a lot of time.
3) When freebsd-update fails to update the kernel, extract the new kernel manually into /boot/kernel, reboot and continue freebsd-update normally.
4) Edit /usr/sbin/freebsd-update and try to debug its use of find command.
 
PF92_ said:
When freebsd-update fails to update the kernel, extract the new kernel manually into /boot/kernel, reboot and continue freebsd-update normally.
Click to expand...
Kernel not getting upgraded might be because it's a custom kernel, not GENERIC.
 
SirDice said:
Kernel not getting upgraded might be because it's a custom kernel, not GENERIC.
Click to expand...
It is the "GENERIC" kernel:

Code: 
[root@localhost ~]# uname -i
GENERIC
[root@localhost ~]# uname -v
FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 
That's strange as the first freebsd-update install (with a minor/major version upgrade) updates the kernel.

You mentioned ZFS, does this system perhaps have a separate /boot partition?
 
find is only used for backup-ing kernel dir (in 8.0)
if kernel dir is somehow badly detected and ends up as unset you will get that error
 
Make sure that GNU find is not first in $PATH.

Apparently `find [...] -type f` is the problem here, which is odd. That is a basic option that should be supported in all finds.
 
Based on your replies I think that /usr/sbin/freebsd-update (or another shell script if it runs any):
1) uses find with variables not enclosed in double quotes and without checking their sanity
2) doesn't set a variable that should be set to /boot/kernel

I don't have GNU find on this system, only FreeBSD find, and the error messages can be reproduced like this:

Code: 
[root@localhost ~]# dir=""
[root@localhost ~]# find "$dir" -type f
find: ftsopen: No such file or directory
[root@localhost ~]# find $dir -type f
find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e
find: f: No such file or directory

/boot is a separate partition using UFS, so almost any version of GRUB 2 can boot this system whether it can read from ZFS or not.
 
PF92_ said:
/boot is a separate partition using UFS
Click to expand...
Once the system is booted it has probably been overlayed with the /boot directory on ZFS. That's where the kernel has been updated, the underlying UFS /boot is probably never touched and still contains the 'old' kernel. As that's where it boots from it keeps loading the 'old' kernel.

Seriously, just wipe it and reinstall. You can spend days trying to figure this out, or spend a couple of minutes to reinstall.
 
SirDice said:
Once the system is booted it has probably been overlayed with the /boot directory on ZFS. That's where the kernel has been updated, the underlying UFS /boot is probably never touched and still contains the 'old' kernel. As that's where it boots from it keeps loading the 'old' kernel.
Click to expand...
Perhaps creating an extra ZFS filesystem with mountpoint=/boot could cause the result you describe, but I didn't make this mistake.

covacat said:
try
KERNELDIR=/boot/kernel/ freebsd-update install
Click to expand...
This still doesn't work, the errors are the same, but you are on the right track with KERNELDIR. freebsd-update seems to be setting it to an empty string based on the sysctl "kern.bootfile". On my system its value is /kernel. I'll try if running sysctl kern.bootfile=/boot/kernel/kernel helps.
 
it should
here is the problem
sh: 
    BOOTFILE=`sysctl -n kern.bootfile`
    KERNELDIR=${BOOTFILE%/kernel}
    if ! [ -d ${KERNELDIR} ]; then
        echo "Cannot identify running kernel"
        exit 1
    fi
so KERNELDIR will be an empty string
now comes the weird thing on how [ operator works
Code: 
[09:39:37] [ns!titus]~ $A="";[ -d $A ] || echo error
[09:41:44] [ns!titus]~ $[ -d "" ] || echo error
error
so because of this the code fails to detect a borked kernel dir
 
covacat said:
it should
here is the problem
sh: 
    BOOTFILE=`sysctl -n kern.bootfile`
    KERNELDIR=${BOOTFILE%/kernel}
    if ! [ -d ${KERNELDIR} ]; then
        echo "Cannot identify running kernel"
        exit 1
    fi
so KERNELDIR will be an empty string
now comes the weird thing on how [ operator works
Code: 
[09:39:37] [ns!titus]~ $A="";[ -d $A ] || echo error
[09:41:44] [ns!titus]~ $[ -d "" ] || echo error
error
so because of this the code fails to detect a borked kernel dir
Click to expand...
Yeah, the code should be checking [ -d "${KERNELDIR}" ], not [ -d ${KERNELDIR} ].

Setting the sysctl solves the problem. Upgrading from 8.0 to 8.1 completes without errors, the kernel and userland are upgraded to 8.1.

Searching the web for kern.bootfile leads to a related bug reported with mips64 architecture and uboot bootloader: 221550 – kern.bootfile returns only /kernel on mips64 (ERL) platform.

The default location of the kernel changed from /kernel to /boot/kernel/kernel in FreeBSD 3, but the default value of kern.bootfile didn't change until FreeBSD 11-12. So for example in FreeBSD 8.0 some scripts including freebsd-update get confused by the default value of kern.bootfile which is /kernel. Most people who used the FreeBSD loader didn't encounter this bug because the loader set the value automatically. GRUB and other bootloaders did not.

Adding this line to the grub.cfg menu entry doesn't work for me:

Code: 
set kFreeBSD.kern.bootfile=/boot/kernel/kernel

Adding a line to /etc/sysctl.conf works and it's probably the best solution:

Code: 
kern.bootfile=/boot/kernel/kernel
 
Are you running the real find? # which find; should give /usr/bin/find. /rescue/find isn't there now but a stripped down version it might have been on the old rescue version.
I would mv /usr/bin/find to /usr/bin/find.1 and then create a /bin/find that is echo $* >/tmp/find_in and see what is being sent.

That error reminds of script bug that sort of like "find / -type -type f". Find also requires a valid path so your "" above won't work and spaces and other characters confuse it but that can be fixed with -f as in "find -f / -type f". I've often wondered why find doesn't default to ".".
 
covacat said:
[semi] off topic. weird that the shell [ -d ] bug/feature is the same in bash (i tested in bash above)
Click to expand...
It's because [ -e ] or [ -d ] without an argument returns success and it's the same across different shells and operating systems.

Code: 
$ [ -e ]
$ echo $?
0
$ [ -e "" ]
$ echo $?
1

thogard said:
Are you running the real find? # which find; should give /usr/bin/find. /rescue/find isn't there now but a stripped down version it might have been on the old rescue version.
I would mv /usr/bin/find to /usr/bin/find.1 and then create a /bin/find that is echo $* >/tmp/find_in and see what is being sent.

That error reminds of script bug that sort of like "find / -type -type f". Find also requires a valid path so your "" above won't work and spaces and other characters confuse it but that can be fixed with -f as in "find -f / -type f". I've often wondered why find doesn't default to ".".
Click to expand...
Of course it's the real find from FreeBSD and which find is /usr/bin/find. This utility has changed somewhat between FreeBSD 8.0 and 14.2, so if you're testing it on a recent version of FreeBSD, the errors aren't exactly the same.

Your example with the -f option doesn't work for me:

Code: 
[root@localhost ~]# find -f / -type f | head
find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e
/
/dev
/dev/geom.ctl
/dev/devctl
/dev/console
/dev/ptmx
/dev/ctty
/dev/sysmouse
/dev/bpf
/dev/bpf0

By the way, GNU find defaults to .: "If no starting-point is specified, `.' is assumed."
 
PF92_ said:
Of course it's the real find from FreeBSD and which find is /usr/bin/find. This utility has changed somewhat between FreeBSD 8.0 and 14.2, so if you're testing it on a recent version of FreeBSD, the errors aren't exactly the same.

Your example with the -f option doesn't work for me:

Code: 
[root@localhost ~]# find -f / -type f | head
find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e

By the way, GNU find defaults to [file].[/file]: "If no starting-point is specified,  `.'  is assumed."
[/QUOTE]
It doesn't look like the real freebsd find based on my testing of a 14.1 or an older version which give the same error and I don't have 8.0 around anymore.  The path must be specified (likely a posix thing from way back) and can not be a null string.  The -type f has been in find since before it left AT&T so something else has to be causing the issue.  A version 8 find  might not have been fixed for any unicode file name issue.

I get 
$ find   -type f
find: illegal option -- t
but not the -- y and so on errors you are seeing. 
At this point I would be looking at making sure the arguments to find are exactly what they should be and don't have some odd characters in them.  Maybe some unicode filename is in there somehow. If you replace find with a shell script that dumps the args, then cat -v or od can show any strange characters. 

does set | grep LC_ show anything odd or does setting export LC_ALL="C" change things?
Click to expand...
 
thogard said:
It doesn't look like the real freebsd find based on my testing of a 14.1 or an older version which give the same error and I don't have 8.0 around anymore.
Click to expand...
Do you really think that I come here to lie and mislead people because you don't get the exact same errors with your FreeBSD 14.1 find that I did with the FreeBSD 8.0 find? Actually FreeBSD 8.0 ISO images are still available for download from the archival FTP. If you are interested, you can install it on a real or virtual machine, test find there and compare the errors. They are not the same across versions. And a wrapper script that dumps the arguments of find is completely unnecessary because reading the /usr/sbin/freebsd-update script with some understanding is enough to know what its arguments to find are when the sysctl kern.bootfile is set to its default value. On my system the problem is solved.
 
PF92_ said:
Do you really think that I come here to lie and mislead people because you don't get the exact same errors with your FreeBSD 14.1 find that I did with the FreeBSD 8.0 find? Actually FreeBSD 8.0 ISO images are still available for download from the archival FTP. If you are interested, you can install it on a real or virtual machine, test find there and compare the errors. They are not the same across versions. And a wrapper script that dumps the arguments of find is completely unnecessary because reading the /usr/sbin/freebsd-update script with some understanding is enough to know what its arguments to find are when the sysctl kern.bootfile is set to its default value. On my system the problem is solved.
Click to expand...
I didn't accuse of lying. There are reasons that different versions would get installed like an non-official package that decided to install a gnu version isn't unheard of. If you fixed the problem, good.
 
thogard said:
I didn't accuse of lying. There are reasons that different versions would get installed like an non-official package that decided to install a gnu version isn't unheard of. If you fixed the problem, good.
Click to expand...
Any other version of find would be installed in /usr/local/bin, not /usr/bin. But if you want me to prove that I have "the real FreeBSD find", here is the proof:

Code: 
[root@localhost ~]# echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
[root@localhost ~]# ls {/sbin,/bin,/usr/sbin,/usr/bin,/usr/games,/usr/local/sbin,/usr/local/bin,/root/bin}/find
ls: /bin/find: No such file or directory
ls: /root/bin/find: No such file or directory
ls: /sbin/find: No such file or directory
ls: /usr/games/find: No such file or directory
ls: /usr/local/bin/find: No such file or directory
ls: /usr/local/sbin/find: No such file or directory
ls: /usr/sbin/find: No such file or directory
/usr/bin/find
[root@localhost ~]# /usr/bin/find
usage: find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
       find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression]
[root@localhost ~]# /usr/bin/find -type f
find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e
find: f: No such file or directory
[root@localhost ~]# freebsd-update IDS
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 8.4-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
/.cshrc has SHA256 hash 2538febc4dfb7233e1f25579bc30aef1b4e24d104bbf1432bf97fe7e58826f08, but should have SHA256 hash 31770a07ec929c25f70edd8d943ff482d92cd7fadc064919ded9a5da675ac8a3.
/.profile has SHA256 hash 19a8c09435cab73150c81babf8c726403060b052040cb0a88ce38756b2ee6a50, but should have SHA256 hash 71e026e14ca76d33661401a32a9e05e6f3ab06057461c01186d93338bd40b78e.
/boot is a symlink, but should be a directory.
/boot/kernel/linker.hints has SHA256 hash 87280405aa135a9535074da8d7e596cd62f584eebb30f3f3f71950ddd44f0c9b, but should have SHA256 hash 60a34802240ca871c3eca6a88f80fd3baf16319bf6f968b3038774ece49bad01.
/boot/kernel/linker.hints has SHA256 hash 87280405aa135a9535074da8d7e596cd62f584eebb30f3f3f71950ddd44f0c9b, but should have SHA256 hash 9ca2f67a8739cc8c350e381c8689967d102ac5c0061eaa100ff6529955306a0e.
/etc/login.conf has SHA256 hash 9d6402aebb6c5c24f803d8a3acf1b20ca233524ec459a494ed683810e54410d1, but should have SHA256 hash 7692eaa755902c951f395bbfb4e4aaeb75e63e18408c30f68436797162955bc9.
/etc/login.conf.db has SHA256 hash 4d4944a5b5732f9fc5925acec985089742a3d5221b3bfb67e230278adee3f5b6, but should have SHA256 hash 02189905d777a6665a233239b4e10de5b4f53158bdfeb30090a344cd0777594c.
/etc/manpath.config has SHA256 hash 7750e61a7b150a79e36c2530d68ef76956eec43b7932c10532429247ee4cf4ab, but should have SHA256 hash 1b71a2c3f82324e12c16e9ecef72f00dd469b0ef7bc7d45004b5c80ccd433321.
/etc/master.passwd has SHA256 hash cd22e4bf49ac6eb5ad48dab658ec6efdd2ae6ce7238719bcdb0eec9c36b2e2cc, but should have SHA256 hash 1cd6ff07da164a4dbfa1cc8550282b457d0a2aed2aea27af5ff9d88a27cda7da.
/etc/motd has SHA256 hash 50d0edd506c0dcde03a320ac213a6b76cca3773258bd42729d6822c886e38616, but should have SHA256 hash ba25bc1d24e50377ebaaa125c2322cf590c238e001c2e11a54d956bc18c4832a.
/etc/passwd has SHA256 hash 488ad993fa4a8af17daabae5481b5c8cde074387f998cabdbf4d7de00471687c, but should have SHA256 hash cc7c03dc754a9faa2aeb9d3aafe2da4a516401d272d59559c15803d1a01a6340.
/etc/pwd.db has SHA256 hash 8e63e385eb35af5fd67920c5ddebf2458e4b3eec993ed5714014343f4caa59da, but should have SHA256 hash 10265dfafadd1b05598c1d5cec16a9fb42475e9061f78e36ee13eda50f2a2fb9.
/etc/shells has SHA256 hash 4556bd20f8360854ddeff604a820c7c7fcf58e9ebe6b177ea8b320a7a9db2b91, but should have SHA256 hash c473f3f864c7bd5280761de161f96f84c25fb5a65e3b10b704d006001400e14c.
/etc/spwd.db has SHA256 hash 4ee41d97647520e10dcaf05bb17fc15db4d7778a20b2a40674c3f800e13a3012, but should have SHA256 hash 0811d890eceaf7733987ca695ef429bfae5d864edcbeb69abf8c04c4ddefc2fb.
/etc/ssh/sshd_config has SHA256 hash 16182a5f6a84889472ab3eaea63e10a7244bcf71f5649430dc9189bcae48f499, but should have SHA256 hash f68ef080849212b8422b5dfbf9e3f3a63222a783cf33c6de2afaa31bb8562067.
/etc/sysctl.conf has SHA256 hash 89dcf62d96211ae0eb93d8f9f8e8db580aa65acbcf2969bce77874f96c33235d, but should have SHA256 hash 5858f412fc9f9a86ca8f9816ac6d333ecabb19ead6a7a5e1a10e457bc750f8b6.
/etc/ttys has SHA256 hash bce8178ffddc64bd9bf5bf37baba4a6c373a654c2427bfae221c8c73130536ff, but should have SHA256 hash 7c3184de0f8ca9a27bb505ec7803b2a738a8c0ad61455d1d7aecae39f0d60a10.
/root/.profile has SHA256 hash 19a8c09435cab73150c81babf8c726403060b052040cb0a88ce38756b2ee6a50, but should have SHA256 hash 71e026e14ca76d33661401a32a9e05e6f3ab06057461c01186d93338bd40b78e.
[root@localhost ~]# uname -v
FreeBSD 8.4-RELEASE-p35 #0: Tue Jul 28 10:38:20 UTC 2015     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC

The system has been upgraded to 8.4 from 8.0, but the behaviour of find remains the same. If /usr/bin/find was somehow replaced by another version, freebsd-update IDS would have detected it.
 
You must log in or register to reply here.
Back
Top