FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.0.0 2011-11-19T11:47:15Z 2011-11-19T11:47:15Z Pawel Jakub Dawidek pjd@FreeBSD.org 2011-11-19T11:47:15Z urn:sha1:fe185ed3af9c00e55f094aad5aa28e0bc84cee08 r226612: r226549: Remove redundant size calculation. r226550: Initialize 'rc' properly before using it. This error could lead to infinite loop when data reconstruction was needed. r226551: Don't mark vdev as healthy too soon, so we won't try to use invalid vdevs. r226552: Never pass NULL block pointer when reading. This is neither expected nor handled by lower layers like vdev_raidz, which uses bp for checksum verification. This bug could lead to NULL pointer reference and resets during boot. r226553: Always pass data size for checksum verification function, as using physical block size declared in bp may not always be what we want. For example in case of gang block header physical block size declared in bp is much larger than SPA_GANGBLOCKSIZE (512 bytes) and checksum calculation failed. This bug could lead to accessing unallocated memory and resets/failures during boot. r226554: Fix missing return when LOADER_GPT_SUPPORT is defined, but LOADER_MBR_SUPPORT is not. r226568: - Correctly read gang header from raidz. - Decompress assembled gang block data if compressed. - Verify checksum of a gang header. - Verify checksum of assembled gang block data. - Verify checksum of uber block. Submitted by: avg r226569: With LOADER_MBR_SUPPORT defined and LOADER_GPT_SUPPORT undefined we would never call disk_openmbr(). Submitted by: avg r226611: - Allow to specify multiple files to check, eg. zfsboottest gpt/system0 gpt/system1 - /boot/kernel/kernel /boot/zfsloader - Instead of printing file's content calculate MD5 hash of the file, so it can be easly compared to the hash calculated via file system. - Some other minor improvements. r226612: Because ZFS boot code was very fragile in the past and real PITA to debug, introduce zfsboottest.sh script that will verify if it will be possible to boot from the given pool. # zfsboottest.sh system Where "system" is pool name of the pool we want to boot from. What is being verified by the script: - Does the pool exist? - Does it have bootfs property configured? - Is mountpoint property of the boot dataset set to 'legacy'? Dataset configured in bootfs property has to be mounted to perform more checks: - Does the /boot directory in boot dataset exist? - Is this dataset configured as root file system in /etc/fstab or set in vfs.root.mountfrom variable in /boot/loader.conf? By using zfsboottest tool the script will read all the files in /boot directory using ZFS boot code and calculate their checksums. Then, it will walk /boot directory using find(1) though regular file sytem and also read all the files in /boot directory and calculate their checksums. If any of the files cannot be looked up, read or checksum is invalid it will be reported and booting off of this pool is probably not possible. Some additional checks may be interesting as well. For example if the disks contain proper pmbr and gptzfsboot code or if all expected files in /boot/ are present. When upgrading FreeBSD, one should snapshot datasets that contain operating system, upgrade (install new world and kernel) and use zfsboottest.sh to verify if it will be possible to boot from new configuration. If all is good one should upgrade boot blocks, by eg.: # gpart -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 If something is wrong, one should rollback datasets and report the problems. Approved by: re (kib) 2011-08-08T20:53:04Z Dimitry Andric dim@FreeBSD.org 2011-08-08T20:53:04Z urn:sha1:f989887b32ae34e93d3e708de7cfc90ce798572e large (>= 10^10) numbers. In theory, 20 characaters should be enough, but bump the buffer to 32 characters, so we have some room for the future. Reviewed by: pjd Approved by: re (kib) 2011-07-11T20:43:59Z Marius Strobl marius@FreeBSD.org 2011-07-11T20:43:59Z urn:sha1:fd70297a1daf4fd6d28c7bf394a551eadb2c484a bogusly casts its contents around causing alignment faults on sparc64 and most likely also on at least powerpc. Fix this by copying the contents bytewise instead as partly already done here. Solving this the right way costs some space, i.e. 148 bytes with GCC and 16 bytes with clang on x86 there are still some bytes left there though, and an acceptable hack which tricks the compiler into only using a 2-byte alignment instead of the native one when accessing the contents turned out to even take up more space that. 2011-07-01T18:31:59Z Marius Strobl marius@FreeBSD.org 2011-07-01T18:31:59Z urn:sha1:7d7a4ae1a7137b51785582937f5f071d21e5731a the MBR support in the common part of the loader in #ifdef's and enable it only for userboot for now. 2011-06-30T16:08:56Z Doug Rabson dfr@FreeBSD.org 2011-06-30T16:08:56Z urn:sha1:9777aa3f124a652e468da4d94d4cf0ed796b28ac as a shared library. This is intended to be used by BHyVe to load FreeBSD kernels into new virtual machines. 2011-06-19T13:35:41Z Alexander Kabaev kan@FreeBSD.org 2011-06-19T13:35:41Z urn:sha1:e1e52afa08eadcc61871cce000ac8c9db1a7c24d Some of loader filesystems are very ill equipped to handle seeking backwards within the file. Namely, tftp requires trasfer to be restarted from the start of the file every time we go backwards. 2011-05-28T08:50:38Z Julian Elischer julian@FreeBSD.org 2011-05-28T08:50:38Z urn:sha1:802e09ac9ee9473983514693e46d8f22012e7f1d Discussed on hackers and recommended for inclusion into 9.0 at the devsummit. All support email to devin dteske at vicor dot ignoreme dot com . Submitted by: dteske at vicor dot ignoreme dot com Reviewed by: me and many others 2011-05-14T01:53:38Z Attilio Rao attilio@FreeBSD.org 2011-05-14T01:53:38Z urn:sha1:4b547324c0a839a0ecd067638686112f6f7cc11e Some files keep the SUN4V tags as a code reference, for the future, if any rewamped sun4v support wants to be added again. Reviewed by: marius Tested by: sbruno Approved by: re 2011-05-07T13:57:30Z Andriy Gapon avg@FreeBSD.org 2011-05-07T13:57:30Z urn:sha1:4fe5d78a0f5965ce189cb60b8ec3e992bbb95cb9 Reminder from: kib MFC after: 4 days 2011-05-07T10:40:57Z Andriy Gapon avg@FreeBSD.org 2011-05-07T10:40:57Z urn:sha1:ff98e4c51524e01de1452b7b26f8fed64043423d MFC after: 4 days