Build system deletes /dev/sda1 node in Ubuntu when installing Haiku on real disk

[monni]

When installing Haiku with Firefox optional package on very small real partition, Haiku deletes /dev/sda1 node and fails to install without repartitioning drive and rebooting Linux. When looking at the partition boundaries using cfdisk, it seems end of the partition gets overwritten in partition table.

[bonefish]

Please provide the following information:

• All relevant build variables you set (in doubt your complete UserBuildConfig).
• The command line you use to invoke jam.
• The build output.
• The exact size of the concerned partition.

[monni]

Replying to bonefish:

Please provide the following information:

• All relevant build variables you set (in doubt your complete UserBuildConfig).
• The command line you use to invoke jam.
• The build output.
• The exact size of the concerned partition.

Build variables: HAIKU_IMAGE_DIR = /dev ; HAIKU_IMAGE_NAME = sda1 ; HAIKU_IMAGE_SIZE = 100 ; AddOptionalHaikuImagePackages Vision Firefox ;

command line to invoke jam: jam haiku-image

Exact size of the partition is 2441.4 MB, but if I put it in HAIKU_IMAGE_SIZE, it errors out even earlier.

Can't get build output right now as I have to boot through Ubuntu Live CD because bootman doesn't support booting from SCSI drives and I can't change boot order from BIOS.

Obviously it should ignore the HAIKU_IMAGE_SIZE, but for some reasons it forgets that it is writing to real drive instead of image file.

[axeld]

It would be interesting if we could stop jam from deleting failed targets - that would definitely be nice for the image target.

[stippi]

Ah, now I get it. I was thinking the actual Installer application does something like that!

[bonefish]

Any update on this one? I can't say anything more without at least the build output.

[bonefish]

The removal of /dev/... entries by jam won't be fixed (at least not by me). One should simple *not* run jam with the permissions to do that (i.e. not as root). Reasonable alternatives are setting the permissions of the respective device node as needed, or changing the owning group to something the jam user is member of.

Regarding the supposed partition table changes, I don't see how that can possibly happen. The build system *writes* only to the partition given, so it can't potentially change the partition table.

Regarding the build failure, without at least the build output only guessing can be done. In hrev31332 and hrev32674 problems retrieving the partition size have been fixed. Maybe that was related.