P.S. Just in case if somebody wants to integrate this method into FreeBSD liveCD build, we do a bit of trick there by making normal ISO9660 file system with compressed kernel and relevant boot pieces and then also sticking in BSD label on the same disk image. It turns out ISO9660 and BSD disklabel structures do not overlap, so it works nicely since 2005 or so. Then we append UFS image compressed with mkuzip at the end of it. Resulting image can be used just as any ISO would. We also cook up UFS with unique label and then use GEOM_LABEL to easily find relevant file system on boot regardless of the physical device name. mkuzip -dL -S -s 65536 -o ${UZPFILE} ${UFSFILE} mkisofs -b boot/${CDBOOT} -no-emul-boot -r -o ${ISOFILE} ${CDIR} eval $(stat -s ${UZPFILE}) UZPSIZE=$((st_size + 2048 - (st_size % 2048))) truncate -s ${UZPSIZE} ${UZPFILE} eval $(stat -s ${ISOFILE}) ISOSIZE=${st_size} echo "bytes/sector: 2048" > ${TDIR}/label.txt echo "sectors/unit: $(((UZPSIZE + ISOSIZE) / 2048))" >> ${TDIR}/label.txt echo "a: $((UZPSIZE / 2048)) $((ISOSIZE / 2048)) unused" >> ${TDIR}/label.txt echo "c: $(((UZPSIZE + ISOSIZE) / 2048)) 0 unused" >> ${TDIR}/label.txt truncate -s $((ISOSIZE + UZPSIZE)) ${ISOFILE} disklabel -A -R -f ${ISOFILE} ${TDIR}/label.txt truncate -s ${ISOSIZE} ${ISOFILE} cat ${UZPFILE} >> ${ISOFILE} -Max On Mon, Jul 11, 2016 at 4:28 PM, Chris H <bsd-lists_at_bsdforge.com> wrote: > On Mon, 11 Jul 2016 18:39:51 -0400 Allan Jude <allanjude_at_freebsd.org> > wrote > > > On 2016-07-11 18:33, Chris H wrote: > > > On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov <slw_at_zxy.spb.ru> > > > wrote > > > >> On Mon, Jul 11, 2016 at 09:41:44PM +0000, Glen Barber wrote: > > >> > > >>> On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > > >>>>> On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop <ronald-lists_at_klop.ws > > > > >>>> wrote: >> Hi, > > >>>>>> > > >>>>>> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a > CD on > > >>>>>> Windows 10. It complained that the ISO is too big for my 700 MB > CD-r. > > >>>>>> > > >>>>>> The bootonly iso (281MB) burns and runs ok. > > >>>>>> > > >>>>>> Regards, > > >>>>>> Ronald. > > >>>> > > >>>> Please open a PR. Those images should be able to fit on a CD. > > >>> > > >>> This was actually a known "going to be problem" thing for 11.0. I'm > > >>> looking into how to fix this for 11.0-RELEASE, but right now, there > is > > >>> not much more we can exclude from it. :( > > > Can't it use the compressed iso format, or is it already using that > > > format. Sorry haven't checked. > > >> > > >> Reduce GENERIC to MINIMAL? > > > > > > --Chris > > > > > > > > > _______________________________________________ > > > freebsd-current_at_freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe_at_freebsd.org" > > > > > > > 380MB of the data on disc1 is the distsets, which are already .txz (max > > compression). That doesn't leave much room for the live OS on the disk. > I'm not sure I was clear enough when I responded. So, just for the record; > I meant the ISO data itself, not the image per se; > that is, not disc-1.iso.txz. But rather mounting a compressed file system. > Be it bz2, or xz(1). I seem to remember tar(1) providing examples about > creating/mounting compressed archives as iso images, and then writing > them as an iso image, that can be later burned to CD/DVD. Another option > that I employ, when creating CD/DVD images, is to take a dump(8) of > the data I intend to create the image of. This method removes the "slack" > from the data/files/dirs, before writing the image -- all the nodes > are contiguous, end-for-end. So there is no wasted space. > > > > > -- > > Allan Jude > > --Chris > > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > >Received on Mon Jul 11 2016 - 22:23:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC