Strange building of partition image

1

Hello, I am attempting to build Haiku under Gentoo GNU/Linux, direct to partition. That is, /dev/hda14 has permissions set to allow me to write to it, and UserBuildConfig is as below. However, when GRUB comes to boot from the partition it says that it can’t load the image. The command jam @disk mount is able to view the partition, but it shows one top-level directory myfs, under which are apps, common, develop, home, optional, system and var. Surely those sub-directories should actually be in the root, and there should not be the directory myfs ?


Grub entry:

title Haiku
rootnoverify (hd0,13)
chainloader +1
UserBuildConfig:
HAIKU_IMAGE_HOST_NAME = pimple ;

AddUserToHaikuImage mounty : 573 : 100 : /boot/home/mounty : /bin/bash : “Michael Mounteney” ;

AddOptionalHaikuImagePackages Beam ;
AddOptionalHaikuImagePackages BeHappy ;
AddOptionalHaikuImagePackages BePDF ;
AddOptionalHaikuImagePackages Firefox ;
AddOptionalHaikuImagePackages NetSurf ;
AddOptionalHaikuImagePackages OpenSSL ;
AddOptionalHaikuImagePackages OpenSSH ;
AddOptionalHaikuImagePackages Pe ;
AddOptionalHaikuImagePackages Vision ;
AddOptionalHaikuImagePackages Welcome ;
AddOptionalHaikuImagePackages WonderBrush ;

Add symlink/file (timezone and keymap settings) to the image.

AddSymlinkToHaikuImage home config settings
: /boot/system/etc/timezones/Australia/Adelaide : timezone ;

AddFilesToHaikuImage home config settings : “US-International” : Key_map ;

DefineBuildProfile disk : disk : “/dev/hda14” ;

HAIKU_IMAGE_NAME = hda14 ;
HAIKU_IMAGE_DIR = /dev ;

switch $(HAIKU_BUILD_PROFILE) {
case “disk” : {
AddOptionalHaikuImagePackages Beam BeBook BeHappy BePDF Bluetooth CVS
Development Firefox LibLayout Links NetSurf OpenSound OpenSSH
OpenSSL P7zip Pe Perl Subversion UserlandFS Vision VLC Welcome
WonderBrush Yasm ;
}

case "vmware" : {
	HAIKU_IMAGE_SIZE = 900 ;
}

}

HAIKU_BUILD_FEATURE_SSL = 1 ;

2

You’re mixing both the old style and new style in your UserBuildConfig. Look at UserBuildConfig & BuildProfiles.

3

As Matt says, you’ve got a huge mix of redundant info there…

You should start with the “DefineBuildProfile” line, and nothing more!

When building, you should build with jam -q @disk and make sure there are no errors

when using the “mount” action, myfs is indeed what replaces the /boot subfolder, and I believe the list of directories you’ve got are correct.

Hopefully you’re not attempting to any funny tricks with makebootable, as build directly to the partition should handle that.

Once you get a successful build to your partition, I highly suggest you take some time to understand what all the other stuff you added to your UserBuildConfig is doing - the extra use of variables, and switch logic redundantly specifying which optional packages is pretty much overkill.

Often times I end up with a UserBuildConfig that has no more than 3 or 4 lines.

4

OK, taken out all but the DefineBuildProfile line.

During building it says, warning: <src!bin!network!ftpd>ftpcmd.y depends on itself.

At the end of the build it says:

…
AddDirectoryToContainerCopyFilesScript system/data/licenses/-/data/system/data/licenses
InitScript1 generated/haiku.image-unzip-files
BuildHaikuImage1 /dev/hda14

Creating image …
Error: Failed to open “/dev/hda”: Permission denied
Populating image …
Deleting old MIME database …
Installing MIME database …
Unmounting …
…updated 1632 target(s)…

Is that /dev/hda error a clue ? Surely only the partition itself should be needed ? Why does it want to write the entire disk ? Still the same result though. The partition is unbootable. Any ideas where to look next ?
5

It needs read access to /dev/hda in order to read the partition offset…

you should do something like this:

sudo chmod o+r /dev/hda
sudo chmod o+rw /dev/hda14
jam -q @disk

the warning about the ftpcmd.y is known…

HTH!

6

You need to provide read access (write is not required) to the entire disk : the Haiku loader needs this to calculate the partition offset.

7

The fs_shell mounts the volume at /myfs in the internal name space; that’s surely nothing to worry about.

8

Thanks to you and others who replied. It’s working now, very well !

Gosh, it certainly is fast ! Pity a lot of my hardware isn’t seen but I expect drivers can be found, with some digging.

BTW, if you are building on GNU/Linux as I am, you can use /etc/udev/rules.d — I have added 99-hdpart.rules which has, amongst other things

KERNEL==“hda14” OWNER=“mounty” GROUP=“vboxusers” MODE="0660"
This sets permissions as I want them, with the udev file system.