Hi PulkoMandy, I followed your instructions and had to give it a couple hours to download. I had to issue the commands as root (sudo) since Ubuntu linux wont allow ordinary users to create directories outside of their home directory. I went into the newly created haiku directory and tried to run configure but, got the following message:
“Invalid argument: `–build-cross-tools”
Is there something different for linux build environmnts?
Why are you working outside of the home directory? These commands can be run inside your home, you do not need to mess with other parts of the OS. The “/boot/home” paths you may have seen are just where the home directory is when running Haiku. And the “boot/net/…” path to include files does not start with a slash, because it is a relative path (the build system knows where to look for the file, don’t worry)
I see there was some website formatting playing tricks on me. --build-cross-tools takes two dashes, and somehow it got converted to a single long dash, which won’t work.
Somehow my terminal was at root. I think I have moved everything to my home folder by issuing “cp -r /buildtools buildtools” and “cp -r /haiku haiku”. I then replaced the long dash with two short dashes and entered the configure command which ran for several minutes with lots of out put to the screen.
At this point I decided to follow Marcus’ intsructions from here:
but, when I issued “TARGET_BOOT_PLATFORM=pxe_ia32 jam pxehaiku-loader”, the response was, “You can only build Haiku with Haiku’s Jam, not Perforce Jam or some other variant (you are using 2.6).”. I had thought I was going to need jam at some point so I had done an “apt-get install jam”. To get rid of Ubuntu’s version of jam I issued “apt-get purge jam” after which the response to the jam command was “bash: /usr/bin/jam: No such file or directory”. It looks like I have messed up something!
I have created a “develop” folder in my home directory and I am in the process of using git to clone the buildtools to that directory after which I will be cloning haiku again and trying the process over again.
No, that is fine. You now need to build and install Haiku’s version of Jam. This is documented here (in this case it seems our build instructions are a bit out of order, we should probably rework this): Using Jam | Haiku Project
cd buildtools/jam
make
sudo ./jam0 install
Then you should be able to run Jam again. To check it is the right version, jam -v should say something with “Haiku” in it.
I’ve folowed your latest instructions but when I tried to run “jam -v” I get “bash: /usr/bin/jam: No such file or directory”. I noticed that the last three lines of out put from the jam install command were:
I issued “/usr/local/bin/jam -v” and the response was “Jam 2.5-haiku-20111222. OS=LINUX. Copyright 1993-2002 Christopher Seiwald.”. I suspect that somehow the path to jam has been set to “/usr/bin/jam” instead of “/usr/local/bin/jam”. What went wrong and how can I fix this?
PulkoMandy, I just did some poking around in my /usr/local/bin directory and the only file visible was jam! Does this mean that there is some sort of error in the build instructions that is putting jam in /usr/local/bin instead of /usr/bin ?
I also just ran “/usr/local/bin/jam -q run ‘:remote_disk_server’ /tfptboot/haiku.image” and surprisingly enough some messages that look very similar to the messages I got when trying to compile remote_disk_server on it’s own. The messages follow:
src/tools/remote_disk_server/remote_disk_server.cpp: In member function ‘void Server::_HandleReadRequest()’:
src/tools/remote_disk_server/remote_disk_server.cpp:199:65: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
printf(“READ request: offset: %llu, %hd bytes\n”, offset, size);
^
src/tools/remote_disk_server/remote_disk_server.cpp:216:37: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
“%s.”, offset, strerror(errno));
^
src/tools/remote_disk_server/remote_disk_server.cpp:221:29: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
offset, strerror(errno));
^
src/tools/remote_disk_server/remote_disk_server.cpp: In member function ‘void Server::_HandleWriteRequest()’:
src/tools/remote_disk_server/remote_disk_server.cpp:242:66: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
printf(“WRITE request: offset: %llu, %hd bytes\n”, offset, size);
^
src/tools/remote_disk_server/remote_disk_server.cpp:261:37: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
“%s.”, offset, strerror(errno));
^
src/tools/remote_disk_server/remote_disk_server.cpp:266:29: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t {aka long unsigned int}’ [-Wformat=]
offset, strerror(errno));
^
Usually the “local” directory is for things you compile and install yourself, while the normal “bin” directory is reserved for things installed through a package manager. However, this may be different depending on which distribution you use. It’s fine to run Jam with the absolute path as you did.
The warnings you listed are apparently because the remote_disk_server was not completely adjusted to build on 64bit. If you only see these warnings and no build errors, it should still run (you may have problems with format of some messages). If there is an error later on in the build, please let us see it. I guess no one has tested this in a while so it may be currently broken.
“/usr/local/bin/jam -q run ‘:remote_disk_server’ ~/tftpboot/haiku.image”
The test system is now getting an IP address from the DHCP server and starting the bootloader. The seven boot icons appear on the screen and the first four “light up”, the last three stay grayed out. The remote disk server on the host PC is disolaying output as shown on the page at the following link:
After a while the output from remote disk server freezes, the test system reboots and the output from remote disk server starts changing again. This is an unending loop.
The next step would be to grab a syslog, but I’m not sure if you can access the early boot menu for that when using the PXE loader. The alternative would be to get it from the COM port of the target machine, if there is one (they are getting rare), or maybe the system got far enough to write the syslog to haiku.image?
I tried the spacebar trick while booting to see if I could get a boot menu and that works so, I have access to all sorts of goodies from the boot menu. What do I start with? The system is based on Intel’s H67 chipset and a 3.3 GHz Sandy Bridge processor and is essentially “legacy free” so no PS/2 or COM or printer ports. I was able to find the point at which the remote_disk_server output freezes and the system reboots and have included the out put just before and after the reboot for what it’s worth. I tried a x86_64 nightly and a ggc2 hybrid nightly I downloaded, and an image I built myself and they all displayed similar behavior, except that the read offset when the boot process freezes is different. I suspect that nothing was written to the syslog since the output from the remote disk server does not include any write requests but, I can access the syslog from the previous boot according to the boot menu. I edited this post after I realized that I had not moved my keyboard to the test system so I was hitting the spacebar on a keyboard that wasn’t connected to the system!
From the boot menu you can enable on screen debug. This will log on screen what the system is doing.
Then you can see if there is an error message or how far it gets before running into problems.
You can take pictures of at least the last screen before a reboot or freeze and share it with us for further analysis
Yes, you should file a bugreport if there isn’t one already for this. I think this is as far as I got last time I tried a network boot as well. It seems the package manager filesystem does not like being mounted from the network for some reason.
There are seven bug reports with "PXE in the summary and the last and only open one is ticket #10198. While this is vaguely similar it is four years old and the person who reported it seems not to have gone any further than I have in terms of investigation. I did notice lines in the debug output starting with packagefs that suggest that there is a problem with the package fs. Should I file a new bug report or add something to ticket #10198?
I downloaded the most recent build I could find that did not have package management (hrev46101) and tried to boot that. All seven boot icons lit up but, it did not boot. I am currently downloading the first build I could find with package management included and will be checking to see what happens with that build.
Edit: I downloaded and attempted to boot hrev46154. It reverted to the behavior of the most recent builds, hanging with the last three boot icons grayed out and the rebooting.
Hi PulkoMandy, it’s been a while! II’ve just started looking at Haiku again, installing rev54010 on my laptop. I still have to use safe graphics mode but, my WiFi works as does audio. I’m just wondering if the PXE boot issues discussed in this thread were ever fixed? The fact that there is a guide “Network Booting Haiku” on the Haiku web site would suggest this but, that guide may have been there from before package management was implemented. I don’t remember if that guide existed when I started this thread.
I think nothing changed. I’m trying to use network booting for the SPARC port but it does not boot this far, yet, so I have not done anything for this specific issue. And I think no one else did.
From the post at the following link, it looks like you won’t get very far booting the ARM port either. Should I just watch the bug reports to see when this one is squashed?
