On Sat, Nov 3, 2012 at 9:08 AM, Alexander Yerenkow <yeren...@gmail.com>wrote:
> Actually in my case, base system image r24243.vmdk, have exactly two > partitions (gpt's freebsd-boot, and roots = freebsd-ufs), and second one is > used only in read-only :) > > For virtual machines approach, base image can be even ISO, which will be > implied RO for system, and upgrade is just switch ISO. > > For real hardware, it can be done with such approach - make two partitions > with fixed size, and when you need upgrade - just `dd` new image to other > partition, mark it as [bootonce] (And if all is ok, as [bootme]), reboot = > and you have new OS very quick, with same configs (except for some LARGE > changes which could happen in /etc and touch your configs), and with same > packages. > > BTW, when you mount /etc-rw union over /etc, when you'll need upgrade, > mergemaster could take less time, less places for errors - since you had to > merge only changed files(which present on /etc-rw). > I think these days with current hw, no one will complain against lost 1Gb > to achieve clean and simple OS upgrade. > > I'm not saying about possible way to shrink it further (no debug, gzip, > etc) - get lesser partition, but still RO, and get ability to make > something dd if=/dev/gpt/rootfs bs=1M | sha256 > > > -- > Regards, > Alexander Yerenkow > I am assuming that ANY SOFTWARE read-only protection , whatever it is , has security vulnerability . Therefore , the first approach should be to provide HARDWARE read only . If this is supplied , the next necessity is that , programs in write-protected part should not attempt to write anything onto write-protected part . Thank you very much . Mehmet Erol Sanliturk _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
