Hello,
I am happy to report a very smooth initial experience with Sculpt TC running in VirtualBox. I followed the tutorial (skipping the parts about virtualization, of course), and everything went well, with the exception of the minor error I will describe below. The Sculpt Manager is surprisingly convenient and mature, and the under-the-hood improvements are impressive as always. I really like the direction things are moving!
My only problem was building the "image/disk" version of the image.
For development, I am running an up-to-date Debian Unstable, which has worked well for me so far.
Here is the relevant part of the output:
checking configuration syntax CHECK init using 'core-nova.o' as 'core.o' Run script aborted because gdisk is not installed Makefile:312: recipe for target 'run/sculpt' failed make: *** [run/sculpt] Error 1
In fact, "gdisk" is installed, but it doesn't run under a normal user. I could hack the scripts to use "sudo", but I thought I'd check here first, in case there is a simple solution (since Ubuntu and Debian usually operate similarly).
I obviously don't expect Linux distro tech support - if there isn't an easy answer, I'll just install Ubuntu.
Thanks!
That's strange. I don't have that problem on Debian Stable.
On Tue, Jun 5, 2018, 5:01 PM John J. Karcher devuser@alternateapproach.com wrote:
Hello,
I am happy to report a very smooth initial experience with Sculpt TC running in VirtualBox. I followed the tutorial (skipping the parts about virtualization, of course), and everything went well, with the exception of the minor error I will describe below. The Sculpt Manager is surprisingly convenient and mature, and the under-the-hood improvements are impressive as always. I really like the direction things are moving!
My only problem was building the "image/disk" version of the image.
For development, I am running an up-to-date Debian Unstable, which has worked well for me so far.
Here is the relevant part of the output:
checking configuration syntax CHECK init using 'core-nova.o' as 'core.o' Run script aborted because gdisk is not installed Makefile:312: recipe for target 'run/sculpt' failed make: *** [run/sculpt] Error 1
In fact, "gdisk" is installed, but it doesn't run under a normal user. I could hack the scripts to use "sudo", but I thought I'd check here first, in case there is a simple solution (since Ubuntu and Debian usually operate similarly).
I obviously don't expect Linux distro tech support - if there isn't an easy answer, I'll just install Ubuntu.
Thanks!
John J. Karcher devuser@alternateapproach.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello John,
* John J. Karcher devuser@alternateapproach.com [2018-06-05 18:55:48 -0400]:
Run script aborted because gdisk is not installed Makefile:312: recipe for target 'run/sculpt' failed make: *** [run/sculpt] Error 1
In fact, "gdisk" is installed, but it doesn't run under a normal user. I could hack the scripts to use "sudo", but I thought I'd check here first, in case there is a simple solution (since Ubuntu and Debian usually operate similarly).
Please check if '/sbin' is included in your $PATH variable. There are distros, e.g. Debian, which do not set the common 'sbin' paths in the shell when executed as non-root user. This issue comes up now and then but so far we have not decided on how - and if at all - to solve it.
Personally, I always set the PATH variable myself so no suprises there.
Regards, Josef
On 06/06/2018 03:03 AM, Josef Söntgen wrote:
Hello John,
- John J. Karcher devuser@alternateapproach.com [2018-06-05 18:55:48 -0400]:
Run script aborted because gdisk is not installed Makefile:312: recipe for target 'run/sculpt' failed make: *** [run/sculpt] Error 1
In fact, "gdisk" is installed, but it doesn't run under a normal user. I could hack the scripts to use "sudo", but I thought I'd check here first, in case there is a simple solution (since Ubuntu and Debian usually operate similarly).
Please check if '/sbin' is included in your $PATH variable. There are distros, e.g. Debian, which do not set the common 'sbin' paths in the shell when executed as non-root user. This issue comes up now and then but so far we have not decided on how - and if at all - to solve it.
Personally, I always set the PATH variable myself so no suprises there.
Thanks, that was the problem. (I needed to add both "/sbin" and "/usr/sbin".)
But now I get a stranger error:
[...] using 'core-nova.o' as 'core.o' /sys/firmware/dmi/tables/smbios_entry_point: Permission denied /dev/mem: Operation not permitted while executing "exec parted -a none -s [run_dir].header -- rm 3" [...]
Since "Nobody III" says Debian Stable works, I'll just try that instead.
Thanks again!
Hello John,
I'd like to ask you to help me solving this issue.
I discovered in the Debian parted sources that the tool spawns "dmidecode -s system-manufacturer" since Debian version 3.2-21 to detect if it's running on Apple. If yes, it applies an heuristic to generate Apple-compatible GPT/MBR combinations (whatever that means - some comments mention "synced MBR"). Fortunately, they also added a force feature via the PARTED_GPT_APPLE environment variable.
So, could you please try to set the PARTED_GPT_APPLE env var to 0 before running the Genode build system. In bash this is as easy as
export PARTED_GPT_APPLE=0 make run/sculpt KERNEL=nova
Thanks in advance for your help.
Regards
Hello again,
On Thu, Jun 07, 2018 at 08:51:15AM +0200, Christian Helmuth wrote:
I'd like to ask you to help me solving this issue.
While investigating information for approaching the parted-devel mailing list with this issue, I discovered that the parted execution with recent versions logs permission denials but actually succeeds. So I created a patch for Genode to ignore parted's log messages to standard error, which I'd like to ask you to test.
https://github.com/genodelabs/genode/commit/01d0f2d464d855ddb05948e1ca7fbe97...
Thanks and regards
-
Christian Helmuth -
John J. Karcher -
Josef Söntgen -
Nobody III