Date: Fri, 29 Aug 2014 10:42:19 -0400 From: Rick Miller <vmiller@hostileadmin.com> To: "Martin G. McCormick" <martin@server1.shellworld.net> Cc: "questions@freebsd.org" <questions@freebsd.org> Subject: Re: Recreating the FreeBSD Installation Disks Message-ID: <CAHzLAVHYUNpTJiy_TKD8H9%2BzbXZKzDCTCAA3fp=BXZ7kHQX2XA@mail.gmail.com> In-Reply-To: <20140827142517.CF67A228B7@server1.shellworld.net> References: <20140827142517.CF67A228B7@server1.shellworld.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I realize I'm late in the game...inline... On Wed, Aug 27, 2014 at 10:25 AM, Martin G. McCormick < martin@server1.shellworld.net> wrote: > I have been asking lots of questions recently about > whether the procedure for building a custom FreeBSD installation > CD has changed and it apparently has not but the problem I am > having is not hard to define. > The original image downloaded from freebsd.org is: > FreeBSD-9.1-RELEASE-amd64-disc1.iso and it is > 718862336 bytes large. > I mounted it on a FreeBSD9 system as follows: > ##Set up memory disk. > # mdconfig -f FreeBSD-9.1-RELEASE-amd64-disc1.iso -u 1 > ##Mount it. > #mount -t cd9660 /dev/md1 /mnt2 > Everything looks normal if you ls /mnt2. > If one was to use mkisofs with /mnt2 as the top of the tree, a > new iso image file should appear somewhere that is about the > same size as the starting ISO file. As a test to see if this > happens, I did the following: > # mkisofs -J -R -V customBSD -no-emul-boot -b boot/cdboot -iso-level 3 > -o \ > #/home/martin/tmp/serialcd64.iso . > #ls -l /home/martin/serialcd64.iso > -rw-r--r-- 1 root martin 833892352 Aug 26 10:48 serialcd64.iso > > Man! I sure wish my pay check could do that after a week of > living. > I know that hard links will make tar and rsync produce > larger outputs if not called correctly. My understanding is that > hard links are multiple sets of inode numbers pointing to the > same files so they are hard to mechanically distinguish from > actual disk space being occupied by the same data in more than > one spot. > When one needs to make a custom CD, the extremely > difficult part is recreating the steps that were used to > originally build the image. > An amusing side note; I used rsync to create a writable > copy of the tree as follows: > #cd ./treetop > #sudo rsync -a /mnt2/ ./ > A few seconds later, I had something that built without > a single complaint so I made an image out of treetop and got: > #ls -l custom* > -rw-r--r-- 1 martin martin 455213056 Aug 26 11:42 custom.iso > That was the exact same file tree that insists on being > 120 MB too large if you try to make a straight ISO image from > the mounted file system of the original image which is about 300 > MB larger than this one. > That has been pretty much the story of the last few days > and I am running out of things to try. The process for building > the FreeBSD installation CD is clever since it manages to cram > so much in to the limited space without compressing the entire > image. So far, orthogonalness has escaped me at every turn. > You have already been back and forth working on this via the list and I have nothing very meaningful to contribute except that I encountered a problem using the 10.0-RELEASE bootonly ISO on a few bare metal chassis' (though 8.0-RELEASE bootonly ISO has worked nearly 4 years installing 8.x). A solution to the problem, described in PR190939[1], has not been determined. However, switching from the bootonly ISO to mfsBSD[2] has, thus far, proven successful in performing fully automated, non-interactive installs. mfsBSD provides several advantages over the ISO including, but not limited to, being mounted rw (as opposed to ro in the ISO) and it's much smaller footprint (~40MB image vs 200MB+ ISO). Perhaps mfsBSD can be considered as an alternate installation media? [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190939 [2] http://mfsbsd.vx.sk -- Take care Rick Miller
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHzLAVHYUNpTJiy_TKD8H9%2BzbXZKzDCTCAA3fp=BXZ7kHQX2XA>