Build system writes over actual filesystem contents while trying to add boot sector to partition

[monni]

hrev25995 and a lot of previous ones

How to reproduce: jam haiku-image (under Ubuntu 7.04+) Experienced behavior: didn't boot anymore, partition missing files Expected behavior: preserve existing files when HAIKU_DONT_CLEAR_IMAGE is set

This has happened me every time when "FS Shell" has failed to access the partition, which is a lot considering previous ticket about build system not taking account drive node can change between build attempts (happens often with machines with several mass storage controllers)

[bonefish]

I'm a bit confused by this report. If the bfs_shell can't access the partition, how can anything be touched at all?

Anyway, maybe there's a basic misunderstanding regarding HAIKU_DONT_CLEAR_IMAGE. It is not supposed to preserve any files on the image/partition. The only thing it does is disabling zeroing the image/partition. Zeroing usually makes no sense for partitions, but is useful for images when one intents to zip them. Regardless of this flag the file system is re-initialized on every "jam haiku-image".

[monni]

Most likely the error is that "makebootable" is invoked before trying to access the actual file system on partition...

If build script can't access the file system, "makebootable" shouldn't try to write to partition boot block either.

[bonefish]

Replying to monni:

Most likely the error is that "makebootable" is invoked before trying to access the actual file system on partition...

If build script can't access the file system, "makebootable" shouldn't try to write to partition boot block either.

That's exactly how it works:

		$bfsShell --initialize $imageOffsetFlags "$imagePath" Haiku \
			"block_size 2048" || exit 1
		$makebootable $imageOffsetFlags "$imagePath"

When initializing the FS fails, the script exits.

[monni]

Hmmm...

I'm going to vote for removing/disabling whole initialize command as it seriously looks like it's not safe... At least until build script starts dereferencing symbolic links for installation target.

And I still think it does "makebootable" too early...

To make it simple... As it is default that it clears the image, it should initialize the partition only if also clearing the image is allowed.

[bonefish]

Replying to monni:

And I still think it does "makebootable" too early...

To make it simple... As it is default that it clears the image, it should initialize the partition only if also clearing the image is allowed.

That's exactly what's happening as the snippet I copied from the build_haiku_image script shows. I can even easily reproduce that it works like this when trying to build with insufficient permissions.

Regarding not being able to boot. If you provided the symlink, makebootable wouldn't be able to make the partition bootable at all, since it wouldn't find the disk device the partition belongs to.

If there's still some problem that justifies the ticket to be open after hrev26006, please provide the build output.

[scottmc]

Probably fixed in hrev26006, no comments for 4 months, can close?

[monni]

I have nothing against closing this one for now. Big part of the issue was fixed in hrev26006 and even though it didn't fix the whole issue, it's not very likely to happen after "update-all" enhancement.