[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded



Steven Chamberlain <steven@pyro.eu.org> (2014-08-20):
> On 14/08/14 18:15, Cyril Brulebois wrote:
> > [...] If a
> > single extra udeb (or udeb size increase, which happens from time to
> > time) is going to break kfreebsd-*, it seems to me that their status
> > is far too brittle.
> 
> The fixed-size d-i initrds had to be carefully sized for kfreebsd
> wheezy.

That this was the case for wheezy already isn't an excuse.

I really don't think it's viable to play the "let's save a byte here or
there" game. Even if that were the case, someone has to care, and commit
to actually ensuring that constraints are met, and that d-i works.

Look, I don't like releasing broken things. Especially when it looks
to me I'm the only user, and not even a real one, just a beta tester.

> We discussed about a year ago the possibility of adding a variable-sized
> ramdisk to avoid ENOSPC, for anna/cdebconf in particular.  It may affect
> our minimum RAM requirements.

Is that a viable option for jessie?

> And/or we could maybe lose some unnecessary udebs.  I mentioned
> partman-iscsi as an example to start with (I also didn't understand
> how/why that was being included in the image at all?) but there are
> probably other and larger candidates.

If you're trying to insinuate I/we deliberately broke kfreebsd-* by
introducing partman-iscsi, rest assured that: no. Can we please figure
out a way to unbreak kfreebsd *most of the time* and stop caring about
this single package? Extra udebs are sometimes added. That shouldn't be
the end of the world for release architectures. And when breakages
happen, there really should be someone to detect them, and deal with
them.

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: