On 03/14/11 19:20, Dan Mack wrote: > On Mar 14, 2011, at 9:13 AM, Nathan Whitehorn wrote: > >> I just committed (r219641) changes that make the release infrastructure (src/release/Makefile) use bsdinstall by default instead of sysinstall on install media. A big thank you is in order to everyone who provided advice, criticism, and testing for this project over the last few months! >> >> Along with sysinstall, the original sysinstall build stuff has been preserved (now /usr/src/release/Makefile.sysinstall) and will continue to be for the lifetime of the 9.x release series, although it will not be used by default. This change modifies the process of building releases somewhat, so I'll outline changes that people who run snapshot buildbots will have to make below, and some next steps planned with the installer. >> >> Changes to release(7) >> ----------------------------- >> >> Release builds work and look slightly different now, so everyone who snapshot tinderboxes will likely find them breaking shortly. The nearest analog to the old make release (with version-control checkouts and a chroot) is src/release/generate-release.sh, which can be run as generate-release.sh head /path/to/chroot/dir. If you want to include ports and documentation on the release media, CVSUP_HOST must be defined in the environment to point to a cvsup mirror. The output is placed in /R in the chroot directory, as before. >> >> If the chroot is unimportant (it ensures a total clean-room build, but may not be necessary in most cases), you can get a release build using the regular makefile, like so: >> cd /usr/src >> make buildworld buildkernel >> cd /usr/src/release >> make obj release >> >> >> > <snip> > > Thanks! For what it's worth, I built a new release using this new method and the only problem I ran into was getting dropped to the "mountroot>" because the memstick's root partition failed to mount. I am not sure if this has anything to do with your changes or not but I thought I would bring it up. After mounting my usb stick with : ufs:/dev/da0a it booted into bsdinstall without issue. I don't know if this was do to kern.cam.boot_delay not being long enough or if it was a problem with the creation of the memstick image. Hm. I'd be interested to know if this is repeatable. The memstick stuff is a fairly new feature, and so hasn't been tested to quite the same degree as the ISOs. In case anyone else wants to try it, there is a memstick image (and ISO) here: http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110313/ > During bsdinstall, there were a bunch of console debug messages spewing alongside the bsdinstall text but they cleared before I could take a picture. Yes, there seem to be some LORs in UFS that get triggered if you untar massive quantities of files very fast. They seem harmless, though. > Now we just need a ZFS template for the partition tool :-) Yes. Hopefully this comes in through collaboration with the pc-sysinstall people. Having gptboot and gptzfsboot be the same thing would also help a great deal toward that goal. > Thanks again! > Glad you liked it! -NathanReceived on Sat Mar 19 2011 - 00:56:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:12 UTC