For those of us subscribed to the freebsd-mobile mailling list, some of the more recent postings are both alarming and hilarious, at the expense of George Neville-Neil, a well-known name in the circles of ACM and FreeBSD.
See, in received order, messages 1, 2, 3, and 4.
I’m sure more will follow. LinkedIn will hopefully be able to stop this nonsense. It’s a sad example of identity theft, and more of that sort is regrettably on the rise.
I have attempted to migrate a running i386 stable/9 system into a running amd64 stable/9 system, and attempted to migrate a running i386 stable/10 system into a running amd64 stable/10 system, only to see if these tasks are in fact feasible. The results speaks for themselves, given the boundary conditions outlined below.
If your system has a separate root filesystem of less than 1 GiB, then I suggest you consider scrapping the 32-bit system altogether, and install a fresh 64-bit system. If you wish to continue having a separate root filesystem, make that filesystem no smaller than 2 GiB to accommodate future expansion. You may gain additional free space by deleting
/boot/kernel*/*.symbols prior to installing a new kernel. If this isn’t good enough, then you should limit the modules installed using the
MODULES_OVERRIDE directive in your kernel configuration file.
The boundary conditions are:
- base built from the appropriate stable branch of the source code tree,
- amd64 snapshot for the appropriate stable branch to speed up parts of the transition,
- the system being able to run with the
GENERIC kernel until a new custom kernel is optionally installed,
- if your system needs a custom kernel to function properly, one can be precompiled on a spare 64-bit system and transferred to the subject at the right moment,
- ports built from the ports collection with
ports-mgmt/portmaster as a vital instrument, and
- the ports listed below.
Continue reading Migrating FreeBSD from i386 to amd64
Order has once again been restored. I have successfully upgraded 8.4-RELEASE (r251259) to stable/8 r277528, and further to stable/9 r277528, and finally to stable/10 r277559.
Work is underway enabling latest stable/8 to go directly to latest stable/9.
All my FreeBSD systems have run stable/something-something, compiled from source, for as long as I can remember. I compile and install all ports using the ports collection and portupgrade. I used pre-built binary packages only to get
up and running, a long, long time ago. I have almost never ended up in a situation from which I could not recover. Continue reading Upgrading FreeBSD from stable/8 to stable/9, and to stable/10
investerning (in-vest-er-ning eller in-ves-ter-ning)
utvilkling (u-tvil-kling eller ut-vil-kling)
Ref.: https://www.politi.no/vedlegg/rapport/Vedlegg_452.pdf, side 41 (side 43 rent fysisk).
The removal of BIND from base in stable/10, left us with the option of running BIND from ports either in a jail or as an ordinary service. The old BIND in base was able to run in a chroot environment, isolated from the rest of the system.
Some of us believe a chroot is a good compromise between running BIND as an unisolated service or in a jail. I personally believe the removal of
/var/named as part of
make delete-old is premature, as most of us would like to continue keeping all BIND related files in
Harald Schmalzbauer has been kind enough to recreate a chroot environment for
dns/bind910. I guess the same patch can be used for
Take a look at Harald’s contribution if you feel a jail is too much work for a simple service like DNS.
Enabling encrypted swap has changed in FreeBSD stable/10. I was interested in running AES-XTS with a 256 bit random key and a simulated blocksize of 4096 bytes.
I had to change the line in
/etc/fstab for the swap partition from
/dev/ada0s4b none swap sw 0 0
/dev/ada0s4b.eli none swap sw,keylen=256,sectorsize=4096 0 0
The kernel could then happily report:
GEOM_ELI: Device ada0s4b.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: software
Sitatet under er tatt ut av sammenhengen, men det er likevel en viss sannhet i de utvalgte ordene. Problemet er ikke unikt for Microsoft-systemer.
… likegyldighet er et problem for Microsoft, fordi dette er brukere som ikke klarer å holde maskinen sin oppdatert og som får installert all slags malware. Så blir de sinte og sure når internett ikke fungerer, men skjønner ikke at de selv er problemet …
DRADIS contact! Santa’s sleigh inbound.
It’s definitely friendly!
Have you been a good boy/girl this year?
The 20141214 entry in
AFFECTS: users of TeXLive
Several scripts in print/texlive-base have been moved to devel/tex-kpathsea. Upgrading them can fail because texlive-base depends on tex-kpathsea, and the new ex-kpathsea tries to install files which were installed by the old texlive-base. The following error message indicates this situation:
pkg-static: tex-kpathsea-6.2.0_1 conflicts with texlive-base-20140525_3 (installs files into the same place). Problematic file: /usr/local/bin/kpsewhere
To solve this problem, remove both of tex-kpathsea and texlive-base first and install the new versions:
# pkg delete -f tex-kpathsea texlive-base
The above is a bit drastic, at least for us who build our own ports. These two
portupgrade commands gets the job done, albeit with some overhead:
portupgrade -fprv print/texlive-base
portupgrade -fprv devel/tex-kpathsea