build system doesn't honor HAIKU_DONT_CLEAR_IMAGE

[monni]

at least up to hrev25995

Like summary says, it tries to dd the partition if HAIKU_IMAGE_SIZE is not set, even though HAIKU_DONT_CLEAR_IMAGE is set.

[bonefish]

Works for me (OpenSuse 10.3). The part in the build_haiku_image script looks good too:

		if [ $isVMwareImage ]; then
			vmdkImageFlags=
			if [ ! "$dontClearImage" ]; then
				vmdkImageFlags="-c"
			fi
			$vmdkimage -h 64k -i${imageSize}M $vmdkImageFlags "$imagePath" \
				|| exit 1
		elif [ ! -e "$imagePath" -o ! "$dontClearImage" ]; then
			dd if=/dev/zero of="$imagePath" bs=1048576 count=$imageSize \
				|| exit 1
		fi

dd is only invoked, if the image path doesn't exist or HAIKU_DONT_CLEAR_IMAGE is not set. I can only ask you to analyze what goes wrong on your system.

[monni]

All I could find is that #2270 is related... Something goes wrong inside jam and -e test fails...

IMHO both jam and this script never should try to delete or create anything inside /dev...

I know it's a special case, but as it can corrupt data outside Haiku's own "playground" it should be handled gracefully.

[anevilyak]

If it helps, I used to have a similar problem on Ubuntu, but it would only exhibit itself after doing a certain number of builds in the same session, and would also be characterized by an out of disk space error on the partition in question for some reason. A reboot consistently fixed it in that case. However, since switching to FreeBSD7 as my main build platform I haven't seen this error again.

[bonefish]

Replying to monni:

All I could find is that #2270 is related... Something goes wrong inside jam and -e test fails...

I don't see what should go wrong other than the tested file doesn't exist.

IMHO both jam and this script never should try to delete or create anything inside /dev...

It doesn't, if you don't give it the permissions. All it needs is write access to the partition device and read access to the disk device. If you don't give it any more permissions, it won't be able to create or delete any entries in /dev/.

[monni]

For it to work, I need to run it as user "root"... Normal user won't work as the whole /dev file system (udev) is created run-time... There is no way to permanently chmod or chown individual "nodes".

What happens is that first error inside "jam" removes /dev/sd?1 node, next it creates that as regular file of 100 MB and errors out again because it is too small for all the requested files. Subsequent tries all fail because it no longer points to a valid block device. Reboot fixes it temporarily as /dev file system is recreated by udev.

If I set the image size, it will fill up the whole Linux partition and render it unbootable.

[umccullough]

Replying to monni:

For it to work, I need to run it as user "root"... Normal user won't work as the whole /dev file system (udev) is created run-time... There is no way to permanently chmod or chown individual "nodes".

Which is why many of us just chmod the necessary paths before jamming an image :)

BTW, after you've been running your haiku builds as root - trying to run them as a normal user often fails to remove files created in the generated folder as root - so you'll want to chown those, or just remove them all and start clean.

[monni]

Replying to umccullough:

Which is why many of us just chmod the necessary paths before jamming an image :)

BTW, after you've been running your haiku builds as root - trying to run them as a normal user often fails to remove files created in the generated folder as root - so you'll want to chown those, or just remove them all and start clean.

Take this:

I got two mass storage controllers ...

Haiku is on SCSI 0, Linux is on SCSI 3

First time I boot Haiku gets /dev/sda, Linux gets /dev/sdb Next time I boot Linux might get /dev/sda and Haiku gets /dev/sdb

So each time I test the "image" and boot back to update the sources I need to verify which one it got that time.

In worst cases when it render the Linux partition unbootable, I have to boot from Live CD and I get Haiku on /dev/sda in one shell and /dev/sdb in another.

God bless Ubuntu and ide-scsi ;)

[bonefish]

Replying to monni:

Replying to umccullough:

Which is why many of us just chmod the necessary paths before jamming an image :)

BTW, after you've been running your haiku builds as root - trying to run them as a normal user often fails to remove files created in the generated folder as root - so you'll want to chown those, or just remove them all and start clean.

Take this:

I got two mass storage controllers ...

Haiku is on SCSI 0, Linux is on SCSI 3

First time I boot Haiku gets /dev/sda, Linux gets /dev/sdb Next time I boot Linux might get /dev/sda and Haiku gets /dev/sdb

So each time I test the "image" and boot back to update the sources I need to verify which one it got that time.

In worst cases when it render the Linux partition unbootable, I have to boot from Live CD and I get Haiku on /dev/sda in one shell and /dev/sdb in another.

But you still also have symlinks somewhere that are stable between reboots, right?

Anyway, can you try adding the following to build/scripts/build_haiku_image (line 32, after the first if-block):

if which readlink &> /dev/null; then
	normalizedImagePath=$(readlink -e "$imagePath")
	if [ $normalizedImagePath ]; then
		imagePath="$normalizedImagePath"
	fi
fi

It should resolve any symlinks in the image path. Which, if I understood it correctly, is somehow the source of your problems.

[monni]

Replying to bonefish:

But you still also have symlinks somewhere that are stable between reboots, right?

Anyway, can you try adding the following to build/scripts/build_haiku_image (line 32, after the first if-block):

if which readlink &> /dev/null; then
	normalizedImagePath=$(readlink -e "$imagePath")
	if [ $normalizedImagePath ]; then
		imagePath="$normalizedImagePath"
	fi
fi

It should resolve any symlinks in the image path. Which, if I understood it correctly, is somehow the source of your problems.

BuildHaikuImage1 /dev/disk/by-id/scsi-1ATA_WDC_AC12500L_WD-WT4850304790-part1 
/bin/readlink

Creating image ...
Partition::SetTo(): active: 80
Partition::SetTo(): active: 0
Partition::SetTo(): active: 0
Partition::SetTo(): active: 0
Writing boot code to "/dev/sda1" (partition offset: 32256 bytes) ...
Populating image ...

Rest of the output is pretty much redundant... Funny thing is that it just hides this bug, but fixes another, #2376.

[bonefish]

Replying to monni:

Rest of the output is pretty much redundant... Funny thing is that it just hides this bug, but fixes another, #2376.

OK, closing this ticket then. If any bug is hidden, it's a bug in your system. I would put it past Ubuntu to mess something up with "test -e". It simply shouldn't fail for an existing symlink.