Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Control: reassign -1 rootskel Control: affects -1 debian-installer Steven Chamberlain ste...@pyro.eu.org (2014-08-21): The simple patch for this issue is as follows. It has been tested now on kfreebsd-amd64 and kfreebsd-i386 with varying amounts of available RAM. * On kfreebsd, use dynamically-sized tmpfs for: - /var/cache/anna - /var/lib/cdebconf to avoid running out of space in the fixed-size initrd. (Closes: #757985) diff --git a/src/sbin/init-kfreebsd b/src/sbin/init-kfreebsd index e8ea04d..e10f149 100755 --- a/src/sbin/init-kfreebsd +++ b/src/sbin/init-kfreebsd @@ -19,6 +19,8 @@ mount /dev mount /dev/fd mount /proc mount /sys +mount -t tmpfs tmpfs /var/cache/anna +mount -t tmpfs tmpfs /var/lib/cdebconf ln -s /var/run/log /dev/log # Get all kernel parameters that can be exported as environment variables For those following at home this is a patch for rootskel. Thanks, I've applied it and I'm uploading 1.108 in a moment. Out of curiosity: maybe this could have been done for wheezy in order to avoid having to tweak the initrd size several times? KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Processing control commands: reassign -1 rootskel Bug #757985 [debian-installer] kfreebsd: hang with ENOSPC after a few components are loaded Bug reassigned from package 'debian-installer' to 'rootskel'. No longer marked as found in versions debian-installer/20140802. Ignoring request to alter fixed versions of bug #757985 to the same values previously set affects -1 debian-installer Bug #757985 [rootskel] kfreebsd: hang with ENOSPC after a few components are loaded Added indication that 757985 affects debian-installer -- 757985: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b757985.140864722632634.transcr...@bugs.debian.org
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On 21/08/14 19:53, Cyril Brulebois wrote: Out of curiosity: maybe this could have been done for wheezy in order to avoid having to tweak the initrd size several times? At the time of the freeze, the tmpfs code in wheezy kernels contained a warning that it might not be stable yet, but is removed now. It was only a few months ago that we discussed tmpfs as a solution to this problem. And I personally wouldn't have known enough in 2012 about how d-i works, to know which directories to use it for. The initrds still must be sized carefully, to leave enough space for udebs to be installed in the d-i root, plus some margin of safety, but not waste so much space that low-memory systems can't use it. (And kfreebsd-i386 has some maximum initrd size too). I looked into this while testing the patch for this bug, and got some approximate numbers. They're OK but could do with being shrunk a little bit now. I'll open a separate bug for that, I hope sometime next month is not too late (this change must happen after the number and size of udebs has stabilised - we do still have more than 10 weeks until freeze though). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On Wed, Aug 20, 2014 at 01:19:52AM +0100, Steven Chamberlain wrote: 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. Please move d-i to an unfixed size filesystem. Even freebsd have some sort of tmpfs. 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. Sorry, not in this stage of the Jessie development. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820064719.ga10...@mail.waldi.eu.org
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Control: tags -1 + patch Hi, The simple patch for this issue is as follows. It has been tested now on kfreebsd-amd64 and kfreebsd-i386 with varying amounts of available RAM. * On kfreebsd, use dynamically-sized tmpfs for: - /var/cache/anna - /var/lib/cdebconf to avoid running out of space in the fixed-size initrd. (Closes: #757985) diff --git a/src/sbin/init-kfreebsd b/src/sbin/init-kfreebsd index e8ea04d..e10f149 100755 --- a/src/sbin/init-kfreebsd +++ b/src/sbin/init-kfreebsd @@ -19,6 +19,8 @@ mount /dev mount /dev/fd mount /proc mount /sys +mount -t tmpfs tmpfs /var/cache/anna +mount -t tmpfs tmpfs /var/lib/cdebconf ln -s /var/run/log /dev/log # Get all kernel parameters that can be exported as environment variables Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821011150.ga6...@squeeze.pyro.eu.org
Processed: Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Processing control commands: tags -1 + patch Bug #757985 [debian-installer] kfreebsd: hang with ENOSPC after a few components are loaded Added tag(s) patch. -- 757985: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b757985.140858352131963.transcr...@bugs.debian.org
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
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. 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. 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. This has a higher priority than the other issues. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@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. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On 20/08/14 01:49, Cyril Brulebois wrote: If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, [...] No, I was not insinuating that. But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 20/08/14 01:49, Cyril Brulebois wrote: If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, [...] No, I was not insinuating that. But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Feel free to use another bug report to investigate/track that. I'd really appreciate if we could concentrate on the other points of my mail, instead of deflecting on this point of detail. Mraw, KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Thanks. I've meanwhile found the answer to this. It's actually not being installed in the images, but is installed later by anna. I think all we need to do is add the expected-uninstallable packages to /var/cache/anna/exclude (perhaps referring to http://d-i.debian.org/edos/#unstable for packages we probably want to exclude) On 20/08/14 02:50, Cyril Brulebois wrote: I'd really appreciate if we could concentrate on the other points of my mail, instead of deflecting on this point of detail. But it *is* also relevant here. Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, and if we can keep the anna excludes up-to-date, we could avoid some unwanted udebs (meant for Linux) appearing in the future. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): But it *is* also relevant here. Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, and if we can keep the anna excludes up-to-date, we could avoid some unwanted udebs (meant for Linux) appearing in the future. I did *not* say it wasn't relevant… Now, to be more precise, getting back one of my main points, which you didn't quote, or replied to: | 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. Who among the kfreebsd porters is going to make sure that d-i gets in to a somewhat reasonable shape, and going to keep it that way, so that we avoid the current mess? KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
I've finished testing these hypotheses: On 20/08/14 03:14, Steven Chamberlain wrote: I think all we need to do is add the expected-uninstallable packages to /var/cache/anna/exclude That works. I think on each architecture, any uninstallable udeb (according to http://d-i.debian.org/edos/#unstable) belongs in the anna excludes file. Maybe it could be automated, perhaps determined at debian-installer build time. [...] Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, [...] Skipping 21 surplus udebs was not enough. The biggest problem is indeed cdebconf templates: | /var/lib/cdebconf # ls -alS | -rw-r--r--1 root root 10886119 Aug 20 02:28 templates.dat | -rw-r--r--1 root root 10886119 Aug 20 02:27 templates.dat-old I wonder if -old is really needed in d-i? There is also a temporary templates.dat-new while it is processing. So at its peak, this directory accounts for some 30MiB or more in the d-i filesystem (in memory). That's half as big as the whole rest of d-i. I'm surprised this hasn't caused a problem yet on non-kfreebsd architectures -- a machine with only just enough memory to support graphical mode (instead of falling back to lowmem install mode where I think cdebconf localisation is disabled?). Anyway, I also tried using a tmpfs for /var/lib/cdebconf. That works very well, and seems like the best way we can fix this bug. It also helped slightly to mount a tmpfs on /var/cache/anna, where udebs are downloaded to one-at-a-time, before each is extracted then deleted. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-13): On 13/08/14 02:55, Cyril Brulebois wrote: (Looking at syslog when I can, it seems anna is the tool running into a full partition, which isn't surprising.) Some new installer components have appeared since wheezy, such as partman-iscsi, which is arch: all. It is of no use without open-iscsi-udeb, which is linux-any. Is it a bug that it is added into kfreebsd images with unsatisfied dependencies? And/or, must we work around it by making partman-iscsi arch: linux-any? I know it is not very big, but it is shown in the partman menu, despite it not going to work. I don't think we'll have userland iSCSI initiator support for jessie. (Non-)installability seems quite orthogonal to the fact that we're hitting ENOSPC right after locale-related settings, doesn't it? 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. I'm also quite astonished about being the one reporting that. Did I miss developer/porter testing and/or user reports? This kind of breakage is so bad that I would have expected reports way earlier, or at least before my own noticing that these images are unusable… Mraw, KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On 13/08/14 02:55, Cyril Brulebois wrote: (Looking at syslog when I can, it seems anna is the tool running into a full partition, which isn't surprising.) Some new installer components have appeared since wheezy, such as partman-iscsi, which is arch: all. It is of no use without open-iscsi-udeb, which is linux-any. Is it a bug that it is added into kfreebsd images with unsatisfied dependencies? And/or, must we work around it by making partman-iscsi arch: linux-any? I know it is not very big, but it is shown in the partman menu, despite it not going to work. I don't think we'll have userland iSCSI initiator support for jessie. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53eb4e66.1050...@pyro.eu.org
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Package: debian-installer Version: 20140802 Severity: important User: debian-...@lists.debian.org Usertags: kfreebsd Hi, with a wheezy/amd64/kvm-based setup (hda is ~5GB, RAM is 1GB), the following images don't work at all, with the following message on vt1: | /: write failed, filesystem is full (Looking at syslog when I can, it seems anna is the tool running into a full partition, which isn't surprising.) - debian-jessie-DI-a1-kfreebsd-amd64-netinst.iso debian-jessie-DI-b1-kfreebsd-amd64-netinst.iso → with Default install (graphical mode), after locale settings, when udeb components are loaded. - debian-jessie-DI-a1-kfreebsd-i386-netinst.iso debian-jessie-DI-b1-kfreebsd-i386-netinst.iso → with Default install, after locale settings, when udeb components are loaded. I'm very concerned to see that Jessie Alpha 1 images were already totally broken for kfreebsd-i386 (ditto for kfreebsd-amd64 in graphical mode), and that it doesn't seem to have been detected/worked on/fixed. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813015546.21404.15511.report...@wodi.home.mraw.org
