Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Uwe Dippel
[I consider it better to open a new thread, since the title, and part of
the content, of the previous one was superseded.]

Having upgraded one machine (amd64) from 4.6 to 4.7, using the normal
upgrade procedure as outlined in http://openbsd.org/faq/upgrade47.html 
to the dot, after the reboot it showed that the files contained in
base47.tar were not installed. All other sets apparently did get
installed. This led to some out-of-sync problems with pfctl, by which
this failure was noticed.
(http://article.gmane.org/gmane.os.openbsd.misc/174272)

While waiting for some details, and trying to recapitulate what went
wrong, I did the same procedure to an i386 machine, apparently with
identical result: The base47 files are missing; there are still the
previous files from base46 in the machine. As far as I can make out, all
other sets installed perfectly well.

Since this happened on two physical machines of different architecture,
and in both cases by meticulously following the upgrade guide with the
boot bsd.rd mechanism, it cannot be excluded that there is a weakness in
the installer. There was no error message, on the contrary, all looked
okay, including the installation of the sets.

There is one more machine (amd64) that needs to be upgraded. Before I do
this, I rather solicit suggestions on how to log the upgrade process,
debug it, or otherwise.

I do not state at all, that the observed behaviour affects all
installations, nor anyone else. It still points to a potential weakness,
since both machines run nothing but standard OpenBSD, and have been
upgraded through all previous versions using the same method since 3.8;
until now without fail.

Uwe


As preliminary evidence, I have attached randomly selected files from
the tar-sets that were found to differ in 4.6 and 4.7.
The first line shows the extraction of those files from the archives
used for installation, the subsequent lines show the calculations of
their md5 sums, firstly in the user directory; followed by the md5 sums
of those files as installed by the upgrade process.
(For misc and xfonts no files were found (non-exhaustive search) that
differed in 4.6 and 4.7)
The '$' prompt is on the machine containing the archives, followed by
the '#' prompt, which is on the respective machine to which 4.7 was
installed.

amd64:

> base:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
> $ md5 sbin/pfctl
> MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4 <== archive
> # md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7 <== upgraded
> $ md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7 <== 4.6
>
>
> comp:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/comp47.tgz ./var/db/libc.tags
> $ md5 var/db/libc.tags
> MD5 (var/db/libc.tags) = ef05ce6515665eff14618c02c4678edc <== archive
> # md5 /var/db/libc.tags
> MD5 (/var/db/libc.tags) = ef05ce6515665eff14618c02c4678edc <== upgraded
> $ md5 /var/db/libc.tags
> MD5 (/var/db/libc.tags) = d3e2a489d70cd3f0d91fef538f4ebfd1 <== 4.6
>
> games:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/game47.tgz ./usr/games/morse
> $ md5 usr/games/morse
> MD5 (usr/games/morse) = 61157239de35061df71e7be2e17a9471 <== archive
> # md5 /usr/games/morse
> MD5 (/usr/games/morse) = 61157239de35061df71e7be2e17a9471 <== upgraded
> $ md5 /usr/games/morse
> MD5 (/usr/games/morse) = ee30c2129ceac343438ea03a9efa2fe5 <== 4.6
>
> man:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/man47.tgz ./usr/share/man/ps8/loongson
> $ md5 usr/share/man/ps8/loongson/
> MD5 (usr/share/man/ps8/loongson/) = d41d8cd98f00b204e9800998ecf8427e <== archive
> # md5 /usr/share/man/ps8/loongson/
> MD5 (/usr/share/man/ps8/loongson/) = d41d8cd98f00b204e9800998ecf8427e <== upgraded
> $ md5 /usr/share/man/ps8/loongson/
> md5: cannot open /usr/share/man/ps8/loongson/: No such file or directory <== 4.6
>
> misc:
> ??
>
> xbase:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/xbase47.tgz ./usr/X11R6/man/whatis.db
> $ md5 usr/X11R6/man/whatis.db
> MD5 (usr/X11R6/man/whatis.db) = a6ebdd66fe58b66136c9fdfc9eca1c5d <== archive
> # md5 /usr/X11R6/man/whatis.db
> MD5 (/usr/X11R6/man/whatis.db) = a6ebdd66fe58b66136c9fdfc9eca1c5d <== upgraded
> $ md5 /usr/X11R6/man/whatis.db
> MD5 (/usr/X11R6/man/whatis.db) = 01e11bb37c523bc6fe8c37e139f6fe41 <== 4.6
>
> xetc:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/xetc47.tgz ./var/db/sysmerge/xetcsum
> $ md5 var/db/sysmerge/xetcsum
> MD5 (var/db/sysmerge/xetcsum) = 374865b6f2b5a34b64148bfe6746cfd0 <== archive
> # md5 /var/db/sysmerge/xetcsum
> md5: cannot open /var/db/sysmerge/xetcsum: No such file or directory <== upgraded
> $ md5 /var/db/sysmerge/xetcsum
> md5: cannot open /var/db/sysmerge/xetcsum: No such file or directory <== 4.6
>
> xfonts:
> ??
>
> xserv:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/xserv47.tgz ./usr/X11R6/lib/modules/dri/r300_dri.so
> $ md5 usr/X11R6/lib/modules/dri/r300_dri.so
> MD5 (usr/X11R6/lib/modules/dri/r300_dri.so) = e7caa1ee3691a40c40f994dfb210738c <== archive
> # md5 /usr/X11R6/lib/modules/dri/r300_dri.so
> MD5 (/usr/X11R6/lib/modules/dri/r300_dri.so) = e7caa1ee3691a40c40f994dfb210738c<== upgraded
> $ md5 /usr/X11R6/lib/modules/dri/r300_dri.so
> MD5 (/usr/X11R6/lib/modules/dri/r300_dri.so) = f31e33e835d6361800553b7a74eb0bf2 <== 4.6
>
> xshare:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/xshare47.tgz ./usr/X11R6/share/pci.ids
> $ md5 usr/X11R6/share/pci.ids
> MD5 (usr/X11R6/share/pci.ids) = 4f25889b608e7d9ba54e3904cc22d969 <== archive
> # md5 /usr/X11R6/share/pci.ids
> MD5 (/usr/X11R6/share/pci.ids) = 4f25889b608e7d9ba54e3904cc22d969 <== upgraded
> $ md5 /usr/X11R6/share/pci.ids
> MD5 (/usr/X11R6/share/pci.ids) = 48feb928ed568b380f63a904e099a87e <== 4.6

i386:

> base:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/base47.tgz ./sbin/pfctl
> $ md5 sbin/pfctl
> MD5 (sbin/pfctl) = d9db01cc42e88ac827e5062c7b141d34 <== archive
> # md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 5475de97e9aa2a76678da2f02fbdad9d <== upgraded
>
> comp:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/base47.tgz ./sbin/pfctl
> $ md5 var/db/libc.tags
> MD5 (var/db/libc.tags) = 877f50cf022baa15cebdec89a937b0c5 <== archive
> # md5 /var/db/libc.tags
> MD5 (/var/db/libc.tags) = 877f50cf022baa15cebdec89a937b0c5 <== upgraded
>
> games:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/game47.tgz ./usr/games/morse
> $ md5 usr/games/morse
> MD5 (usr/games/morse) = 258c848f9975ebeb252c15bce9ed9920 <== archive
> # md5 /usr/games/morse
> MD5 (/usr/games/morse) = 258c848f9975ebeb252c15bce9ed9920 <== upgraded
>
> man:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/man47.tgz ./usr/share/man/ps8/loongson
> $ md5 usr/share/man/ps8/loongson/
> MD5 (usr/share/man/ps8/loongson/) = d41d8cd98f00b204e9800998ecf8427e <== archive
> # md5 /usr/share/man/ps8/loongson/
> MD5 (/usr/share/man/ps8/loongson/) = d41d8cd98f00b204e9800998ecf8427e <== upgraded
>
> misc:
> ??
>
> xbase:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/xbase47.tgz ./usr/X11R6/man/whatis.db
> $ md5 usr/X11R6/man/whatis.db
> MD5 (usr/X11R6/man/whatis.db) = e6bea4479ed31cfe59072a7e90a913c7 <== archive
> # md5 /usr/X11R6/man/whatis.db
> MD5 (/usr/X11R6/man/whatis.db) = e6bea4479ed31cfe59072a7e90a913c7 <== upgraded
>
> xfonts:
> ??
>
> xserv:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/xserv47.tgz ./usr/X11R6/lib/modules/dri/r300_dri.so
> $ md5 usr/X11R6/lib/modules/dri/r300_dri.so
> MD5 (usr/X11R6/lib/modules/dri/r300_dri.so) = 96d210a275277d1834cfac3945e62068 <== archive
> # md5 /usr/X11R6/lib/modules/dri/r300_dri.so
> MD5 (/usr/X11R6/lib/modules/dri/r300_dri.so) = 96d210a275277d1834cfac3945e62068 <== upgraded
>
> xshare:
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/i386/xshare47.tgz ./usr/X11R6/share/pci.ids
> $ md5 usr/X11R6/share/pci.ids
> MD5 (usr/X11R6/share/pci.ids) = 4f25889b608e7d9ba54e3904cc22d969 <== archive
> # md5 /usr/X11R6/share/pci.ids
> MD5 (/usr/X11R6/share/pci.ids) = 4f25889b608e7d9ba54e3904cc22d969 <== upgraded

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Uwe Dippel
Getting closer ...

Extracted the archive being used for the upgrade to amd64 into my
user-directory and calculated all 7484 md5 for the files included in
base47, and redirected those into a file.
Then, I calculated all the md5 for the files *installed* in the upgraded
machine; the file names taken from the same base47.
Then, I had two files of 7484 md5s each, and could diff them.
Further down is the result. I'm stumped. Why would these files (around
100) not be the 4.7 version, but previous (4.6 I guess; I haven't
checked all).
(Add /etc/pfctl to the list of different files; I had already manually
copied it to /sbin from the archive to get the firewall working)
So *all* sets were installed, in principle, but some files were not. Huh?

I am sure, some people with more insight can help me further to explain
what is going on here. What makes or made these files below so 'special'
that they fail to be 'just there' after the upgrade on amd64?

Thanks for any further hint,

Uwe


$ diff md5sums_archive md5sums_install
1c1
< ./usr/lib/libasn1.so.17.0 f07fcaad530dd9632ef7de1491ed6bd3
---
 > ./usr/lib/libasn1.so.17.0 aa2c929c805b55008bba1bc942483b01
3,4c3,4
< ./usr/lib/libcom_err.so.17.0 f07fcaad530dd9632ef7de1491ed6bd3
< ./usr/lib/libcrypto.so.18.0 4280f48657120e382c01ca4c1a8aafc4
---
 > ./usr/lib/libcom_err.so.17.0 aa2c929c805b55008bba1bc942483b01
 > ./usr/lib/libcrypto.so.18.0 5f38e49397b845acdf818c520953eb0e
14,15c14,15
< ./usr/lib/libkafs.so.17.0 f07fcaad530dd9632ef7de1491ed6bd3
< ./usr/lib/libkrb5.so.17.0 f07fcaad530dd9632ef7de1491ed6bd3
---
 > ./usr/lib/libkafs.so.17.0 aa2c929c805b55008bba1bc942483b01
 > ./usr/lib/libkrb5.so.17.0 aa2c929c805b55008bba1bc942483b01
34c34
< ./usr/lib/libssl.so.15.1 baa09f0512fbe6ecb1519de10ed6a8a4
---
 > ./usr/lib/libssl.so.15.1 e3dcfdfc876252231bd8994c3f0c6f1d
192,195c192,195
< ./sbin/atactl 6ba0fc88a2cf2ad11bf5bdfee76b5bc5
< ./sbin/badsect 4914ef0ea057a00d8b9ae91eaf894af5
< ./sbin/bioctl ce8467b4415309be9b447405938fcda0
< ./sbin/ccdconfig 08123bd59420bf542011b5a72c6f896c
---
 > ./sbin/atactl e214991d640840544a90595b661b6378
 > ./sbin/badsect a87ca3adea353c650c15ff7db2059c94
 > ./sbin/bioctl 6737ac6873c92917779282cf3f3e8cb5
 > ./sbin/ccdconfig af51c2c19995759fcfd4f8ed6c7ab64d
197,198c197,198
< ./sbin/clri 721d8795ff051d72ee67175902c53dd6
< ./sbin/dhclient 3e1f06ca19aa5aceec214d2891fa504e
---
 > ./sbin/clri afef2851d33038cb9de7c21f2d6dc037
 > ./sbin/dhclient 5f6a023ce04f9fc3611a56c1752c5c30
200,219c200,219
< ./sbin/disklabel 3162a316caada7f5ebdd8b07d5722cb2
< ./sbin/dmesg 3acb23453982bdf9974c4f3abb8d6dfd
< ./sbin/dump e24875bd59e468780c4f53dc8685befc
< ./sbin/dumpfs 5cc5b40775147860423cddf45e264fac
< ./sbin/fdisk 6a1a875a41cceed2874e2b1e861b0257
< ./sbin/fsck 6fd26d79982bfe5d91d2f450ea495a19
< ./sbin/fsck_ext2fs 5dbb372ffbdb958bcfbd8d24811c4f87
< ./sbin/fsck_ffs 7bba80258056a3a40b51d24a63d4e5de
< ./sbin/fsck_msdos 85eacde50cecb85043601e05aac5a606
< ./sbin/fsdb e46a8fa824d753af715cae0f8e4a8049
< ./sbin/fsirand 65018fa13f98e1de12f5dfdcfc59cafd
< ./sbin/growfs 7e7ba9034167529de5cef12497e2228b
< ./sbin/halt e8612dfe7b7703188cb887852b073fe7
< ./sbin/ifconfig bc731472da980771e922604a7f76bb7e
< ./sbin/init a6e6bf349857e9addcce114f5cbeebea
< ./sbin/iopctl b1ffd69049a845e749f1fdff490045be
< ./sbin/ipsecctl acdee246db653efa457193d9d7be195b
< ./sbin/isakmpd 6e8462f8a4c3cfc2901dbe3163c9f857
< ./sbin/kbd b7da651953889ab863042dd1e05976dc
< ./sbin/ldattach b0b97a2496c0c2593c437842cb29d9df
---
 > ./sbin/disklabel b6455e58788253af334bda563c12ca12
 > ./sbin/dmesg 4a9f96f0a968f616a4dda156ec1572f4
 > ./sbin/dump bdbfcd38d79289f81f23059cfb6156ea
 > ./sbin/dumpfs 847cde118bbff6e12981ec92270aabcc
 > ./sbin/fdisk 7b0d0a7788e323811c91c92761c7244f
 > ./sbin/fsck 8105d9fc124a57dd343ba97d19c9fc48
 > ./sbin/fsck_ext2fs ed161578a1777c598c10bb6963d0b7b4
 > ./sbin/fsck_ffs 1b978655ccdcbf54e78c8febc2b8808b
 > ./sbin/fsck_msdos 43bc067c65f648041f8ade25ddd077d1
 > ./sbin/fsdb 8f720b110108c74f55b69935a20adfa6
 > ./sbin/fsirand d39bf0252bfaad9aa256dbf294ede7da
 > ./sbin/growfs d129af4e9526b87992de226da5f1e184
 > ./sbin/halt 2d0046c3e383d785b856d1cb0dbe7e5a
 > ./sbin/ifconfig 35e192bac398bf47ddf8e0a190f6b06a
 > ./sbin/init 37d5ca74a94642c48f2278c17420bf76
 > ./sbin/iopctl 04b18862d04525f6a53324694180592f
 > ./sbin/ipsecctl 0f78f6df80715707bcd0dca44199debe
 > ./sbin/isakmpd 9093d66c257145221ce33f4114ca3507
 > ./sbin/kbd d0e6b82ecadad09eab297ce032fe1d70
 > ./sbin/ldattach 04eace371d1dc317b289da273a311c10
221,242c221,242
< ./sbin/lmccontrol 2c9a1f7a4cb9af7d9ceaf47d9482eb8b
< ./sbin/mkfifo 7ebd0d605fb65d8acdce0b1542b7a949
< ./sbin/mknod 7ebd0d605fb65d8acdce0b1542b7a949
< ./sbin/modload bca677810f776226d24832fa2a118609
< ./sbin/modunload 95e4adeda57e7c52f240f136e092eb7b
< ./sbin/mount 6903ddec325432d73f65c80a56a9aef3
< ./sbin/mount_cd9660 cb343f92845ad398d2cc3e4262934030
< ./sbin/mount_ext2fs dcb91a3f42126fb96ece261f9a3db010
< ./sbin/mount_ffs 6fbd41195622e084f3b9ace630d73d2d
< ./sbin/mount_mfs c707d5acad7bc11fc5feeb4f4841a1e0
< ./sbin/mount_msdos c1d5742cc20e13b2b195f9d8d32c7769
< ./sbin/mount_nfs 1d760a000ff47f1743e17ed2f5d23ddf
< ./sbin/mount_nnpfs 1ebcaf70eb85aa082c0b2414582595fe
< ./sbin/mount_ntfs 30cb5fce31d371e7a40754926ef81faa
< ./sbin/mount_portal 514303a34e29caff296c916713caca73
< ./sbin/mount_procfs 35f6484fe2ea2dc6c265a8fb4497b6ec
< ./sbin/mount_udf ee3ad9802ed7deea77e8f402e87e9b73
< ./sbin/mount_vnd 9985c390c46acc04449ad7042d28903d
< ./sbin/mountd 8841709628945de4dbf4598d8c4bb5a5
< ./sbin/ncheck 81288e95570b42a89847fbadab19fb8a
< ./sbin/ncheck_ffs 81288e95570b42a89847fbadab19fb8a
< ./sbin/newfs c707d5acad7bc11fc5feeb4f4841a1e0
---
 > ./sbin/lmccontrol 3cfbcac457727d6b145f331c47f345c8
 > ./sbin/mkfifo 56eaaf46d8cf944cf99dc765fbd6c21e
 > ./sbin/mknod 56eaaf46d8cf944cf99dc765fbd6c21e
 > ./sbin/modload 23c241782c9d04f1ec3b11e72d78259f
 > ./sbin/modunload 97ef8032d349a26bf552f494ec756ba7
 > ./sbin/mount f40e9bc2c5f7079a490e1d139397de25
 > ./sbin/mount_cd9660 5104ec3f6ab7f4f37dc69250f234a376
 > ./sbin/mount_ext2fs d10da37fb419f17238e2eeca536f2e07
 > ./sbin/mount_ffs 25e2a1e6597ade7a13d1c0698c70f1d3
 > ./sbin/mount_mfs 817bcb9d2fa5f45289f22e4fe704668c
 > ./sbin/mount_msdos 3efa0a8c1ddff19fa81db4fdd9166a01
 > ./sbin/mount_nfs 7f96f5ddc24fa113cd7c01a95fcd4db7
 > ./sbin/mount_nnpfs 61d2a0dc800c340c263837af109b4f5a
 > ./sbin/mount_ntfs 0b57598fe9bbeea8d48df5cd61652046
 > ./sbin/mount_portal 12f4bb37e9398444fa16e4d07684ecc7
 > ./sbin/mount_procfs 044ca47eba1932b5078f6b216c089a5d
 > ./sbin/mount_udf 166658197af47ccd19b69a4de14f2cba
 > ./sbin/mount_vnd c0dd846355175aed4ea96354eef26132
 > ./sbin/mountd 7b82e9669a1db4cbebb2bde3fdeffd19
 > ./sbin/ncheck 80a003d861c1c175e322cb02a13f68ed
 > ./sbin/ncheck_ffs 80a003d861c1c175e322cb02a13f68ed
 > ./sbin/newfs 817bcb9d2fa5f45289f22e4fe704668c
244,246c244,246
< ./sbin/newfs_msdos 9b09835b9ab5475c915423c7258c6ea9
< ./sbin/nfsd 0cc86442030ebc35e1bab446078e7da7
< ./sbin/nologin 1942857c67b2b5bb52d4cd75037d95dc
---
 > ./sbin/newfs_msdos 3ef62790af22a09db5daa84979074949
 > ./sbin/nfsd db29c705c0769b5c9d611bb4d3fd8b6d
 > ./sbin/nologin 377f29caddbd06120ee9934fceda26e4
248,272c248,272
< ./sbin/pflogd 1e6bd994990e69b35bb80ecb5039a65f
< ./sbin/ping 58698721b4b734ffef47dbbb7554a110
< ./sbin/ping6 400543499da12ad96036ddc33b29680a
< ./sbin/quotacheck 4726491371bad7d181ae80b8965b4b8f
< ./sbin/raidctl 037a404b02443a1fa249790efb7699c2
< ./sbin/rdump e24875bd59e468780c4f53dc8685befc
< ./sbin/reboot e8612dfe7b7703188cb887852b073fe7
< ./sbin/restore cebb040a27aeedc100bd017870d3ae97
< ./sbin/route a898196125f5258edb8fc348c5b90c4f
< ./sbin/rrestore cebb040a27aeedc100bd017870d3ae97
< ./sbin/rtsol 0b88b74a081f4a999c6f061e85ca4cb2
< ./sbin/savecore 7516d314269e4e913346150d6f833098
< ./sbin/scan_ffs 3c4377999f843a4338ebc1a4306eeac4
< ./sbin/scsi 3a7354c2176ad66d84f25355703e5a87
< ./sbin/shutdown 09322f95ff3982c5e3b4df1c66e7cd6e
< ./sbin/slattach ec868b1d908a76f452ae096f53097cb9
< ./sbin/swapctl 03461e70a2fad3ffa70bc40ba459f045
< ./sbin/swapon 03461e70a2fad3ffa70bc40ba459f045
< ./sbin/sysctl 0f7cb8fe62e5f130eee087868b3a2098
< ./sbin/ttyflags bf4c17f7211e5ca630a4dbdb803483d7
< ./sbin/tunefs 556251270178586c529c399d8c75dcdd
< ./sbin/umount 04c65299ef0dab645fbff6ebc6653dbc
< ./sbin/vnconfig 9985c390c46acc04449ad7042d28903d
< ./sbin/wpa-psk c18bd9f7dcf367c7a1ed032213810249
< ./sbin/wsconsctl c57d0a0fc63c8409f414f6da0ea1a547
---
 > ./sbin/pflogd eeac80b9d83a32369cca35593aaf43ca
 > ./sbin/ping 6c9e56c20ee3419008b1701859c91418
 > ./sbin/ping6 4d51e1976d48029de6a8745c24bbbdff
 > ./sbin/quotacheck 4bdf584e2c405de2c96073bbdbb3f61f
 > ./sbin/raidctl 058de739a75c4de7720b5d3e3d420fdb
 > ./sbin/rdump bdbfcd38d79289f81f23059cfb6156ea
 > ./sbin/reboot 2d0046c3e383d785b856d1cb0dbe7e5a
 > ./sbin/restore e1e9cf3cad1aa8472f5ebe43c2c1e0b0
 > ./sbin/route e43646310fa402c2d36a0f9758d1af60
 > ./sbin/rrestore e1e9cf3cad1aa8472f5ebe43c2c1e0b0
 > ./sbin/rtsol ea6f7ba10531c3f9dfc26065f56d6801
 > ./sbin/savecore 768a92dfffcc124932e305a350d5eb05
 > ./sbin/scan_ffs 0a66911fbad56c5f467d99e50eed4a0a
 > ./sbin/scsi 72dd0869171420748838bc0eb55f7bc0
 > ./sbin/shutdown 256b00b7cd99195945e561a73ec93153
 > ./sbin/slattach 6118b9bdf57b6ea78bbc93f9ed474918
 > ./sbin/swapctl dd683988fc5032c046963d269ea3ea47
 > ./sbin/swapon dd683988fc5032c046963d269ea3ea47
 > ./sbin/sysctl 2ba5c508efabf6f43a8250d9bf1d5bcf
 > ./sbin/ttyflags 2e31357bde3a78d3368c11f338920b09
 > ./sbin/tunefs 56083ca24ffd35073a1edd79d8797673
 > ./sbin/umount 3a0d45c6217916c5a090d609b038456c
 > ./sbin/vnconfig c0dd846355175aed4ea96354eef26132
 > ./sbin/wpa-psk c54d87ca75a4e2c46faacc9bbe45b7f3
 > ./sbin/wsconsctl 6429af333c60de898ec8feab84ef059c
4518c4518
< ./usr/libexec/kdc beea11bf456670a1e12a71194deceb2c
---
 > ./usr/libexec/kdc c824ff813bcfd588a8d6eaabb5c24d11
4762c4762
< ./usr/sbin/sysctl 0f7cb8fe62e5f130eee087868b3a2098
---
 > ./usr/sbin/sysctl 2ba5c508efabf6f43a8250d9bf1d5bcf


And here is the 'code' used; for verification purposes:

$ cd
$ mkdir helpo
$ cd helpo
$ [download base47.tgz to .]
$ tar xzf base47.tgz
$ su
# pwd
/home/udippel/helpo
# for FILE in `tar tzf base47.tgz`
 > do
 > echo -n $FILE >> md5sums_archive
 > echo -n " " >> md5sums_archive
 > md5 $FILE | cut -d ' ' -f4 >> md5sums_archive
 > done
#
# cd /
# for FILE in `tar tzf /home/udippel/helpo/base47.tgz`
 > do
 > echo -n $FILE >> /home/udippel/helpo/md5sums_install
 > echo -n " " >> /home/udippel/helpo/md5sums_install
 > md5 $FILE | cut -d ' ' -f4 >> /home/udippel/helpo/md5sums_install
 > done
# cd /home/udippel/helpo/
# chown udippel:udippel md5sums_install
# exit
$ cd
$ cd helpo/
$ ls -l md5sums_*
-rw-r--r--  1 udippel  udippel  573434 Jun  2 14:52 md5sums_archive
-rw-r--r--  1 udippel  udippel  573434 Jun  2 15:05 md5sums_install
$ diff md5sums_archive md5sums_install

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Uwe Dippel
In reply to this post by Uwe Dippel
Now, with

$ diff md5sums_archive md5sums_install | grep ^">" | cut -d ' ' -f2
these are the files different on amd64, between what the archive
supplied, and what the installer left behind:

./usr/lib/libasn1.so.17.0
./usr/lib/libcom_err.so.17.0
./usr/lib/libcrypto.so.18.0
./usr/lib/libkafs.so.17.0
./usr/lib/libkrb5.so.17.0
./usr/lib/libssl.so.15.1
./sbin/atactl
./sbin/badsect
./sbin/bioctl
./sbin/ccdconfig
./sbin/clri
./sbin/dhclient
./sbin/disklabel
./sbin/dmesg
./sbin/dump
./sbin/dumpfs
./sbin/fdisk
./sbin/fsck
./sbin/fsck_ext2fs
./sbin/fsck_ffs
./sbin/fsck_msdos
./sbin/fsdb
./sbin/fsirand
./sbin/growfs
./sbin/halt
./sbin/ifconfig
./sbin/init
./sbin/iopctl
./sbin/ipsecctl
./sbin/isakmpd
./sbin/kbd
./sbin/ldattach
./sbin/lmccontrol
./sbin/mkfifo
./sbin/mknod
./sbin/modload
./sbin/modunload
./sbin/mount
./sbin/mount_cd9660
./sbin/mount_ext2fs
./sbin/mount_ffs
./sbin/mount_mfs
./sbin/mount_msdos
./sbin/mount_nfs
./sbin/mount_nnpfs
./sbin/mount_ntfs
./sbin/mount_portal
./sbin/mount_procfs
./sbin/mount_udf
./sbin/mount_vnd
./sbin/mountd
./sbin/ncheck
./sbin/ncheck_ffs
./sbin/newfs
./sbin/newfs_msdos
./sbin/nfsd
./sbin/nologin
./sbin/pfctl
./sbin/pflogd
./sbin/ping
./sbin/ping6
./sbin/quotacheck
./sbin/raidctl
./sbin/rdump
./sbin/reboot
./sbin/restore
./sbin/route
./sbin/rrestore
./sbin/rtsol
./sbin/savecore
./sbin/scan_ffs
./sbin/scsi
./sbin/shutdown
./sbin/slattach
./sbin/swapctl
./sbin/swapon
./sbin/sysctl
./sbin/ttyflags
./sbin/tunefs
./sbin/umount
./sbin/vnconfig
./sbin/wpa-psk
./sbin/wsconsctl
./usr/libexec/kdc
./usr/sbin/sysctl

Let's assume for a moment, that the differences of Kerberos and crypto
stuff is a result of the patches and packages, everything else different
is the majority of the files in /sbin.
A yet closer inspection of the differences there leads to a confirmation
of what was assumed before: of all files in /sbin, except of
/sbin/ifconfig, /sbin/ipsecctl and /sbin/isakmpd, are the files of the
4.6 Release.

Waiting for some further enlightment about what was going on; what
happened to those 4.7 files,

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Nick Holland
In reply to this post by Uwe Dippel
On 06/01/10 23:25, Uwe Dippel wrote:
...
> There is one more machine (amd64) that needs to be upgraded. Before I do
> this, I rather solicit suggestions on how to log the upgrade process,
> debug it, or otherwise.

serial console.
Log everything from the first chars out the serial port to the reboot.
 In fact, log the reboot.
Don't edit anything.
Use a public mirror or an official CD for the install, make sure it is
obvious which.

Stick the resulting file on a webserver.
...

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
Nick Holland <nick <at> holland-consulting.net> writes:

> > There is one more machine (amd64) that needs to be upgraded. Before I do
> > this, I rather solicit suggestions on how to log the upgrade process,
> > debug it, or otherwise.
>
> serial console.
> Log everything from the first chars out the serial port to the reboot.
>  In fact, log the reboot.
> Don't edit anything.
> Use a public mirror or an official CD for the install, make sure it is
> obvious which.
>
> Stick the resulting file on a webserver.

Thanks, Nick.

Based on the latest results, the problem seems to exist only for most of the
/sbin files. So, the upgrade runs through as programmed.
With a public mirror, it will take hours. I really hope SHA256 is good enough to
confirm the integrity of the archives. Serial console seems a good idea; I have
to use it in any case.
What I have in mind, is, before the reboot, to use the command prompt to check
the files in the /sbin-to-be. I have a hunch, that they'll be there, then. Then
I'll do the same after the reboot, and once again, after the package upgrade.
Should the phenomenon show again, by now I can imagine that the changes are
happening some time later. We'll see ...

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Joachim Schipper-2
On Wed, Jun 02, 2010 at 02:42:53PM +0000, Uwe Dippel wrote:

> Nick Holland <nick <at> holland-consulting.net> writes:
>
> > > There is one more machine (amd64) that needs to be upgraded. Before I do
> > > this, I rather solicit suggestions on how to log the upgrade process,
> > > debug it, or otherwise.
> >
> > serial console.
> > Log everything from the first chars out the serial port to the reboot.
> >  In fact, log the reboot.
> > Don't edit anything.
> > Use a public mirror or an official CD for the install, make sure it is
> > obvious which.
> >
> > Stick the resulting file on a webserver.
>
> Thanks, Nick.
>
> Based on the latest results, the problem seems to exist only for most of the
> /sbin files. So, the upgrade runs through as programmed.
> With a public mirror, it will take hours. I really hope SHA256 is good enough to
> confirm the integrity of the archives. Serial console seems a good idea; I have
> to use it in any case.
> What I have in mind, is, before the reboot, to use the command prompt to check
> the files in the /sbin-to-be. I have a hunch, that they'll be there, then. Then
> I'll do the same after the reboot, and once again, after the package upgrade.
> Should the phenomenon show again, by now I can imagine that the changes are
> happening some time later. We'll see ...

Just for clarity: is everything that fails to change on the same disk?
I.e. can you post the output of 'mount' (within bsd.rd) as well? And I
presume you shut down in a sensible fashion, right?

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Theo de Raadt
> > Based on the latest results, the problem seems to exist only for most of the
> > /sbin files. So, the upgrade runs through as programmed.
> > With a public mirror, it will take hours. I really hope SHA256 is good enough to
> > confirm the integrity of the archives. Serial console seems a good idea; I have
> > to use it in any case.
> > What I have in mind, is, before the reboot, to use the command prompt to check
> > the files in the /sbin-to-be. I have a hunch, that they'll be there, then. Then
> > I'll do the same after the reboot, and once again, after the package upgrade.
> > Should the phenomenon show again, by now I can imagine that the changes are
> > happening some time later. We'll see ...
>
> Just for clarity: is everything that fails to change on the same disk?
> I.e. can you post the output of 'mount' (within bsd.rd) as well? And I
> presume you shut down in a sensible fashion, right?

A chit-chat on a public mailing list isn't going to find this supposed
bug.  Why discuss it?  Why not just keep prove it happened.  Don't you see
how tiring it is to discuss it when we've seen no evidence?

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
Theo de Raadt <deraadt <at> cvs.openbsd.org> writes:

> A chit-chat on a public mailing list isn't going to find this supposed
> bug.  Why discuss it?  Why not just keep prove it happened.

Yes, Theo. Though: How? This is what I tried to find out.
I showed the list if files. Do you assume I tinkered with it? Why should I?
pfctl wasn't working correctly. Without the help of the list, I wouldn't have
been able to drill it down to some 70 files being of the previous version.
Thanks to everyone who helped!

> Don't you see
> how tiring it is to discuss it when we've seen no evidence?

It might be tiring, but what evidence do you want? Here, I want to solve a
problem of files missing. Since I followed the Upgrade guide to the dot,
rebooted to bsd.rd in the beginning, rebooted at the command prompt, we (I) need
to find what went wrong. That's all. I don't even mind if the mistake was on my
side, then I could learn.

So, please, specify the evidence that you need.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Theo de Raadt
> Theo de Raadt <deraadt <at> cvs.openbsd.org> writes:
>
> > A chit-chat on a public mailing list isn't going to find this supposed
> > bug.  Why discuss it?  Why not just keep prove it happened.
>
> Yes, Theo. Though: How? This is what I tried to find out.
> I showed the list if files. Do you assume I tinkered with it? Why should I?
> pfctl wasn't working correctly. Without the help of the list, I wouldn't have
> been able to drill it down to some 70 files being of the previous version.
> Thanks to everyone who helped!
>
> > Don't you see
> > how tiring it is to discuss it when we've seen no evidence?
>
> It might be tiring, but what evidence do you want? Here, I want to solve a
> problem of files missing. Since I followed the Upgrade guide to the dot,
> rebooted to bsd.rd in the beginning, rebooted at the command prompt, we (I) need
> to find what went wrong. That's all. I don't even mind if the mistake was on my
> side, then I could learn.
>
> So, please, specify the evidence that you need.

If everyone felt the need to debug the personal problem with their own
machines on this giant mailing list in the fashion you just did, I
will unsubscribe.

It isn't tiring -- it is just plain ridiculous.

Figure out what is wrong, THEN POST THAT.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Tony Abernethy
In reply to this post by udippel (Bugzilla)
Uwe Dippel wrote:
> drill it down to some 70 files being of the previous
> version.

> It might be tiring, but what evidence do you want?

The error message(s) you are suppressing (or maybe didn't see)

About the only way you can get some files but not all files
from a tarball is some fatal error in the extraction of the
tarball. Any such error tends to give an error message.
I don't think this list likes to play guessing games as to exactly
what mistakes you have made or what evidence you are suppressing.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
On Thu, Jun 3, 2010 at 3:20 PM, Tony Abernethy <[hidden email]> wrote:

> The error message(s) you are suppressing (or maybe didn't see)
>
> About the only way you can get some files but not all files
> from a tarball is some fatal error in the extraction of the
> tarball. Any such error tends to give an error message.
> I don't think this list likes to play guessing games as to exactly
> what mistakes you have made or what evidence you are suppressing.

Oh, how beautiful! This is a sign of mutual trust. I documented
everything from the first pfctl after reboot from upgrade not working,
for what I am chided; and still, I am supposed to 'suppress evidence'.
How nice of you!
And if I present a serial log, I will have been suspected to have
tempered with it?

No, that seriously turns me off. I have given everything in detail
that I came across, I have not been silent about any additional
message, any unusual activity. I have stated a few times that I
followed the upgrade procedure to the dot, I have confirmed that
nothing unusual showed.
Over. I might have made some mistake, yes. Even though these same
boxes have been upgraded since 3.8, nevermind. I could at all times
have made a mistake or overlooked something.
But to start kind of asking for 'proof', that's what's ridiculous, to
cite Theo. I am willing to give individuals unprivileged access to the
boxes, I did this before, to look around.
When you have a box that is relevant to your company, and you are
responsible for it, and you noticed something unusual, why would you
not want to come screaming to the list (like it did, my excuses), to
look for help, but 'conveniently avoid' mentioning that serious error
message during the upgrade? You need the box to be up and running, and
adding this error message can only help; so why would you suppress it,
maybe preventing efficient help to be offered?

I fully agree that what I report sounds highly unlikely. But it is
true, and by now I confirmed exactly the same having happened on that
other box (i386), If I suppressed anything, why should I add to the
improbability? Yes, it happened, and I applied the same method and
have by now tar xzvphf-ed the 70+ sbin-files that were there and -
identically to the previous amd64 - are from version 4.6.
It is not excluded, as I wrote earlier, that the upgrade itself does
everything 100% correct. Who knows, there can always be a rogue
package. Not that I'm saying this has happened, but theoretically, any
package could contain 4.6-files and write them back at pkg_add.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Richard Toohey
On 3/06/2010, at 8:42 PM, Uwe Dippel wrote:

[cut]
> No, that seriously turns me off. I have given everything in detail
> that I came across, I have not been silent about any additional
> message, any unusual activity. I have stated a few times that I
> followed the upgrade procedure to the dot, I have confirmed that
> nothing unusual showed.
[cut]

<quote>everything in detail ... I have not been silent</unquote>

I think that is the point that people are trying to make - you've sent
so much to the list that it is hard to keep up.  The people who can
help may not want to wade through 20 emails to keep up with you.

Take a deep breath.  Take a 4.6 CD install on a spare clean machine and
upgrade via the CD.   Problem there?  Yes/no.

Start again with the 4.6 CD a CLEAN install, upgrade via your normal process
to 4.7.  Is the issue there?  Yes/no.

And then follow the other suggestions from minds wiser than mine.

So far as you are aware, if you upgrade amd64 from a 4.6 CD to a 4.7 via
your normal upgrade process, there are issues - correct?  If so, I've got
a spare amd64 box to try on, but to be honest I'm a bit intimated by the
volume of mail you've sent - I'm losing the thread.

HTH.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Jan Stary
In reply to this post by udippel (Bugzilla)
On Jun 03 16:42:58, Uwe Dippel wrote:

> On Thu, Jun 3, 2010 at 3:20 PM, Tony Abernethy <[hidden email]> wrote:
>
> > The error message(s) you are suppressing (or maybe didn't see)
> >
> > About the only way you can get some files but not all files
> > from a tarball is some fatal error in the extraction of the
> > tarball. Any such error tends to give an error message.
> > I don't think this list likes to play guessing games as to exactly
> > what mistakes you have made or what evidence you are suppressing.
>
> Oh, how beautiful! This is a sign of mutual trust. I documented
> everything from the first pfctl after reboot from upgrade not working,
> for what I am chided; and still, I am supposed to 'suppress evidence'.
> How nice of you!
> And if I present a serial log, I will have been suspected to have
> tempered with it?

Where is the complete serial log of the install
and subsequent md5 checks? Because that's the only
way anybody can see what really happened, you know.

> But to start kind of asking for 'proof', that's what's ridiculous, to
> cite Theo.

No. You claim the installer of 4.7 installs some, but not all,
of the files in the install sets; or that some of the files instal 4.7
install sets are actually 4.6 files, according to their md5 hashes.
That's what's highly suspectible (if not ridiculous). Don't be surprised
that people want to be sure this actually happened before they invest
time into investigating it.

> I am willing to give individuals unprivileged access to the
> boxes, I did this before, to look around.

That's not a substitute for the complete, unedited serial log
of everything that happend from the moment you put an official CD in
to the moment you run the md5 test (included). Having root account
on your machine will not give me this information.

> I fully agree that what I report sounds highly unlikely. But it is
> true, and by now I confirmed exactly the same having happened on that
> other box (i386),

Where's the two complete serial logs?

> If I suppressed anything, why should I add to the
> improbability? Yes, it happened, and I applied the same method and
> have by now tar xzvphf-ed the 70+ sbin-files that were there and -

That were _where_? Do you claim that the base47.tgz file contains
4.6 versions of certain files in /sbin? Where exactly does this
strange base47.tgz file come from?

> identically to the previous amd64 - are from version 4.6.
> It is not excluded, as I wrote earlier, that the upgrade itself does
> everything 100% correct. Who knows, there can always be a rogue
> package. Not that I'm saying this has happened, but theoretically, any
> package could contain 4.6-files and write them back at pkg_add.

Packages install under /usr/local and don't interfere
with files from a base install.

Jan

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Richard Toohey
In reply to this post by Richard Toohey
On 3/06/2010, at 9:02 PM, Richard Toohey wrote:

> On 3/06/2010, at 8:42 PM, Uwe Dippel wrote:
>
> [cut]
>> No, that seriously turns me off. I have given everything in detail
>> that I came across, I have not been silent about any additional
>> message, any unusual activity. I have stated a few times that I
>> followed the upgrade procedure to the dot, I have confirmed that
>> nothing unusual showed.
> [cut]
>
> <quote>everything in detail ... I have not been silent</unquote>
>
> I think that is the point that people are trying to make - you've sent
> so much to the list that it is hard to keep up.  The people who can
> help may not want to wade through 20 emails to keep up with you.
>
> Take a deep breath.  Take a 4.6 CD install on a spare clean machine and
> upgrade via the CD.   Problem there?  Yes/no.
>
> Start again with the 4.6 CD a CLEAN install, upgrade via your normal
process
> to 4.7.  Is the issue there?  Yes/no.
>
> And then follow the other suggestions from minds wiser than mine.
>
> So far as you are aware, if you upgrade amd64 from a 4.6 CD to a 4.7 via
> your normal upgrade process, there are issues - correct?  If so, I've got
> a spare amd64 box to try on, but to be honest I'm a bit intimated by the
> volume of mail you've sent - I'm losing the thread.
>
OK, I've tried it and cannot reproduce what you see.  I've never done
an upgrade from bsd.rd before, so wanted to give it a go.

Obviously something different with your set-up, or where you got the files
from, or factor X - but as other people have said, they can't guess what.

In short - the basic bsd.rd "follow these instructions" worked for me here.

OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release)

uname -a
OpenBSD dellamd64.home 4.6 GENERIC#0 amd64

But before I upgrade, what's /sbin/pfctl?

$ ls -l /sbin/pfctl
-r-xr-xr-x  1 root  bin  492664 Dec  3 23:12 /sbin/pfctl
$ md5 /sbin/pfctl
MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7

http://openbsd.org/faq/upgrade47.html

"One easy way to boot from the install kernel is to place the 4.7 version of
bsd.rd in the root of your boot drive, then instruct the
 boot loader to boot using this new bsd.rd file. On amd64 and i386, you do
this by entering "boot bsd.rd" at the initial boot> prompt."

OK, I'll get the bsd.rd from the 4.7 release CD (but could have used FTP.)

/usr/bin/su root
mv /bsd.rd /bsd46.rd
mount /dev/cd0a /mnt/
cp /mnt/4.7/amd64/bsd.rd /bsd.rd
umount /mnt
eject /dev/cd0a
reboot
... boot > boot bsd.rd
... Welcome to the OpenBSD/amd64 4.7 installation program.
... I choose upgrade ... take defaults all the way until ...
Location of sets?  [What do I do here?  I'll try http, and take the defaults.
What did YOU do here?]
bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz,
xbase47.tgz
xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors.
... rest of install, reboot ...
$ uname -a
OpenBSD dellamd64.home 4.7 GENERIC#112 amd64
$ ls -l /sbin/pfctl
-r-xr-xr-x  1 root  bin  500856 Mar 18 15:36 /sbin/pfctl
$ md5 /sbin/pfctl
MD5 (/sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4

> HTH.
>
> Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Stuart Henderson
In reply to this post by udippel (Bugzilla)
On 2010-06-03, Uwe Dippel <[hidden email]> wrote:
>
> No, that seriously turns me off. I have given everything in detail
> that I came across,

The problem is obviously relating to something that you didn't
come across otherwise you wouldn't be posting here - if you can post
logs this will give more people a chance to spot it..

Ideally send everything right back to the boot messages from bsd.rd.

The request for unedited is because some people will "tidy things
up" before posting, which might remove something that other people
would find important.

On a hunch: what does stat /sbin/pfctl say?


>                          Who knows, there can always be a rogue
> package. Not that I'm saying this has happened, but theoretically, any
> package could contain 4.6-files and write them back at pkg_add.

You'll get a clearly visible error if the hash doesn't match that
stored in the install kernel.

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
In reply to this post by Richard Toohey
On Thu, Jun 3, 2010 at 7:18 PM, Richard Toohey
<[hidden email]> wrote:

> OK, I've tried it and cannot reproduce what you see.  I've never done
> an upgrade from bsd.rd before, so wanted to give it a go.
>
> Obviously something different with your set-up, or where you got the files
> from, or factor X - but as other people have said, they can't guess what.
>
> In short - the basic bsd.rd "follow these instructions" worked for me here.
>
> OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release)
>
> uname -a
> OpenBSD dellamd64.home 4.6 GENERIC#0 amd64
>
> But before I upgrade, what's /sbin/pfctl?
>
> $ ls -l /sbin/pfctl
> -r-xr-xr-x  1 root  bin  492664 Dec  3 23:12 /sbin/pfctl
> $ md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7
>
> http://openbsd.org/faq/upgrade47.html
>
> "One easy way to boot from the install kernel is to place the 4.7 version of
bsd.rd in the root of your boot drive, then instruct the
>  boot loader to boot using this new bsd.rd file. On amd64 and i386, you do
this by entering "boot bsd.rd" at the initial boot> prompt."

>
> OK, I'll get the bsd.rd from the 4.7 release CD (but could have used FTP.)
>
> /usr/bin/su root
> mv /bsd.rd /bsd46.rd
> mount /dev/cd0a /mnt/
> cp /mnt/4.7/amd64/bsd.rd /bsd.rd
> umount /mnt
> eject /dev/cd0a
> reboot
> ... boot > boot bsd.rd
> ... Welcome to the OpenBSD/amd64 4.7 installation program.
> ... I choose upgrade ... take defaults all the way until ...
> Location of sets?  [What do I do here?  I'll try http, and take the
defaults.  What did YOU do here?]
> bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz,
xbase47.tgz
> xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors.
> ... rest of install, reboot ...
> $ uname -a
> OpenBSD dellamd64.home 4.7 GENERIC#112 amd64
> $ ls -l /sbin/pfctl
> -r-xr-xr-x  1 root  bin  500856 Mar 18 15:36 /sbin/pfctl
> $ md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4

Thanks, Richard.

No, you couldn't encounter it.
It comes in later.
I have now the whole upgrade session of my third machine, the log is > 2 MB.
Whenever I rebooted, it was okay:
1. reboot to start bsd.rd - okay
2. reboot directly after bsd.rd upgrade - okay
3. reboot after 'Final steps', before pkg_add - okay
4. reboot after 'Upgrading packages' - okay
5. reboot after patching - old files and wrong timestamps - bummer, as
Theo might say.

I wonder if I can put the file up into the open, or if it contains
security-related matter.??
As bz2 it is just 91 k; I will of course make it available to
individuals on request.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
On Fri, Jun 4, 2010 at 2:18 PM, Uwe Dippel <[hidden email]> wrote:

> 5. reboot after patching - old files and wrong timestamps - bummer, as
> Theo might say.

Sorry, guys, (too quick as too often), just cat-grep pfctl shows where
the old one comes in:

pfctl: pf already enabled
# ls -l # ls -l /etc/# ls -l /sbin/pfctl
-r-xr-xr-x  1 root  bin  500856 Mar 18 10:36 /sbin/pfctl
# ls -l # ls -l /sbin/     # ls -l # ls -l /sbin/pfctl # ls -l
/sbin/pfctl
-r-xr-xr-x  1 root  bin  500856 Mar 18 10:36 /sbin/pfctl
-r-xr-xr-x  1 root  bin        500856 Mar 18 10:36 pfctl
# pfctl -f # pfctl -f /etc/# pfctl -f # pfctl -f /etc/pf.conf# pfctl
-f /etc/pf.conf
# # pfctl -e
pfctl: pf already enabled
# # pfctl -d
# # pfctl -e
===> pfctl
/usr/src/sbin/pfctl/obj -> /usr/obj/sbin/pfctl
===> pfctl
===> pfctl
nroff -Tascii -mandoc /usr/src/sbin/pfctl/pfctl.8 > pfctl.cat8
===> pfctl
install -c -s -o root -g bin  -m 555 pfctl /sbin/pfctl
install -c -o root -g bin -m 444 pfctl.cat8 /usr/share/man/cat8/pfctl.0
pfctl: DIOCBEGINADDRS: Operation not supported by device
pfctl: DIOCBEGINADDRS: Operation not supported by device
-r-xr-xr-x  1 root  bin        492664 Jun  4 13:28 pfctl

Through patching outdated(?) source files; though with the proper time stamp:
# cd /home/ftp/pub/OpenBSD/4.7
# ls -l
-r-xr-xr-x  1 root  ftp  131759003 Mar 21 19:17 src.tar.gz
-rw-r--r--  1 root  ftp   20668814 Mar 21 19:17 sys.tar.gz
# md5 src.tar.gz
MD5 (src.tar.gz) = 5214cd951cac5b7fbd89c968d1b5f859
# md5 sys.tar.gz
MD5 (sys.tar.gz) = 566c0cd7c3d2f28b17a9795324ead6ff

Maybe TeXitoi was right, after all, when he mentioned corrupted files
on some mirrors?
I wouldn't bet on it, but usually our fastest mirror here is
ftp://ftp.jaist.ac.jp.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

patrick keshishian
In reply to this post by udippel (Bugzilla)
On Thu, Jun 3, 2010 at 11:18 PM, Uwe Dippel <[hidden email]> wrote:

> On Thu, Jun 3, 2010 at 7:18 PM, Richard Toohey
> <[hidden email]> wrote:
>
>> OK, I've tried it and cannot reproduce what you see.  I've never done
>> an upgrade from bsd.rd before, so wanted to give it a go.
>>
>> Obviously something different with your set-up, or where you got the files
>> from, or factor X - but as other people have said, they can't guess what.
>>
>> In short - the basic bsd.rd "follow these instructions" worked for me
here.

>>
>> OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release)
>>
>> uname -a
>> OpenBSD dellamd64.home 4.6 GENERIC#0 amd64
>>
>> But before I upgrade, what's /sbin/pfctl?
>>
>> $ ls -l /sbin/pfctl
>> -r-xr-xr-x  1 root  bin  492664 Dec  3 23:12 /sbin/pfctl
>> $ md5 /sbin/pfctl
>> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7
>>
>> http://openbsd.org/faq/upgrade47.html
>>
>> "One easy way to boot from the install kernel is to place the 4.7 version
of

> bsd.rd in the root of your boot drive, then instruct the
>>  boot loader to boot using this new bsd.rd file. On amd64 and i386, you do
> this by entering "boot bsd.rd" at the initial boot> prompt."
>>
>> OK, I'll get the bsd.rd from the 4.7 release CD (but could have used FTP.)
>>
>> /usr/bin/su root
>> mv /bsd.rd /bsd46.rd
>> mount /dev/cd0a /mnt/
>> cp /mnt/4.7/amd64/bsd.rd /bsd.rd
>> umount /mnt
>> eject /dev/cd0a
>> reboot
>> ... boot > boot bsd.rd
>> ... Welcome to the OpenBSD/amd64 4.7 installation program.
>> ... I choose upgrade ... take defaults all the way until ...
>> Location of sets?  [What do I do here?  I'll try http, and take the
> defaults.  What did YOU do here?]
>> bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz,
> xbase47.tgz
>> xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors.
>> ... rest of install, reboot ...
>> $ uname -a
>> OpenBSD dellamd64.home 4.7 GENERIC#112 amd64
>> $ ls -l /sbin/pfctl
>> -r-xr-xr-x  1 root  bin  500856 Mar 18 15:36 /sbin/pfctl
>> $ md5 /sbin/pfctl
>> MD5 (/sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
>
> Thanks, Richard.
>
> No, you couldn't encounter it.
> It comes in later.
> I have now the whole upgrade session of my third machine, the log is > 2
MB.
> Whenever I rebooted, it was okay:
> 1. reboot to start bsd.rd - okay
> 2. reboot directly after bsd.rd upgrade - okay
> 3. reboot after 'Final steps', before pkg_add - okay
> 4. reboot after 'Upgrading packages' - okay
> 5. reboot after patching - old files and wrong timestamps - bummer, as
> Theo might say.

you mean applying the errata47.html patches? If so, are you certain
your source tree is tagged OPENBSD_4_7 and not anything else?

--patrick


> I wonder if I can put the file up into the open, or if it contains
> security-related matter.??
> As bz2 it is just 91 k; I will of course make it available to
> individuals on request.
>
> Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

Richard Toohey
On 4/06/2010, at 6:41 PM, patrick keshishian wrote:

> On Thu, Jun 3, 2010 at 11:18 PM, Uwe Dippel <[hidden email]> wrote:
>> On Thu, Jun 3, 2010 at 7:18 PM, Richard Toohey
>> <[hidden email]> wrote:
>>
>>> OK, I've tried it and cannot reproduce what you see.  I've never done
>>> an upgrade from bsd.rd before, so wanted to give it a go.
>>>
>>> Obviously something different with your set-up, or where you got the
files

>>> from, or factor X - but as other people have said, they can't guess what.
>>>
>>> In short - the basic bsd.rd "follow these instructions" worked for me
> here.
>>>
>>> OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release)
>>>
>>> uname -a
>>> OpenBSD dellamd64.home 4.6 GENERIC#0 amd64
>>>
>>> But before I upgrade, what's /sbin/pfctl?
>>>
>>> $ ls -l /sbin/pfctl
>>> -r-xr-xr-x  1 root  bin  492664 Dec  3 23:12 /sbin/pfctl
>>> $ md5 /sbin/pfctl
>>> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7
>>>
>>> http://openbsd.org/faq/upgrade47.html
>>>
>>> "One easy way to boot from the install kernel is to place the 4.7 version
> of
>> bsd.rd in the root of your boot drive, then instruct the
>>> boot loader to boot using this new bsd.rd file. On amd64 and i386, you do
>> this by entering "boot bsd.rd" at the initial boot> prompt."
>>>
>>> OK, I'll get the bsd.rd from the 4.7 release CD (but could have used
FTP.)

>>>
>>> /usr/bin/su root
>>> mv /bsd.rd /bsd46.rd
>>> mount /dev/cd0a /mnt/
>>> cp /mnt/4.7/amd64/bsd.rd /bsd.rd
>>> umount /mnt
>>> eject /dev/cd0a
>>> reboot
>>> ... boot > boot bsd.rd
>>> ... Welcome to the OpenBSD/amd64 4.7 installation program.
>>> ... I choose upgrade ... take defaults all the way until ...
>>> Location of sets?  [What do I do here?  I'll try http, and take the
>> defaults.  What did YOU do here?]
>>> bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz,
>> xbase47.tgz
>>> xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors.
>>> ... rest of install, reboot ...
>>> $ uname -a
>>> OpenBSD dellamd64.home 4.7 GENERIC#112 amd64
>>> $ ls -l /sbin/pfctl
>>> -r-xr-xr-x  1 root  bin  500856 Mar 18 15:36 /sbin/pfctl
>>> $ md5 /sbin/pfctl
>>> MD5 (/sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
>>
>> Thanks, Richard.
>>
>> No, you couldn't encounter it.
>> It comes in later.
>> I have now the whole upgrade session of my third machine, the log is > 2
> MB.
>> Whenever I rebooted, it was okay:
>> 1. reboot to start bsd.rd - okay
>> 2. reboot directly after bsd.rd upgrade - okay
>> 3. reboot after 'Final steps', before pkg_add - okay
>> 4. reboot after 'Upgrading packages' - okay
>> 5. reboot after patching - old files and wrong timestamps - bummer, as
>> Theo might say.
>
> you mean applying the errata47.html patches? If so, are you certain
> your source tree is tagged OPENBSD_4_7 and not anything else?
>
> --patrick
I think we are getting closer, aren't we?

So, NOTHING to do with the actual upgrade, is it?  Or the ports/packages.

It is something to do with how you are PATCHING after an upgrade.

You don't mention where/when you get the source you patch?

Because that would be a separate step, wouldn't it?

(I usually install from CD, so I scrub /usr/src & load from src.tar.gz on the
CD.)

>
>
>
>> I wonder if I can put the file up into the open, or if it contains
>> security-related matter.??
>> As bz2 it is just 91 k; I will of course make it available to
>> individuals on request.
>>
>> Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64

udippel (Bugzilla)
In reply to this post by patrick keshishian
On Fri, Jun 4, 2010 at 2:41 PM, patrick keshishian <[hidden email]> wrote:

> you mean applying the errata47.html patches? If so, are you certain
> your source tree is tagged OPENBSD_4_7 and not anything else?

Do I understand you correctly? I am not building releases. I am
installing/downloading the sets; then I do all the stuff in 'Upgrade
guide', then

rm -Rf * in /usr/src
rm -Rf * in /usr/xenocara
rm -Rf * in /usr/ports,
and then tar ... the source files meticulously as pointed out in the guide:
# cd /usr/src
# tar xzf ../sys.tar.gz
# tar xzf ../src.tar.gz
# cd /usr
# tar xzf xenocara.tar.gz
# tar xzf ports.tar.gz
and then download the patches into /usr/src, then applying them....
and this is what you would see in the serial log.
So I don't tag, because I don't cvs; what i do is just download the 4
files. (Also see my other post, it points clearly to the sequence and
the reboots done, with always checking pfctl after each reboot.)

Uwe

1234