partition 'out of space' when building

[luroh]

When trying to build to /dev/sda1, a 4.6GB partition, it aborts the process during 'creating the image' with an 'out of space' error.
The only way I have found to trick it into succeeding is to first build a 400MB haiku.image and then enabling HAIKU_DONT_CLEAR_IMAGE.
Rev 30148, gcc2, on 32-bit Ubuntu 8.10.

TQH posted about something similar ​here.

[koki]

I have a similar problem, where jam -q now stays at the "Creating image..." stage a very long time (used to be a minute or two; it now stays there like five minutes) and then spits the following error message:

Creating image ...
Error: writing to device file /dev/sda1 failed (No space left on device)

export imagePath="/dev/sda1"
export isImage="1"
export isVMwareImage=""
build/scripts/build_haiku_image generated/haiku.image-init-vars
generated/haiku.image-make-dirs generated/haiku.image-copy-files
generated/haiku.image-unzip-files

...failed BuildHaikuImage1 /dev/sda1 ...
...removing /dev/sda1
...failed updating 1 target(s)...
...updated 423 target(s)...
jorge@jorge-laptop:~/develop/haiku/trunk$

This is at hrev30144.

[bga]

ARe you guys using Ubuntu by any chance? The reason I ask is because I see something like this from time to time but I know why.

I have several disks on my machine. For some reason I was not able to track down, Linux sometimes shuffles the id of a disk so in one boot my7 1 Tb disk could be sda and in the next boot it would move to sdb. When this happens, jam -q @disk1 will actually try to install haiku to the wrong partition and will then fail.

[koki]

@bga: Yes, cross-compiling from Ubuntu (8.10); but I just checked, and I don't see any changes in the disks ids.

[luroh]

After some more testing, I found that this problem was introduced in hrev30133.

[koki]

In case it matters, this happens when trying to build Haiku gcc2 in Ubuntu 8.10 32-bit.

[bonefish]

Fixed in hrev30151.

Unless you guys have masochistic tendencies or need long build times for meditation breaks, you should really set HAIKU_DONT_CLEAR_IMAGE when writing to a partition/device or use build profiles in the first place.

Generally HAIKU_DONT_CLEAR_IMAGE should be set also for image files, unless you intend to zip the image.

[koki]

I don't know about the others here, but in my case it's more a matter of ignorance rather than masochism. :) Anyway, with your advice here and the commit in hrev30151, I was able to build Haiku again. Thanks! :)

[axeld]

Is there any point then in keeping HAIKU_DONT_CLEAR_IMAGE around like this? Maybe we should default to this behaviour, and only introduce an optional HAIKU_CLEAR_IMAGE instead?

[Luposian]

Whew! The fix was simply to enabled (remove the pound/hash ("#") symbol) in front of HAIKU_DONT_CLEAR_IMAGE = 1

If that "function" is now a requirement (which it wasn't up til now), just make it a default, I say. That way, people like me, aren't left utterly confused why JAM is taking forever and a day (if not longer, as it *never* got past that point for me) to get past "Creating image..."

[umccullough]

The better solution is to start using a BuildProfile as documented in build/jam/UserBuildConfig.Readme

Any guides you read that tell you to set HAIKU_IMAGE_NAME and HAIKU_IMAGE_PATH directly in your UserBuildConfig are pretty much outdated now.