Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Sepherosa Ziehau]

On Fri, Jul 15, 2016 at 7:13 AM, Glen Barber  wrote:
> With additional tweaks, I was able to get the CD to boot both with
> a real internal CD-ROM drive, as well as USB CD-ROM.
>
> I have uploaded a disc1.iso image here:
>
>  https://people.freebsd.org/~gjb/disc1_uzip.iso
>
> Could people try this on various hardware, KVM setups, and so on?  I'm

It works for me on Hyper-V.

Thanks,
sephe

-- 
Tomorrow Will Never Die
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

On Thu, Jul 14, 2016 at 11:13:56PM +, Glen Barber wrote:
> Could people try this on various hardware, KVM setups, and so on?  I'm
> mainly interested if you get to the bsdinstall(8) screen, not issues not
> directly related to using GEOM_UZIP to compress the image further.
> (Meaning, I'm not asking for people to do installs from this image.)
> 

I forgot to mention, the UEFI bits are not in place in this image, so
likely will not boot on UEFI-only systems.  This will be added after the
project branch is created and what I have now is added to the build
tools.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

With additional tweaks, I was able to get the CD to boot both with
a real internal CD-ROM drive, as well as USB CD-ROM.

I have uploaded a disc1.iso image here:

 https://people.freebsd.org/~gjb/disc1_uzip.iso

Could people try this on various hardware, KVM setups, and so on?  I'm
mainly interested if you get to the bsdinstall(8) screen, not issues not
directly related to using GEOM_UZIP to compress the image further.
(Meaning, I'm not asking for people to do installs from this image.)

The hashes are:
SHA512 (disc1_uzip.iso) =
560033cbc65932abb77ae85475f3a222fbdd8a35f99ac220f85028ede60a47305d62c5e8eab508bfb3f02f0d074a1dc3200f2a1e409408e34fa9808e800ad6df
SHA256 (disc1_uzip.iso) =
65edbc4ddca29af5f9f03f8a3026e06462f05400d70b79d4a8d0adf2ea875e33

I'll create the project branch shortly, and add the relevant bits
afterward.

Thank you.

Glen

On Thu, Jul 14, 2016 at 08:50:24PM +, Glen Barber wrote:
> Thank you for the additional information.
> 
> I finally found my old laptop's internal CD-ROM drive, so I'll be able
> to at least check if the issue is USB-related.  I just need to open the
> laptop to install it.  After which I'll tinker with the cluster sizes
> and test further.
> 
> Glen
> 
> On Wed, Jul 13, 2016 at 10:30:33PM -0700, Maxim Sobolev wrote:
> > Hi Glen, nice update, glad being of some help. The slowdown may be related
> > to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
> > typically, even if only single block from that cluster is requested. I
> > imagine it might impact rc.d, which is essentially bunch of small(ish)
> > shell scripts and I would not be surprised if their blocks would be
> > scattered all over the place. There is some very basic caching in the
> > geom_uzip module, but it is only one cluster deep. What might help if you
> > still have some room on the CD is to decrease cluster size (-s parameter of
> > mkuzip), to something like 32k or even 16k. That would make compression
> > less effective, but would reduce the I/O bandwidth waste, which could also
> > be important for the KVM setups. I might also look into making a bigger
> > cache, as RAM is getting cheaper and more abundant every day. Another
> > approach would be to make several "partitions", segregating for example
> > /etc stuff so it's all tighly packed together and you can also use smaller
> > cluster size for /etc and bigger for the rest. In any case, keep me posted
> > with your findings.
> > 
> > -Max
> > 
> > On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber  wrote:
> > 
> > > Just replying to the first email in the thread, since it's a general
> > > reply, and only related to the original topic at hand, and only for
> > > informative purposes at this point.
> > >
> > > On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> > > > 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.
> > > >
> > >
> > > I have *something* semi-working, with a huge amount of help from Maxim
> > > in private email.  There is still a nit or two to fix, I'm running into
> > > them as I rebuild the ISO after fixing the prior issue.  But, right now,
> > > I can get the ISO to boot enough to get to a shell (the "init failed due
> > > to inability to mount '/'" shell, but it is still a shell).  :)
> > >
> > > Once I get what I have now into a state where it's somewhat committable,
> > > I'm going to create a project branch to sand off the edges, instead of
> > > doing it directly in head, since there might be some edge cases for
> > > non-x86 architectures.  (But some other architectures do not have the
> > > "too big" problem.)
> > >
> > > Once that is merged, I fully intend to merge this to stable/11, provided
> > > there is no major fallout.  With what I have now, disc1.iso is 630M, and
> > > the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
> > > people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
> > > though, there appears to be a significantly non-zero speed decrease,
> > > though this may just be because my CD-ROM is USB-based.  When I have the
> > > ready-to-commit result, I'll test it on a machine with an internal CD
> > > drive.
> > >
> > > Glen
> > >
> > >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

Thank you for the additional information.

I finally found my old laptop's internal CD-ROM drive, so I'll be able
to at least check if the issue is USB-related.  I just need to open the
laptop to install it.  After which I'll tinker with the cluster sizes
and test further.

Glen

On Wed, Jul 13, 2016 at 10:30:33PM -0700, Maxim Sobolev wrote:
> Hi Glen, nice update, glad being of some help. The slowdown may be related
> to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
> typically, even if only single block from that cluster is requested. I
> imagine it might impact rc.d, which is essentially bunch of small(ish)
> shell scripts and I would not be surprised if their blocks would be
> scattered all over the place. There is some very basic caching in the
> geom_uzip module, but it is only one cluster deep. What might help if you
> still have some room on the CD is to decrease cluster size (-s parameter of
> mkuzip), to something like 32k or even 16k. That would make compression
> less effective, but would reduce the I/O bandwidth waste, which could also
> be important for the KVM setups. I might also look into making a bigger
> cache, as RAM is getting cheaper and more abundant every day. Another
> approach would be to make several "partitions", segregating for example
> /etc stuff so it's all tighly packed together and you can also use smaller
> cluster size for /etc and bigger for the rest. In any case, keep me posted
> with your findings.
> 
> -Max
> 
> On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber  wrote:
> 
> > Just replying to the first email in the thread, since it's a general
> > reply, and only related to the original topic at hand, and only for
> > informative purposes at this point.
> >
> > On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> > > 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.
> > >
> >
> > I have *something* semi-working, with a huge amount of help from Maxim
> > in private email.  There is still a nit or two to fix, I'm running into
> > them as I rebuild the ISO after fixing the prior issue.  But, right now,
> > I can get the ISO to boot enough to get to a shell (the "init failed due
> > to inability to mount '/'" shell, but it is still a shell).  :)
> >
> > Once I get what I have now into a state where it's somewhat committable,
> > I'm going to create a project branch to sand off the edges, instead of
> > doing it directly in head, since there might be some edge cases for
> > non-x86 architectures.  (But some other architectures do not have the
> > "too big" problem.)
> >
> > Once that is merged, I fully intend to merge this to stable/11, provided
> > there is no major fallout.  With what I have now, disc1.iso is 630M, and
> > the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
> > people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
> > though, there appears to be a significantly non-zero speed decrease,
> > though this may just be because my CD-ROM is USB-based.  When I have the
> > ready-to-commit result, I'll test it on a machine with an internal CD
> > drive.
> >
> > Glen
> >
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

> On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber  wrote:
> 
> > Just replying to the first email in the thread, since it's a general
> > reply, and only related to the original topic at hand, and only for
> > informative purposes at this point.
> >
> > On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> > > 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.
> > >
> >
> > I have *something* semi-working, with a huge amount of help from Maxim
> > in private email.  There is still a nit or two to fix, I'm running into
> > them as I rebuild the ISO after fixing the prior issue.  But, right now,
> > I can get the ISO to boot enough to get to a shell (the "init failed due
> > to inability to mount '/'" shell, but it is still a shell).  :)
> >
> > Once I get what I have now into a state where it's somewhat committable,
> > I'm going to create a project branch to sand off the edges, instead of
> > doing it directly in head, since there might be some edge cases for
> > non-x86 architectures.  (But some other architectures do not have the
> > "too big" problem.)
> >
> > Once that is merged, I fully intend to merge this to stable/11, provided
> > there is no major fallout.  With what I have now, disc1.iso is 630M, and
> > the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
> > people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
> > though, there appears to be a significantly non-zero speed decrease,
> > though this may just be because my CD-ROM is USB-based.  When I have the
> > ready-to-commit result, I'll test it on a machine with an internal CD
> > drive.
> >
> > Glen
> >
> >
On Wed, 13 Jul 2016 22:30:33 -0700 Maxim Sobolev  wrote

> Hi Glen, nice update, glad being of some help. The slowdown may be related
> to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
> typically, even if only single block from that cluster is requested. I
> imagine it might impact rc.d, which is essentially bunch of small(ish)
> shell scripts and I would not be surprised if their blocks would be
> scattered all over the place. There is some very basic caching in the
> geom_uzip module, but it is only one cluster deep. What might help if you
> still have some room on the CD is to decrease cluster size (-s parameter of
> mkuzip), to something like 32k or even 16k. That would make compression
> less effective, but would reduce the I/O bandwidth waste, which could also
> be important for the KVM setups. I might also look into making a bigger
> cache, as RAM is getting cheaper and more abundant every day. Another
> approach would be to make several "partitions", segregating for example
> /etc stuff so it's all tighly packed together and you can also use smaller
> cluster size for /etc and bigger for the rest. In any case, keep me posted
> with your findings.
> 
> -Max
> 
It's CPU, and IO bound mostly, and it's going to prove painful for some
with lesser powered hardware. But better than than the alternative. Right?

Hey, Glen. Just a nod, for taking the time to do this!

--Chris


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

Hi Glen, nice update, glad being of some help. The slowdown may be related
to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
typically, even if only single block from that cluster is requested. I
imagine it might impact rc.d, which is essentially bunch of small(ish)
shell scripts and I would not be surprised if their blocks would be
scattered all over the place. There is some very basic caching in the
geom_uzip module, but it is only one cluster deep. What might help if you
still have some room on the CD is to decrease cluster size (-s parameter of
mkuzip), to something like 32k or even 16k. That would make compression
less effective, but would reduce the I/O bandwidth waste, which could also
be important for the KVM setups. I might also look into making a bigger
cache, as RAM is getting cheaper and more abundant every day. Another
approach would be to make several "partitions", segregating for example
/etc stuff so it's all tighly packed together and you can also use smaller
cluster size for /etc and bigger for the rest. In any case, keep me posted
with your findings.

-Max

On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber  wrote:

> Just replying to the first email in the thread, since it's a general
> reply, and only related to the original topic at hand, and only for
> informative purposes at this point.
>
> On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> > 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.
> >
>
> I have *something* semi-working, with a huge amount of help from Maxim
> in private email.  There is still a nit or two to fix, I'm running into
> them as I rebuild the ISO after fixing the prior issue.  But, right now,
> I can get the ISO to boot enough to get to a shell (the "init failed due
> to inability to mount '/'" shell, but it is still a shell).  :)
>
> Once I get what I have now into a state where it's somewhat committable,
> I'm going to create a project branch to sand off the edges, instead of
> doing it directly in head, since there might be some edge cases for
> non-x86 architectures.  (But some other architectures do not have the
> "too big" problem.)
>
> Once that is merged, I fully intend to merge this to stable/11, provided
> there is no major fallout.  With what I have now, disc1.iso is 630M, and
> the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
> people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
> though, there appears to be a significantly non-zero speed decrease,
> though this may just be because my CD-ROM is USB-based.  When I have the
> ready-to-commit result, I'll test it on a machine with an internal CD
> drive.
>
> Glen
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

Just replying to the first email in the thread, since it's a general
reply, and only related to the original topic at hand, and only for
informative purposes at this point.

On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> 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.
> 

I have *something* semi-working, with a huge amount of help from Maxim
in private email.  There is still a nit or two to fix, I'm running into
them as I rebuild the ISO after fixing the prior issue.  But, right now,
I can get the ISO to boot enough to get to a shell (the "init failed due
to inability to mount '/'" shell, but it is still a shell).  :)

Once I get what I have now into a state where it's somewhat committable,
I'm going to create a project branch to sand off the edges, instead of
doing it directly in head, since there might be some edge cases for
non-x86 architectures.  (But some other architectures do not have the
"too big" problem.)

Once that is merged, I fully intend to merge this to stable/11, provided
there is no major fallout.  With what I have now, disc1.iso is 630M, and
the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
though, there appears to be a significantly non-zero speed decrease,
though this may just be because my CD-ROM is USB-based.  When I have the
ready-to-commit result, I'll test it on a machine with an internal CD
drive.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ruben Kerkhof]

On Tue, Jul 12, 2016 at 11:02 PM, Steve Rikli  wrote:
> I haven't done it in a very long time (circa FreeBSD-6) but PXE installs
> were possible back then, so I'd hope that's still a possibility in 11.
>
> Are there mostly current docs for that routine these days?
>
> Cheers,
> sr.

This has become a bit harder recently, but it's not impossible.
You'll need an mfsroot for pxe installs. If I remember correctly it used to be
on the CD and possibly even on the ftp servers. This stopped being the case
somewhere after FreeBSD 9. You can still create it yourself, but it would be
great if the release process could churn it out again as one of the artifacts.

Kind regards,

Ruben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Adrian Chadd]

There's a lot more in GENERIC, and we still build things twice - once
as modules, and then also inside the GENERIC image.

Hopefully warner (and others who may help!) can push forward the "bus
enumerate" bits early on in -12 so we can just use a modules-driven
kernel on platforms where that's now mostly easy (ie, i386/amd64,
arm/arm64 with loader support (which I think is all?), powerpc, etc.)

I think the one deviant atm is my embedded mips platforms, as
mips-loader is still under development.


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

On Wed, 13 Jul 2016 12:05:06 +0300 Slawa Olhovchenkov  wrote

> On Tue, Jul 12, 2016 at 02:05:32PM -0700, Chris H wrote:
> 
> > On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler 
> > wrote 
> > > On 12/07/2016 06:54, Conrad Meyer wrote:
> > > > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > > > it's time to move on from CD.
> > > 
> > > +1 on dropping CD images. I haven't burnt a CD in over 10 years and I
> > > don't believe I have seen a CD only drive in that time. Even with a CD
> > > size image I have burnt them to DVD, I first started this because
> > > transfer speeds of DVD's are faster and nowadays it costs almost the
> > > same to burn a DVD. So I see zero benefit to using CD's and that's
> > > before thinking of reusable USB devices.
> > > 
> > > I do think there is a benefit to keeping the small boot only image
> > > available that can be used to start/recover a machine that can then
> > > download any data to be installed.
> > > 
> > > -- 
> > > FreeBSD - the place to B...Storing Data
> > > 
> > > Shane Ambler
> > > 
> > 
> > -1
> > There is no *good* reason that FreeBSD can't maintain the CD image.
> > I think the *real* question here is; *why* is it now so hard to fit
> > it on a CD?
> 
> clang main binary now 50MB size (27MB for 10.x) -- on live FS and in
> base.txz. 11.x now ship lldb (on live FS too) -- 50MB also binary -- on live
> FS and in base.txz.
> kernel now 26M vs 12M on 10.3.
> kernel with modules now 115MB vs 54MB on 10.3
> total size of *.a now 50M (vs 48M).
> 
> All binaries slightly bigger: usr/bin/ld from 1580008 to 1615912 (+2%).

Thank you very much for posting the stats, Slawa!

Yikes. The kernel is now *twice* the size?!
Is bigger really better? I understand that clang is largely
responsible. But do the ends truly justify the means? What's
the cruft factor? You know; new ideas get started then life,
or other things get in the way, and it stalls. Leaving cruft
in the source. With the hopes of completing it at a later date.
Sorry, I haven't (yet) had the time to download a new iso image
and examine this, myself.

Honestly, these numbers are really depressing. :(

--Chris

--


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Lars Engels]

On Tue, Jul 12, 2016 at 12:09:09PM +0200, Ronald Klop wrote:
> On Mon, 11 Jul 2016 23:24:10 +0200, Conrad Meyer  wrote:
> 
> > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > it's time to move on from CD.
> 
> Becoming anecdotal now, but my fairly old computer has a (BIOS) bug which  
> brakes booting from USB devices. It hangs when it boots with a USB stick  
> in it.
> With the bootonly ISO I upgraded it from 9.3-PRERELEASE to 11-BETA1. By  
> just copying /boot/kernel from the CD to the harddisk. :-) I know I have  
> to do more for a proper upgrade, but the ZFS version on disk was to new  
> for the 9.3 kernel, by a human mistake. LOL

I've never tried it, but Plop Boot Manager allows to boot from USB
on PCs without BIOS USB support (or in your case, where that support is
broken):

https://www.plop.at/en/bootmanagers.html


pgpCK2TS6HekT.pgp
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

Hi Maxim,

Ok, thanks for the information.  I'm glad you replied, because I what
I was going to do was wrong.  I'm testing things now, and if it works,
would integrate this into the build.

Thank you for providing this information.

Glen

On Wed, Jul 13, 2016 at 07:22:58AM -0700, Maxim Sobolev wrote:
> Glen, UFSFILE here is the path to the UFS file system input image that can
> be created either via attaching file (vnode) with mdconfig, doing newfs
> mdX, mount mdX etc or by using mkimg tool. The UZPFILE is resulting CLOOP
> image, temporary file. ISOFILE is the output file (ISO). Let me know if you
> have some more specific questions, I'll be glad to help.
> 
> -Max
> 
> On Wed, Jul 13, 2016 at 6:52 AM, Glen Barber  wrote:
> 
> > On Mon, Jul 11, 2016 at 05:23:32PM -0700, Maxim Sobolev wrote:
> > > 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}
> > >
> >
> > I'm very interested in implementing this, provided it solves the
> > disc1.iso size issue.  Could you provide a bit explanation on what the
> > variables above represent?  At the moment, I'm having trouble parsing
> > the file paths and input/output paths.
> >
> > Glen
> >
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

Glen, UFSFILE here is the path to the UFS file system input image that can
be created either via attaching file (vnode) with mdconfig, doing newfs
mdX, mount mdX etc or by using mkimg tool. The UZPFILE is resulting CLOOP
image, temporary file. ISOFILE is the output file (ISO). Let me know if you
have some more specific questions, I'll be glad to help.

-Max

On Wed, Jul 13, 2016 at 6:52 AM, Glen Barber  wrote:

> On Mon, Jul 11, 2016 at 05:23:32PM -0700, Maxim Sobolev wrote:
> > 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}
> >
>
> I'm very interested in implementing this, provided it solves the
> disc1.iso size issue.  Could you provide a bit explanation on what the
> variables above represent?  At the moment, I'm having trouble parsing
> the file paths and input/output paths.
>
> Glen
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

On Wed, Jul 13, 2016 at 01:52:13PM +, Glen Barber wrote:
> On Mon, Jul 11, 2016 at 05:23:32PM -0700, Maxim Sobolev wrote:
> > 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}
> > 
> 
> I'm very interested in implementing this, provided it solves the
> disc1.iso size issue.  Could you provide a bit explanation on what the
> variables above represent?  At the moment, I'm having trouble parsing
> the file paths and input/output paths.
> 

For now, I think ignore my reply.  I think I now see what you're doing.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

On Mon, Jul 11, 2016 at 05:23:32PM -0700, Maxim Sobolev wrote:
> 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}
> 

I'm very interested in implementing this, provided it solves the
disc1.iso size issue.  Could you provide a bit explanation on what the
variables above represent?  At the moment, I'm having trouble parsing
the file paths and input/output paths.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[David Chisnall]

On 13 Jul 2016, at 10:17, O. Hartmann  wrote:
> 
> A CD is still a used media, but it starts getting squeezy on it as certain
> software starts to grow - as CLANG/LLVM does. Maybe it is time to have also 
> CDs
> as "miniboot" and DVDs for a more complete installation media?

I completely agree.  If you’re installing somewhere that’s not firewalled off 
completely from the Internet, then it’s typically faster to boot the bootonly 
ISO and then download the rest on the target machine (from a local mirror if 
necessary).  Even 100Mb/s ethernet is faster than most CD drives.  If you need 
offline installs, then the DVD with a bunch of other packages on it is probably 
what you want, not a CD that just contains the base system.

Even if you can’t boot from USB (as I can’t on one of my FreeBSD machines), it 
should be possible to stick the base distributions and a package repo on a USB 
stick, use the boot-only ISO to boot and then install from USB.

David



smime.p7s
Description: S/MIME cryptographic signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[O. Hartmann]

On Wed, 13 Jul 2016 12:05:06 +0300
Slawa Olhovchenkov  wrote:

> On Tue, Jul 12, 2016 at 02:05:32PM -0700, Chris H wrote:
> 
> > On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler 
> > wrote 
> > > On 12/07/2016 06:54, Conrad Meyer wrote:  
> > > > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > > > it's time to move on from CD.  
> > > 
> > > +1 on dropping CD images. I haven't burnt a CD in over 10 years and I
> > > don't believe I have seen a CD only drive in that time. Even with a CD
> > > size image I have burnt them to DVD, I first started this because
> > > transfer speeds of DVD's are faster and nowadays it costs almost the
> > > same to burn a DVD. So I see zero benefit to using CD's and that's
> > > before thinking of reusable USB devices.
> > > 
> > > I do think there is a benefit to keeping the small boot only image
> > > available that can be used to start/recover a machine that can then
> > > download any data to be installed.
> > > 
> > > -- 
> > > FreeBSD - the place to B...Storing Data
> > > 
> > > Shane Ambler
> > >   
> > 
> > -1
> > There is no *good* reason that FreeBSD can't maintain the CD image.
> > I think the *real* question here is; *why* is it now so hard to fit
> > it on a CD?  
> 
> clang main binary now 50MB size (27MB for 10.x) -- on live FS and in base.txz.
> 11.x now ship lldb (on live FS too) -- 50MB also binary -- on live FS
> and in base.txz.
> kernel now 26M vs 12M on 10.3.
> kernel with modules now 115MB vs 54MB on 10.3
> total size of *.a now 50M (vs 48M).
> 
> All binaries slightly bigger: usr/bin/ld from 1580008 to 1615912 (+2%).
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

More than a decade ago, some of us ran into trouble with floppy disks and/or
tapes, when software started to outgrow some older media. The tribute to
progress is, in some aspects, also to sacrifice.

FreeBSD is one of the few free operating systems which provides a plethora of
installation media - compared to some PR-shiny alternatives from the camp
"Linux".

A CD is still a used media, but it starts getting squeezy on it as certain
software starts to grow - as CLANG/LLVM does. Maybe it is time to have also CDs
as "miniboot" and DVDs for a more complete installation media?

Kind regards,
oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Tue, Jul 12, 2016 at 02:05:32PM -0700, Chris H wrote:

> On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler  wrote
> 
> > On 12/07/2016 06:54, Conrad Meyer wrote:
> > > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > > it's time to move on from CD.
> > 
> > +1 on dropping CD images. I haven't burnt a CD in over 10 years and I
> > don't believe I have seen a CD only drive in that time. Even with a CD
> > size image I have burnt them to DVD, I first started this because
> > transfer speeds of DVD's are faster and nowadays it costs almost the
> > same to burn a DVD. So I see zero benefit to using CD's and that's
> > before thinking of reusable USB devices.
> > 
> > I do think there is a benefit to keeping the small boot only image
> > available that can be used to start/recover a machine that can then
> > download any data to be installed.
> > 
> > -- 
> > FreeBSD - the place to B...Storing Data
> > 
> > Shane Ambler
> > 
> 
> -1
> There is no *good* reason that FreeBSD can't maintain the CD image.
> I think the *real* question here is; *why* is it now so hard to fit
> it on a CD?

clang main binary now 50MB size (27MB for 10.x) -- on live FS and in base.txz.
11.x now ship lldb (on live FS too) -- 50MB also binary -- on live FS
and in base.txz.
kernel now 26M vs 12M on 10.3.
kernel with modules now 115MB vs 54MB on 10.3
total size of *.a now 50M (vs 48M).

All binaries slightly bigger: usr/bin/ld from 1580008 to 1615912 (+2%).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[A. Wilcox]

On 12/07/16 15:58, Steven Hartland wrote:
> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
>> On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
>>
>>> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
>>> be dropped from Tier 2 if they don't support USB and we aren't okay
>>> with dropping disc1 support for all of Tier 2.

That is pretty much all SPARC hardware and a lot of POWER hardware.  Not
to mention newer rack-mount servers that have no USB on front (IBM).

And what of the servers that already have functional CD drives?  Do we
really now have to recommending buying SCSI/SATA slimline or USB DVD
drives just to boot installation media?  That's a heavy cost when you
can fit nearly all other BSDs on a single regular 650 (84 MB for NetBSD
7.0.1 + 223 MB for OpenBSD 5.9 + 385 MB for "TrueOS"/PC-BSD Server 10.3
= 692 MB, all sizes amd64 install iso including sets).

>> Not all BIOS can be boot from USB.
>> I am have Fujitsu notebook not support USB boot.
> From a USB Pen drive I can understand but from a USB DVD Drive that
> would be some seriously antiquated hardware!

I have a Core 2-era Xeon board (Wolfdale-DP, Intel 5000 based) that
cannot under any circumstances boot from a connected USB device.  It
won't boot from a USB DVD, USB CD, USB pen, or USB hard disk (USBMSC).
I hardly consider a server that is 7 years old "antiquated" though I
concede it is not the newest.

Beyond that, there are security issues with allowing servers to boot off
of any random USB device that an admin has lying around.  Most will be
configured by good admins to not do such a thing.

In summary: NAK NAK NAK.  USB is not a solution.  Bringing down the
bloat on disc1 or returning to miniinst is the proper solution.

~arw

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 22:20, Ed Schouten wrote:

2016-07-11 23:01 GMT+02:00 Ronald Klop :

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.

I remember back in the days we also had a 'miniinst' CD, which was
identical to 'bootonly', but at least contained the install sets to
get a minimal system working. What ever happened to that?

Since we found mfsbsd , we've never looked back it 
does just that + a one cmd line install.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ed Schouten]

2016-07-11 23:01 GMT+02:00 Ronald Klop :
> 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.

I remember back in the days we also had a 'miniinst' CD, which was
identical to 'bootonly', but at least contained the install sets to
get a minimal system working. What ever happened to that?

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Tue, Jul 12, 2016 at 09:58:08PM +0100, Steven Hartland wrote:

> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
> > On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
> >
> >> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> >> be dropped from Tier 2 if they don't support USB and we aren't okay
> >> with dropping disc1 support for all of Tier 2.
> >>
> >> There's lots of aging hardware we don't support in modern FreeBSD,
> >> including alpha and ia64.  USB is 20 years young at this point.
> > Not all BIOS can be boot from USB.
> > I am have Fujitsu notebook not support USB boot.
> >
>  From a USB Pen drive I can understand but from a USB DVD Drive that 
> would be some seriously antiquated hardware!

They have CD-ROM. Why I need buy USB DVD Drive?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steve Rikli]

I haven't done it in a very long time (circa FreeBSD-6) but PXE installs
were possible back then, so I'd hope that's still a possibility in 11.

Are there mostly current docs for that routine these days?

Cheers,
sr.

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> be dropped from Tier 2 if they don't support USB and we aren't okay
> with dropping disc1 support for all of Tier 2.
> 
> There's lots of aging hardware we don't support in modern FreeBSD,
> including alpha and ia64.  USB is 20 years young at this point.
> 
> Best,
> Conrad
> 
> On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> > On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> >> +1 on dropping CD images.
> >
> > I have 24U of things that don't have DVD players, including some tier-2
> > machines for which no upgrade is available.
> >
> > mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler  wrote

> On 12/07/2016 06:54, Conrad Meyer wrote:
> > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > it's time to move on from CD.
> 
> +1 on dropping CD images. I haven't burnt a CD in over 10 years and I
> don't believe I have seen a CD only drive in that time. Even with a CD
> size image I have burnt them to DVD, I first started this because
> transfer speeds of DVD's are faster and nowadays it costs almost the
> same to burn a DVD. So I see zero benefit to using CD's and that's
> before thinking of reusable USB devices.
> 
> I do think there is a benefit to keeping the small boot only image
> available that can be used to start/recover a machine that can then
> download any data to be installed.
> 
> -- 
> FreeBSD - the place to B...Storing Data
> 
> Shane Ambler
> 

-1
There is no *good* reason that FreeBSD can't maintain the CD image.
I think the *real* question here is; *why* is it now so hard to fit
it on a CD?

--Chris


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 21:50, Slawa Olhovchenkov wrote:

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:


Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
be dropped from Tier 2 if they don't support USB and we aren't okay
with dropping disc1 support for all of Tier 2.

There's lots of aging hardware we don't support in modern FreeBSD,
including alpha and ia64.  USB is 20 years young at this point.

Not all BIOS can be boot from USB.
I am have Fujitsu notebook not support USB boot.

From a USB Pen drive I can understand but from a USB DVD Drive that 
would be some seriously antiquated hardware!


Regards
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:

> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> be dropped from Tier 2 if they don't support USB and we aren't okay
> with dropping disc1 support for all of Tier 2.
> 
> There's lots of aging hardware we don't support in modern FreeBSD,
> including alpha and ia64.  USB is 20 years young at this point.

Not all BIOS can be boot from USB.
I am have Fujitsu notebook not support USB boot.

> Best,
> Conrad
> 
> On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> > On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> >> +1 on dropping CD images.
> >
> > I have 24U of things that don't have DVD players, including some tier-2
> > machines for which no upgrade is available.
> >
> > mcl
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Conrad Meyer]

Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
be dropped from Tier 2 if they don't support USB and we aren't okay
with dropping disc1 support for all of Tier 2.

There's lots of aging hardware we don't support in modern FreeBSD,
including alpha and ia64.  USB is 20 years young at this point.

Best,
Conrad

On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
>> +1 on dropping CD images.
>
> I have 24U of things that don't have DVD players, including some tier-2
> machines for which no upgrade is available.
>
> mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 20:52, Mark Linimon wrote:

On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:

+1 on dropping CD images.

I have 24U of things that don't have DVD players, including some tier-2
machines for which no upgrade is available.


Any no USB?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Mark Linimon]

On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> +1 on dropping CD images.

I have 24U of things that don't have DVD players, including some tier-2
machines for which no upgrade is available.

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

Another option for the kvm installs and  that we are using for many years
here is to pre-load root UZIP image into RAM. With some easy trimming you
can bring base system down to 30MB or so compressed. Yes, bit of delay to
load, but the kernel alone is around 10MB compressed, so it's not an order
of magnitude increase. Then it runs from the RAM completely, so you are
immune to any disconnects or stalls. If your kvm disconnects in the middle
of the session, you just re-connect and continue.

UZPNAME here is the root UFS compressed with mkuzip. You would just put it
into your ISO as file somewhere and use:

  echo 'image_load="YES"' >> ${CDIR}/boot/loader.conf
  echo "image_name=\"/${UZPNAME}\"" >> ${CDIR}/boot/loader.conf
  echo 'image_type="md_image"' >> ${CDIR}/boot/loader.conf

Also we set mountftom (requires GEOM_LABEL):

  echo vfs.root.mountfrom=\"ufs:ufs/${MD_LABEL}\" >>
${CDIR}/boot/loader.conf

-Maxim

On Tue, Jul 12, 2016 at 9:31 AM, Allan Jude  wrote:

> On 2016-07-12 11:15, Ngie Cooper (yaneurabeya) wrote:
> >
> >> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
> >>
> >> Paweł Tyll wrote on 07/12/2016 01:22:
> >>
> >>> Those 3 things should shave off about 130MB of the 173MB needed to fit
> >>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
> >>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
> >>> CD-R? :)
> >>
> >> It is not only about the target media size. The size matters when you
> need to boot some recovery media from you desktop on remote server via KVM.
> >>
> >> And there is one thing I don't understand - why is the bootonly so
> large? I remember days when this fits to 50MB and now it is almost 235MB
> which renders it almost useless. For recoveries and remote installs I
> always use mfsbsd images (about 45MB).
> >
> > I wholeheartedly agree.
> >
> > It sucks having to transfer more than 50 MB over our work link across a
> few thousand miles with IPMI remote KVM redirection.
> >
> > Thanks,
> > -Ngie
> >
>
> With IPMI virtual media, you usually do not transfer the entire image,
> only read the blocks used by files that you load. Some IPMI clients
> provide stats, usually only about 40mb is read from the bootonly cd.
> More if you do things like invoke an editor to write a custom /etc/fstab
> etc.
>
> --
> Allan Jude
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Allan Jude]

On 2016-07-12 11:15, Ngie Cooper (yaneurabeya) wrote:
> 
>> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> Paweł Tyll wrote on 07/12/2016 01:22:
>>
>>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>>> CD-R? :)
>>
>> It is not only about the target media size. The size matters when you need 
>> to boot some recovery media from you desktop on remote server via KVM.
>>
>> And there is one thing I don't understand - why is the bootonly so large? I 
>> remember days when this fits to 50MB and now it is almost 235MB which 
>> renders it almost useless. For recoveries and remote installs I always use 
>> mfsbsd images (about 45MB).
> 
> I wholeheartedly agree.
> 
> It sucks having to transfer more than 50 MB over our work link across a few 
> thousand miles with IPMI remote KVM redirection.
> 
> Thanks,
> -Ngie
> 

With IPMI virtual media, you usually do not transfer the entire image,
only read the blocks used by files that you load. Some IPMI clients
provide stats, usually only about 40mb is read from the bootonly cd.
More if you do things like invoke an editor to write a custom /etc/fstab
etc.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ngie Cooper (yaneurabeya)]

> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Paweł Tyll wrote on 07/12/2016 01:22:
> 
>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>> CD-R? :)
> 
> It is not only about the target media size. The size matters when you need to 
> boot some recovery media from you desktop on remote server via KVM.
> 
> And there is one thing I don't understand - why is the bootonly so large? I 
> remember days when this fits to 50MB and now it is almost 235MB which renders 
> it almost useless. For recoveries and remote installs I always use mfsbsd 
> images (about 45MB).

I wholeheartedly agree.

It sucks having to transfer more than 50 MB over our work link across a few 
thousand miles with IPMI remote KVM redirection.

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Olli Hauer]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Miroslav Lachman]

Paweł Tyll wrote on 07/12/2016 01:22:


Those 3 things should shave off about 130MB of the 173MB needed to fit
on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
CD-R? :)


It is not only about the target media size. The size matters when you 
need to boot some recovery media from you desktop on remote server via KVM.


And there is one thing I don't understand - why is the bootonly so 
large? I remember days when this fits to 50MB and now it is almost 235MB 
which renders it almost useless. For recoveries and remote installs I 
always use mfsbsd images (about 45MB).


Miroslav Lachman
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Nathan Whitehorn]

On 07/11/16 23:39, Shane Ambler wrote:

On 12/07/2016 06:54, Conrad Meyer wrote:

DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


+1 on dropping CD images. I haven't burnt a CD in over 10 years and I
don't believe I have seen a CD only drive in that time. Even with a CD
size image I have burnt them to DVD, I first started this because
transfer speeds of DVD's are faster and nowadays it costs almost the
same to burn a DVD. So I see zero benefit to using CD's and that's
before thinking of reusable USB devices.

I do think there is a benefit to keeping the small boot only image
available that can be used to start/recover a machine that can then
download any data to be installed.



But some people clearly do want that, and this is trivially fixable by 
dropping the toolchain from disc1 and leaving it on the DVD image. So 
let's do that.

-Nathan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Kurt Jaeger]

Hi!

> On 12/07/2016 06:54, Conrad Meyer wrote:
> > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > it's time to move on from CD.
> 
> +1 on dropping CD images.

CD-ROMs are read-only and pretty much secure, USB flash can be used to
attack systems.

Just sayin' 8-}

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Shane Ambler]

On 12/07/2016 06:54, Conrad Meyer wrote:

DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


+1 on dropping CD images. I haven't burnt a CD in over 10 years and I
don't believe I have seen a CD only drive in that time. Even with a CD
size image I have burnt them to DVD, I first started this because
transfer speeds of DVD's are faster and nowadays it costs almost the
same to burn a DVD. So I see zero benefit to using CD's and that's
before thinking of reusable USB devices.

I do think there is a benefit to keeping the small boot only image
available that can be used to start/recover a machine that can then
download any data to be installed.

--
FreeBSD - the place to B...Storing Data

Shane Ambler

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Paweł Tyll]

Hello Glen,

> 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. :(
While  the  fact  that  .xz  version  is  roughly 500MB is quite solid
evidence  that  one  can  fit under 700MB with effort, I'm not sure if
this  is  worthwhile. As mentioned earlier, it's 2016, and pretty much
everything  can  be  booted from USB stick for a decade or so, and VMs
usually  emulate DVD drives anyway, which don't care whether the image
is 600MB, 777MB or 3GB.

/usr/bin/clang can be compressed down from 49MB to 14MB by some binary
packer,  if  feasible.  There  are  some  other binaries, not as large
tough.
/boot/kernel/*  -  103MB  -> 38MB - but is there any infrastructure to
load compressed kernel modules, and kernel images?
ports.txz  can  be easily fetched from the net and are useless without
network connection anyway (right?) - saving of another 34MB.

Those 3 things should shave off about 130MB of the 173MB needed to fit
on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
CD-R? :)

And what of FreeBSD 12.0-RELEASE?

Kind regards.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ronald Klop]

On Mon, 11 Jul 2016 23:24:10 +0200, Conrad Meyer  wrote:


DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


Becoming anecdotal now, but my fairly old computer has a (BIOS) bug which  
brakes booting from USB devices. It hangs when it boots with a USB stick  
in it.
With the bootonly ISO I upgraded it from 9.3-PRERELEASE to 11-BETA1. By  
just copying /boot/kernel from the CD to the harddisk. :-) I know I have  
to do more for a proper upgrade, but the ZFS version on disk was to new  
for the 9.3 kernel, by a human mistake. LOL


Regards,
Ronald.





Best,
Conrad

On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop   
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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to  
"freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ronald Klop]

On Mon, 11 Jul 2016 23:32:34 +0200, Alan Somers   
wrote:


On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop   
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.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211029

Cheers
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

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  wrote:

> On Mon, 11 Jul 2016 18:39:51 -0400 Allan Jude 
> wrote
>
> > On 2016-07-11 18:33, Chris H wrote:
> > > On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov 
> > > wrote >
> > >> On Mon, Jul 11, 2016 at 09:41:44PM +, 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  >
> >  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@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

On Mon, 11 Jul 2016 18:39:51 -0400 Allan Jude  wrote

> On 2016-07-11 18:33, Chris H wrote:
> > On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov 
> > wrote >
> >> On Mon, Jul 11, 2016 at 09:41:44PM +, 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 
>  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@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

You don't need that much for OS really if you compress the underlying FS
(be that ISO9660 or UFS) with the mkuzip. Just as an extreme example of
that, we have liveCD-type image that deals with provisioning a new systems
and troubleshooting issues on around 40MB ISO. That includes nearly all of
the stock base system tools (modulo compilers and other dev related bits,
fully linked ones, not crunch), full amd64 kernel (compressed separately)
and complete python 2.7 environment along with necessary dependencies. So
if your live OS takes 300MB+, it will be compressed down to under 100MB by
just using GEOM_UZIP.

Whatever people say here about moving to USB, ISOs are quite useful for
setting up VMs as well as for remove booting off IP KVMs.

JFYI.

-Maxim

P.S. It would be cool to have a loader that can read off CLOOP partition,
but it's just in my wet dreams now.

On Mon, Jul 11, 2016 at 3:39 PM, Allan Jude  wrote:

> On 2016-07-11 18:33, Chris H wrote:
>
>> On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov 
>> wrote
>>
>> On Mon, Jul 11, 2016 at 09:41:44PM +, 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 
>>
> 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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@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.
>
> --
> Allan Jude
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 11/07/2016 23:39, Allan Jude wrote:

On 2016-07-11 18:33, Chris H wrote:
On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov 
 wrote



On Mon, Jul 11, 2016 at 09:41:44PM +, 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 

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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@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.



Silly question but what about only supporting DVD?

I can't remember the last server I installed that had CDROM drive vs a 
DVD drive.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Allan Jude]

On 2016-07-11 18:33, Chris H wrote:

On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov  wrote


On Mon, Jul 11, 2016 at 09:41:44PM +, 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 

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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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.


--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov  wrote

> On Mon, Jul 11, 2016 at 09:41:44PM +, 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 
> > > 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ernie Luzar]

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  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. :(

Glen


I burned 11.0-ALPHA6 to a 700 MB CD-r using
"cdrecord -sao -overburn -disc1.iso"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Mon, Jul 11, 2016 at 09:41:44PM +, 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  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. :(

Reduce GENERIC to MINIMAL?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Glen Barber]

On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote:
> > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop  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. :(

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Alan Somers]

> On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop  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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Conrad Meyer]

DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.

Best,
Conrad

On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop  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.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"