fakerootng-devel Mailing List for Fakeroot Next Gen
Run processes with fake root environment
Brought to you by:
thesun
Menu
▾
▴
fakerootng-devel — Development related discussions
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(4) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
(13) |
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(7) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(2) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shachar S. <sh...@sh...> - 2022-06-15 01:41:47
|
<html style="direction: ltr;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body bidimailui-charset-is-forced="true" style="direction: ltr;">
<p>Hello Cat,</p>
<p><br>
</p>
<p>First of all, thank you for trying to make fakeroot-ng better. I
appreciate the effort.</p>
<p><br>
</p>
<p>Sadly, neither patch is applyable as submitted. The first patch
changes a file that is not part of the source set, but is
generated by running autotools on the configure.ac file. Worse,
the lines you made the changes in are expanded wholesale from a
built-in macro. In particular, I'm pretty sure the
"AC_CANONICAL_TARGET" macro on line 6 of configure.ac is
responsible for the check you're trying to patch. As such, the
correct place to patch it is in the autoconf project rather than
here.</p>
<p><br>
</p>
<p>If that's not possible, the second best option for patching this
bug is at the distribution level. Assuming you ran bootstrap on
the same musl machine, and that autoconf came from your
distribution, then it can patch the macro to correctly identify
the machine.</p>
<p><br>
</p>
<p>Patching this problem at the fakeroot-ng level is a last resort,
as the whole point of using autoconf is so that the individual
projects not need to do their own platform-specific detection.
Even if that's where you're at, a last resort move, patching it at
the configure script level simply won't work. This is a generated
file, is not part of the version control, and cannot be patched
manually.</p>
<p><br>
</p>
<p>So, before trying to patch anything, I urge you to make sure the
auto-tools are installed on your system and just run "autoconf
-i". I am guessing you downloaded a source tar release, rather
than checking it out from git, and that may come with a configure
script that was generated by a very old version of autoconf. It is
more than likely that a newer version already knows how to detect
musl, and will simply not have this bug.</p>
<p><br>
</p>
<p><br>
</p>
<p>As for your second patch: it resolves compilation errors in musl,
but generates them on glibc. Fakeroot-ng is written in C++, and
the difference between an enum and an int is important to it. The
correct approach to resolve this is to have configure detect the
musl distribution (probably setting TARGET_OS to linux-musl), and
having an #ifdef in the code to define a typedef, say,
PtraceRequest, to either __ptrace_request or int. This solution
will work on both glibc and musl.</p>
<p><br>
</p>
<p>I tried to install a musl based distro on a VM, but I'm not sure
which distro is recommended for that. I tried Alpine Linux, but
couldn't get it to install autoconf. If you can recommend a
distribution and write a couple of lines on how to set up a
suitable build environment, I can try and solve these problems
myself.</p>
<p><br>
</p>
<p>Thank you,</p>
<p>Shachar<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 15/06/2022 01:58, cat--- via
Fakerootng-devel wrote:<br>
</div>
<blockquote type="cite" cite="mid:N4Z...@ca...">
<pre class="moz-quote-pre" wrap="">Hello there! I have two patches fixing musl support for fakeroot-ng.
Fakeroot-ng currently hardcodes "linux-gnu" in it's configure script. The first one adds another check for linux-musl as well.
Fakeroot-ng also uses the enum __ptrace_request which is only defined in GNU libc. The second patch subsitutes it for "int" making the tool more portable.
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Fakerootng-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Fak...@li...">Fak...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/fakerootng-devel">https://lists.sourceforge.net/lists/listinfo/fakerootng-devel</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Shachar S. <sh...@sh...> - 2022-06-15 01:40:28
|
<html style="direction: ltr;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bidimailui-charset-is-forced="true" style="direction: ltr;">
<p><br>
</p>
<div class="moz-cite-prefix">On 15/06/2022 04:23, Shachar Shemesh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4f7...@sh...">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; }</style>Worse,
the lines you made the changes in are expanded wholesale from a
built-in macro. In particular, I'm pretty sure the
"AC_CANONICAL_TARGET" macro on line 6 of configure.ac is
responsible for the check you're trying to patch. As such, the
correct place to patch it is in the autoconf project rather than
here.</blockquote>
<p>Actually, on second look, those lines do come from code inside
fakeroot-ng. It just needs to make the same change in configure.ac
rather than in configure.</p>
<p><br>
</p>
<p>My bad. Sorry.</p>
<p><br>
</p>
<p>Shachar<br>
</p>
</body>
</html>
|
|
From: <ca...@ca...> - 2022-06-14 23:15:37
|
Hello there! I have two patches fixing musl support for fakeroot-ng. Fakeroot-ng currently hardcodes "linux-gnu" in it's configure script. The first one adds another check for linux-musl as well. Fakeroot-ng also uses the enum __ptrace_request which is only defined in GNU libc. The second patch subsitutes it for "int" making the tool more portable. -- Sent with Tutanota, enjoy secure & ad-free emails. |
|
From: Shachar S. <sh...@sh...> - 2017-03-17 08:02:46
|
On 17/03/17 09:54, Drew DeVault wrote: > Thanks for the lesson /s. I will be writing my own program in C to fill > this niche, because I have little faith that you can be convinced not to > use boost or to take musl support seriously. I was convinced of that > when I wrote my last email, too. I would have to eventually write my own > anyway because I want to remove C++ from my base system wherever > possible. > > Best of luck with fakeroot-ng. I'm off to write fakeroot-ng-ng. By all means send me a link to the repository as soon as it's up. I will be most interested to see how your efforts come along. Who knows, I may even change my mind. I will also be happy to post a link to it on the fakeroot-ng web site, as soon as it is capable of doing anything constructive. Shachar |
|
From: Drew D. <si...@cm...> - 2017-03-17 07:54:38
|
Thanks for the lesson /s. I will be writing my own program in C to fill this niche, because I have little faith that you can be convinced not to use boost or to take musl support seriously. I was convinced of that when I wrote my last email, too. I would have to eventually write my own anyway because I want to remove C++ from my base system wherever possible. Best of luck with fakeroot-ng. I'm off to write fakeroot-ng-ng. On 2017-03-17 9:50 AM, Shachar Shemesh wrote: > I'm sorry, but here is a very quick lesson in open source development: > > On 17/03/17 09:14, Drew DeVault wrote: > > If you haven't heard of it that's not really my > > problem. > Then why are you asking me for help? > > > > It supports boost, though. Musl isn't objecting to boost. I am. Boost is > > a _huge_ library and the features you're mentioning are of questionable > > utility. > Feel free to suggest alternatives. > http://stackoverflow.com/questions/22427743/daemonize-keeping-a-c-ostream-open > has the problem to which this is the solution. Patches welcome. > > Using it in fakeroot-ng adds 143 MiB to fakeroot-ng's > > footprint. It's not a good call. > I have no idea where that number comes from. Statically compiled > fakeroot-ng is 2.7MB. Dynamically compiled is 2.6MB and the boost > iostreams library is 96KB (132KB including the rest of the package's > files), and it carries no dependency on any other part of boost. That's > on Debian. > > Neither was using C++ in the first > > place, but we're long past changing that. > What you are effectively saying is "I disresepct your choice because it > does not align with my personal preference". With all due respect, it > was, and still is, my choice to make. You're getting to use a tool that > I've spent months of unpaid time in creating and debugging. You are > getting my time in trying to help you solve a problem with that tool. I > don't think a little humility, respect, and backing up your criticism > with some substance is too much to ask in return. > > You can certainly gain my respect by porting fakeroot-ng to the language > of your choice, and showing me that it is at least as performant and as > easy to maintain as the C++ version. I am not aware of a language that > can give you that. This is open source. Code speaks louder than words. > Feel free to prove me wrong. > > > I agree. We shouldn't substitute glibc-isms with musl-isms. But that > > shouldn't be necessary. > Then, by all means, let's find the source of the failure. > > Shachar > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Fakerootng-devel mailing list > Fak...@li... > https://lists.sourceforge.net/lists/listinfo/fakerootng-devel |
|
From: Shachar S. <sh...@sh...> - 2017-03-17 07:50:57
|
I'm sorry, but here is a very quick lesson in open source development: On 17/03/17 09:14, Drew DeVault wrote: > If you haven't heard of it that's not really my > problem. Then why are you asking me for help? > > It supports boost, though. Musl isn't objecting to boost. I am. Boost is > a _huge_ library and the features you're mentioning are of questionable > utility. Feel free to suggest alternatives. http://stackoverflow.com/questions/22427743/daemonize-keeping-a-c-ostream-open has the problem to which this is the solution. Patches welcome. > Using it in fakeroot-ng adds 143 MiB to fakeroot-ng's > footprint. It's not a good call. I have no idea where that number comes from. Statically compiled fakeroot-ng is 2.7MB. Dynamically compiled is 2.6MB and the boost iostreams library is 96KB (132KB including the rest of the package's files), and it carries no dependency on any other part of boost. That's on Debian. > Neither was using C++ in the first > place, but we're long past changing that. What you are effectively saying is "I disresepct your choice because it does not align with my personal preference". With all due respect, it was, and still is, my choice to make. You're getting to use a tool that I've spent months of unpaid time in creating and debugging. You are getting my time in trying to help you solve a problem with that tool. I don't think a little humility, respect, and backing up your criticism with some substance is too much to ask in return. You can certainly gain my respect by porting fakeroot-ng to the language of your choice, and showing me that it is at least as performant and as easy to maintain as the C++ version. I am not aware of a language that can give you that. This is open source. Code speaks louder than words. Feel free to prove me wrong. > I agree. We shouldn't substitute glibc-isms with musl-isms. But that > shouldn't be necessary. Then, by all means, let's find the source of the failure. Shachar |
|
From: Drew D. <fak...@cm...> - 2017-03-17 07:14:43
|
Sorry, responded off-list. Reposting to list. On 2017-03-17 9:01 AM, Shachar Shemesh wrote: > Patches welcome. I really mean that. If I'm relying on GNU > ideosyncracies, I'd like to know about it. If, on the other hand, I'm > doing something completely POSIX compliant which musl happens to not > support, you might find me harder to convince. Well, there was a patch included in my original email so that you could build and try it with musl yourself. I wouldn't consider it for merging upstream until we sort out the rest of the issues, though. > Maybe. As I don't know your library, I cannot really help you much on > that front. > > Either way, that's not what I meant. What I meant was that the runtime > library with which fakeroot-ng was compiled does not affect the programs > it controls. You can compile fakeroot-ng with glibc (say, statically), > and then use it to control musl compiled binaries. Unlike the LD_PRELOAD > approach, this should work without a problem. Maybe, but it should work on any standard libc, no? I don't want to have to port glibc and set up an environment for building one particular package on it. That's contrary to the goal of a self-hosting distribution. > > fakeroot-ng died with SIGABORT in res_mkquery in musl. > So it died on an assert error inside the run time library. Right off the > bat, that's a bug in musl. A run time library should not assert, even if > passed incorrect arguments. If you follow the backtrace upwards, you > will find what fakeroot-ng did to trigger this condition. Please paste > the full backtrace here, and we can try and work it out together (but > you'll have to be a part of that, as I don't know musl). Well, musl is free software and fairly trivial to use alongside glibc. $ curl -O http://www.musl-libc.org/releases/musl-1.1.16.tar.gz $ tar xf musl-1.1.16.tar.gz && cd musl $ ./configure $ make # make install $ cd ~/fakeroot-ng $ CC=musl-gcc ./configure I'm not very comfortable with debugging C++, I would appreciate some help on this front. I will obtain a better backtrace, let me set up a new environment to test in. > I'm sorry if this sounds harsh, but I will not give up on useful, and > above all, quite mainline libraries to support a runtime library that > I've never heard of before. If there are changes that can be made to > support both with not too much library specific code, I'll gladly do it. > However, if your run time does not support the #1 C++ extension library, > which is considered the staging area for future C++ standards, then > there's something wrong with your run time. Musl is probably the largest linux libc outside of glibc. It's shipped as the default libc on several distros and packaged as an alternative libc in most others. If you haven't heard of it that's not really my problem. It supports boost, though. Musl isn't objecting to boost. I am. Boost is a _huge_ library and the features you're mentioning are of questionable utility. Using it in fakeroot-ng adds 143 MiB to fakeroot-ng's footprint. It's not a good call. Neither was using C++ in the first place, but we're long past changing that. > I want to re-iterate. I'm all for fakeroot-ng not relying on glibc > ideosyncracies, and being as portable as possible. For this reason, I'll > gladly work with you on resolving this issue. The line is drawn, > however, at introducing another library's ideosyncracies into the code. I agree. We shouldn't substitute glibc-isms with musl-isms. But that shouldn't be necessary. -- Drew DeVault |
|
From: Shachar S. <sh...@sh...> - 2017-03-17 07:02:08
|
On 17/03/17 08:35, Drew DeVault wrote: > On 2017-03-16 9:01 PM, Shachar Shemesh wrote: >> The runtime library used should not affect fakeroot-ng in any way. > It seems to, though. I had to fix a lot of GNUisms in the code, Patches welcome. I really mean that. If I'm relying on GNU ideosyncracies, I'd like to know about it. If, on the other hand, I'm doing something completely POSIX compliant which musl happens to not support, you might find me harder to convince. > it > wouldn't surprise me if there were more undetected glibc-related > assumptions. Maybe. As I don't know your library, I cannot really help you much on that front. Either way, that's not what I meant. What I meant was that the runtime library with which fakeroot-ng was compiled does not affect the programs it controls. You can compile fakeroot-ng with glibc (say, statically), and then use it to control musl compiled binaries. Unlike the LD_PRELOAD approach, this should work without a problem. > I get a core dump for fakeroot-ng and for bash: > fakeroot-ng: https://sr.ht/uUXh.core > bash: https://sr.ht/gL6T.core > > I pulled them up in gdb but it's hard to tell exactly what went wrong. > Bash died in SIGTRAP with a stacktrace that doesn't go anywhere near > debug symbols. SIGTRAP is what the debugee "sees" when the debugger stops it. If fakeroot-ng crashed, that's normal and nothing to see there. > fakeroot-ng died with SIGABORT in res_mkquery in musl. So it died on an assert error inside the run time library. Right off the bat, that's a bug in musl. A run time library should not assert, even if passed incorrect arguments. If you follow the backtrace upwards, you will find what fakeroot-ng did to trigger this condition. Please paste the full backtrace here, and we can try and work it out together (but you'll have to be a part of that, as I don't know musl). > >> Also, after running "touch foobar", see if "id" returns root. > id returns my normal user. Yes. That was just a test to see whether fakeroot-ng simply did not handle the stat correctly, or whether it crashed. Since we already know it crashed, this is not surprising. > > I'll try that branch when I have time, but porting boost to my system is > a tall order. Is it really necessary to depend on boost? What do you > gain from it? iostream wrapper (for turning a generic fd into an iostream, which I use for logging) and intrusive_ptr (which I doubt very very very much is hard to port, as it's tiny and quite self contained). I'm sorry if this sounds harsh, but I will not give up on useful, and above all, quite mainline libraries to support a runtime library that I've never heard of before. If there are changes that can be made to support both with not too much library specific code, I'll gladly do it. However, if your run time does not support the #1 C++ extension library, which is considered the staging area for future C++ standards, then there's something wrong with your run time. > I want to use fakeroot-ng for my package manager but I'd > sooner figure something else out than include boost in my base system. You can always compile fakeroot-ng statically on a glibc system and use the binary. Like I said, it does not rely on any specific run time library being in use. In fact, part of the complexity of writing it was the fact that it wraps the libc->kernel interface, rather than the much better documented program->libc interface, as LD_PRELOAD does. I want to re-iterate. I'm all for fakeroot-ng not relying on glibc ideosyncracies, and being as portable as possible. For this reason, I'll gladly work with you on resolving this issue. The line is drawn, however, at introducing another library's ideosyncracies into the code. Shachar |
|
From: Drew D. <fak...@cm...> - 2017-03-17 06:35:45
|
On 2017-03-16 9:01 PM, Shachar Shemesh wrote: > The runtime library used should not affect fakeroot-ng in any way. It seems to, though. I had to fix a lot of GNUisms in the code, it wouldn't surprise me if there were more undetected glibc-related assumptions. > > $ ./fakeroot-ng -llog -f sh > > # touch foobar > > # ls -l foobar > > > > Shows foobar with the original permissions. The log is attached, as well > > as a patch to compile fakeroot-ng with musl. Any ideas? I'm not really > > sure how to debug this program. > Please provide more information. In particular, did fakeroot-ng crash? > You can tell by running it with the "-d" flag, which causes it not to > detach itself. Run "ulimit -c unlimited" before starting fakeroot-ng, > and see whether a core file is generated. I get a core dump for fakeroot-ng and for bash: fakeroot-ng: https://sr.ht/uUXh.core bash: https://sr.ht/gL6T.core I pulled them up in gdb but it's hard to tell exactly what went wrong. Bash died in SIGTRAP with a stacktrace that doesn't go anywhere near debug symbols. fakeroot-ng died with SIGABORT in res_mkquery in musl. > Also, after running "touch foobar", see if "id" returns root. id returns my normal user. > What I suspect happens is that you are using 64bit fakeroot-ng with > 32bit shell/touch/ls (mostly the last one). If that's the case, then try > compiling the version in the multithreaded_debugger branch. While not > yet prime time ready, it is fairly feature complete for the basic > features, and it supports cross platform execution better than the > version in master. I'll try that branch when I have time, but porting boost to my system is a tall order. Is it really necessary to depend on boost? What do you gain from it? I want to use fakeroot-ng for my package manager but I'd sooner figure something else out than include boost in my base system. -- Drew DeVault |
|
From: Shachar S. <sh...@sh...> - 2017-03-16 19:18:34
|
Hi Drew, On 15/03/17 20:41, Drew DeVault wrote: > I've been trying to get fakeroot-ng to work on a system based on musl > libc rather than glibc, but have run into problems. The following > procedure: The runtime library used should not affect fakeroot-ng in any way. > > $ ./fakeroot-ng -llog -f sh > # touch foobar > # ls -l foobar > > Shows foobar with the original permissions. The log is attached, as well > as a patch to compile fakeroot-ng with musl. Any ideas? I'm not really > sure how to debug this program. Please provide more information. In particular, did fakeroot-ng crash? You can tell by running it with the "-d" flag, which causes it not to detach itself. Run "ulimit -c unlimited" before starting fakeroot-ng, and see whether a core file is generated. Also, after running "touch foobar", see if "id" returns root. What I suspect happens is that you are using 64bit fakeroot-ng with 32bit shell/touch/ls (mostly the last one). If that's the case, then try compiling the version in the multithreaded_debugger branch. While not yet prime time ready, it is fairly feature complete for the basic features, and it supports cross platform execution better than the version in master. Shachar |
|
From: Drew D. <fak...@cm...> - 2017-03-15 18:41:39
|
I've been trying to get fakeroot-ng to work on a system based on musl libc rather than glibc, but have run into problems. The following procedure: $ ./fakeroot-ng -llog -f sh # touch foobar # ls -l foobar Shows foobar with the original permissions. The log is attached, as well as a patch to compile fakeroot-ng with musl. Any ideas? I'm not really sure how to debug this program. A statically linked version of fakeroot-ng compiled with musl and with debug symbols enabled is here for convenience: https://sr.ht/QYRZ.fakerootng -- Drew DeVault |
|
From: Shachar S. <sh...@sh...> - 2016-08-20 10:49:08
|
Hello Mark, You should know that the head of the git branch for the next version of fakeroot-ng has a fairly functional support for running i686 processes controlled by a x86_64 debugger. If you're interested, you can check out the "multithreaded_debugger" branch and check it out. Shachar On 10 Nov 2015 10:36 p.m., Shachar Shemesh <sh...@sh...> wrote: On 10/11/15 21:27, Марк Коренберг wrote: 1. I did not check, but for example, is this handled right: http://linux.die.net/man/2/socketcall ? At this point in time, probably not. Please note, however, that there is very little in that particular system call that is of interest to fakeroot-ng. Mostly, the bind and connect syscalls for unix domain sockets might need translation if they happen inside a "chroot". With that said, there is nothing preventing implementation. It's just a matter of priorities. 2. on different architectures, syscall have different values. For example: ./x86_64-linux-gnu/asm/unistd_64.h:#define __NR_readlinkat 267 ./x86_64-linux-gnu/asm/unistd_32.h:#define __NR_readlinkat 305 Is this handled ? Yes. See arch/linux/x86_64/platform.cpp Shachar |
|
From: Shachar S. <sh...@sh...> - 2015-12-08 19:40:16
|
On 08/12/15 20:27, James Benze wrote: > Hello, > > I think I found a bug in fakeroot-ng, and I'm trying to determine how > best to submit a bug report. I'm using fakeroot-ng in conjunction > with chroot, and somehow shebangs inside the chroot are finding their > way outside. > > If I have the following script inside the chroot > > > #!/bin/sh > > echo "HELLO WORLD" > Hello James, It's not exactly a bug. More of a known limitation. When performing execve, the kernel does the inital loading of the interpreter, leaving it up to it to finish loading related files (libraries etc.). Since fakeroot-ng wraps the userspace kernel calls, the kernel's initial loading of the interpreter is done without fakeroot-ng interecepting. As a result, as you've mentioned, the shell being loaded is outside of the chroot shell. I actually do have a roadmap plan to fix this, but this would require a significant extra work for each execve (essentially, duplicating the kernel loader). I'm not sure what the performance penalty is going to be. It is pretty clear that some chroots will simply not work without it. For the time being, yes, it is a known issue. Shachar |
|
From: James B. <ben...@gm...> - 2015-12-08 18:27:09
|
Hello, I think I found a bug in fakeroot-ng, and I'm trying to determine how best to submit a bug report. I'm using fakeroot-ng in conjunction with chroot, and somehow shebangs inside the chroot are finding their way outside. If I have the following script inside the chroot > #!/bin/sh > echo "HELLO WORLD" Then enter the chroot environment with fakeroot-ng chroot chroot-folder/ /tmp/tools/bin/bash running "./test_script" gives me the following error /bin/sh: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory It would appear that somehow the shebang is connecting to the /bin/sh *outside* of the chroot, as that executable is linked to libreadline.so.6 and the chroot-folder/bin/sh does not (chroot-folder/bin/sh is actually a symlink to /tmp/tools/bin/bash, but it doesn't link to libreadline) if I run "/bin/sh test_script" to ignore the shebang, everything works as intended. If I replace "fakeroot-ng" with "sudo" to get a real root environment, the shebangs work as normal as well, implying to me that this is a fakeroot-ng problem. I would love either some direction I could take to solve this problem, or directions on how to submit a more formal bug report. Cheers, James Benze |
|
From: Shachar S. <sh...@sh...> - 2015-11-10 20:35:58
|
On 10/11/15 21:27, Марк Коренберг wrote: > 1. I did not check, but for example, is this handled right: > http://linux.die.net/man/2/socketcall ? At this point in time, probably not. Please note, however, that there is very little in that particular system call that is of interest to fakeroot-ng. Mostly, the bind and connect syscalls for unix domain sockets might need translation if they happen inside a "chroot". With that said, there is nothing preventing implementation. It's just a matter of priorities. > > 2. on different architectures, syscall have different values. For example: > > ./x86_64-linux-gnu/asm/unistd_64.h:#define __NR_readlinkat 267 > ./x86_64-linux-gnu/asm/unistd_32.h:#define __NR_readlinkat 305 > > Is this handled ? Yes. See arch/linux/x86_64/platform.cpp Shachar |
|
From: Марк К. <soc...@gm...> - 2015-11-10 19:28:03
|
1. I did not check, but for example, is this handled right: http://linux.die.net/man/2/socketcall ? 2. on different architectures, syscall have different values. For example: ./x86_64-linux-gnu/asm/unistd_64.h:#define __NR_readlinkat 267 ./x86_64-linux-gnu/asm/unistd_32.h:#define __NR_readlinkat 305 Is this handled ? 2015-10-30 12:59 GMT+05:00 Shachar Shemesh <sh...@sh...>: > Hello Mark, > > First, cool gmail username. Thumbs up. > > I am unaware of the platform difference causing data corruption. The cross > platform support in fakeroot-ng is currently broken, but mostly around the > "stat" function call. This means that 32bit function will get an incorrect > view of the fake state of files. If you know of a different problem, please > let me know the exact scenario in which it happens. > > In principle, at the moment, fakeroot-ng does not support cross platform > running, for precisely the reason stated above. I started working on a side > branch where things are, probably, much better, but due to high work load on > my day job, I have been unable to advance it in the recent months. I will > update on this list when I deem it ready. > > The syscall number difference is not the source of your problem. As far as I > know, the code currently in fakeroot-ng is adequate to handle that > difference. Again, if you have a specific scenario in which this is not the > case, please post it here so I can have a look at it. > > Shachar > > > > On 28/10/2015 23:05, Марк Коренберг wrote: > > Hello. I have found that using fakeroot-ng in cross-architecture environment > (run i686 programs on AMD64 environment) may lead to data loss (or > corruption). I mean case when fake-rooted amd64 process do execve() and > become i686 process. > > This may happen due to fact that fakeroot-ng tries to interpret syscalls not > for the architecture of the process it debugs, but for the architecture it > is built for. > > Since syscall numbers (and arguments, i.e. CPU registers) differ, data may > be lost when fakeroot-ng modifies memory and re-executes syscalls. > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Fakerootng-devel mailing list > Fak...@li... > https://lists.sourceforge.net/lists/listinfo/fakerootng-devel > > > > -- Segmentation fault |
|
From: Марк К. <soc...@gm...> - 2015-10-28 21:05:16
|
Hello. I have found that using fakeroot-ng in cross-architecture environment (run i686 programs on AMD64 environment) may lead to data loss (or corruption). I mean case when fake-rooted amd64 process do execve() and become i686 process. This may happen due to fact that fakeroot-ng tries to interpret syscalls not for the architecture of the process it debugs, but for the architecture it is built for. Since syscall numbers (and arguments, i.e. CPU registers) differ, data may be lost when fakeroot-ng modifies memory and re-executes syscalls. |
|
From: Shachar S. <sh...@sh...> - 2015-03-19 18:59:16
|
On 19/03/15 19:55, Ryan Smith-Roberts wrote: > Interesting device node creation assertion failure. Output sanitized for > your protection: > > $ fakeroot-ng -p .fakeroot-ng.persist -d tar xf chroot.tar ./dev/mixer3 > fakeroot-ng: parent.cpp:635: int process_sigchld(pid_t, PTLIB_WAIT_RET, > int, long int): Assertion `proc_state->state!=pid_state::RETURN || > ret==proc_state->orig_sc' failed. > tar: ./dev/mixer3: Cannot mknod: Bad address > tar: Exiting with failure status due to previous errors > $ uname -a > Linux hostname 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12 12:19:35 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > $ lsb_release -d > Description: Ubuntu 14.10 Hi Ryan, Thanks for your report. Unfortunately, Fakroot-ng is somewhat limboed on the master branch (which is where Ubuntu derive their packages). I am currently working on a branch designed to make things both faster and better (for some definition of both words). Unfortunately, the practical upshot of the above is that the code path that fails for you simply no longer exists in the current development branch. It would be very difficult for me, and indeed, a waste of my scarce time working on fakeroot-ng, to try and debug this bug in a dead end branch. The good news is that, after a very long time away, I was able, today, to make some important progress on the branch. As such, there is some hope that in the coming few weeks I'll be able to release a version that could be called a minimal viable version (maybe better labeled as minimally viable). I'm hoping this will clear up most of the remaining issues with the branch, allowing me to bring it up to feature parity with master. As it seems you need the chroot capability, which will not be in the MVV, that is an important step. I'm sorry I cannot be of more assistance. Shachar |
|
From: Ryan Smith-R. <rm...@pu...> - 2015-03-19 18:22:21
|
Interesting device node creation assertion failure. Output sanitized for your protection: $ fakeroot-ng -p .fakeroot-ng.persist -d tar xf chroot.tar ./dev/mixer3 fakeroot-ng: parent.cpp:635: int process_sigchld(pid_t, PTLIB_WAIT_RET, int, long int): Assertion `proc_state->state!=pid_state::RETURN || ret==proc_state->orig_sc' failed. tar: ./dev/mixer3: Cannot mknod: Bad address tar: Exiting with failure status due to previous errors $ uname -a Linux hostname 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -d Description: Ubuntu 14.10 -- Ryan Smith-Roberts ----- System Architect @ Purism rm...@pu... -- The Libre laptop - https://puri.sm 785A 4DDA 1984 4FCD F96D D011 34BB 4D81 9405 98C9 |
|
From: <sh...@sh...> - 2014-11-10 12:42:47
|
On 31/10/2014 05:42, Pradeepa Senanayake wrote: > But that is working in Ubuntu 12.04 32bit. I did not try with Ubuntu 14.04 32bit. At the moment, fakeroot-ng has poor support for running 32 bit executables from 64 bit fakeroot-ng. This is a known issue. I am currently working on a newer version (which is almost a rewrite) that will, among many other changes, also resolve this problem. As such, I'm afraid that it is not likely that this problem will be resolved within the current branch. > I am using Ubuntu 14.04 64bit. > > All those 'mknod's are executed within an install script. I cannot change the script because it is working in Ubuntu 12.04 and other developers are using it. Is this a feature? or a bug? Is it possible that a private version of mknod is used that is, say, within a chroot that is 32 bit? > Also, is "fakeroot-ng <command>" different from executing the "<command>" within fakeroot-ng? No. Shachar |
|
From: Pradeepa S. <pra...@gm...> - 2014-10-31 03:42:37
|
Hello, > What about: > $ fakeroot-ng mknod > /home/pradeepas/testing_non_sudo_build/zone_bare_repository/src/Components/root-file-system/tmp/rootfs/dev/tty > c 5 0 > > ? > > Shachar > > It is successful. And I can see the tty device also, $ ls -la total 8 drwxrwxr-x 2 pradeepas pradeepas 4096 Oct 31 08:58 . drwxrwxr-x 17 pradeepas pradeepas 4096 Oct 30 18:50 .. lrwxrwxrwx 1 pradeepas pradeepas 12 Oct 30 18:50 mtab -> /proc/mounts -rw-rw-r-- 1 pradeepas pradeepas 0 Oct 31 08:58 tty But when I run fakeroot-ng and go into the fakeroot and then execute the command it is not working. But that is working in Ubuntu 12.04 32bit. I did not try with Ubuntu 14.04 32bit. I am using Ubuntu 14.04 64bit. All those 'mknod's are executed within an install script. I cannot change the script because it is working in Ubuntu 12.04 and other developers are using it. Is this a feature? or a bug? Also, is "fakeroot-ng <command>" different from executing the "<command>" within fakeroot-ng? -Pradeepa |
|
From: Shachar S. <sh...@sh...> - 2014-10-30 21:23:34
|
Welcome back: On 30/10/14 15:10, Pradeepa Senanayake wrote: > Hello, > > What happens if you run just fakeroot-ng and the chmod operation? > > > $: mknod > /home/pradeepas/testing_non_sudo_build/zone_bare_repository/src/Components/root-file-system/tmp/rootfs/dev/tty > c 5 0 > What about: $ fakeroot-ng mknod /home/pradeepas/testing_non_sudo_build/zone_bare_repository/src/Components/root-file-system/tmp/rootfs/dev/tty c 5 0 ? Shachar |
|
From: Pradeepa S. <pra...@gm...> - 2014-10-30 13:10:26
|
Hello, What happens if you run just fakeroot-ng and the chmod operation? > > Shachar > > $: mknod /home/pradeepas/testing_non_sudo_build/zone_bare_repository/src/Components/root-file-system/tmp/rootfs/dev/tty c 5 0 mknod: ‘/home/pradeepas/testing_non_sudo_build/zone_bare_repository/src/Components/root-file-system/tmp/rootfs/dev/tty’: Operation not permitted This is exactly what is happening when I execute the mknod command in the fakeroot-ng environment. Thank you. |
|
From: Shachar S. <sh...@sh...> - 2014-08-20 17:45:37
|
On 20/08/14 12:31, Pradeepa Senanayake wrote: > Hello, > > I am sorry for providing you less information. In-fact it is happening > when I build the root-file-system skeliton. It installs the whole > rootfs to a temp folder and uses the temp folder to create the image. > (this was working in fakeroot, but with Ubinti x64 it looks like > fakeroot is not working) When it is creating the skeliton it needs to > do execute commands like chmod, mknod and ln. When executing the mknod > command only it is failing. > > mknod: > ‘/home/pradeepas/example/source_base/src/Components/root-file-system/tmp/rootfs/dev/tty’: > Operation not permitted > > This is the line which is failing. What happens if you run just fakeroot-ng and the chmod operation? Shachar > > --Pradeepa > > > -Pradeepa > > > On Fri, Aug 15, 2014 at 11:08 PM, Shachar Shemesh <sh...@sh... > <mailto:sh...@sh...>> wrote: > > On 14/08/14 08:51, Pradeepa Senanayake wrote: >> Hello, >> >> I'm building a Kernel in the fakeroot-ng environment. >> >> I'm using ubuntu-14.04 x64 version as my OS. >> >> During the kernel build, there are some mknode calls. But they >> fail with "Operation not Permitted" as error messages. >> >> Is this a known issue? Is there any workaround? >> > Hello Pradeepa, > > I suspect there is something missing from your description of the > problem. The kernel does not, normally, require root permissions > during build. It follows, then, that it does not call mknod. I > suspect what you're actually trying to do is to *install* a kernel. > > Fakeroot-ng is an unprivileged program. When you "mknod" inside > the fakeroot-ng environment, it does not really create a device > file. Instead, it creates a regular file, and marks for itself to > lie to you about what that file actually is later on. This works > great if you are trying to create installation images using an > archive tool. It does not work if you are trying to actually > install something on your live system. For that, you will need > actual root. > > I suspect that the EPERM error you're seeing is because your user > does not have permission to create regular files under /dev. If > that's the case, then that is not a bug in fakeroot-ng. It is > working as intended. > > The workaround depends on what you're actually trying to achieve. > If you elaborate, we can figure out what is the best way to do it. > > Shachar > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > _______________________________________________ > Fakerootng-devel mailing list > Fak...@li... > https://lists.sourceforge.net/lists/listinfo/fakerootng-devel |
|
From: Pradeepa S. <pra...@gm...> - 2014-08-20 09:32:00
|
Hello, I am sorry for providing you less information. In-fact it is happening when I build the root-file-system skeliton. It installs the whole rootfs to a temp folder and uses the temp folder to create the image. (this was working in fakeroot, but with Ubinti x64 it looks like fakeroot is not working) When it is creating the skeliton it needs to do execute commands like chmod, mknod and ln. When executing the mknod command only it is failing. mknod: ‘/home/pradeepas/example/source_base/src/Components/root-file-system/tmp/rootfs/dev/tty’: Operation not permitted This is the line which is failing. --Pradeepa -Pradeepa On Fri, Aug 15, 2014 at 11:08 PM, Shachar Shemesh <sh...@sh...> wrote: > On 14/08/14 08:51, Pradeepa Senanayake wrote: > > Hello, > > I'm building a Kernel in the fakeroot-ng environment. > > I'm using ubuntu-14.04 x64 version as my OS. > > During the kernel build, there are some mknode calls. But they fail with > "Operation not Permitted" as error messages. > > Is this a known issue? Is there any workaround? > > Hello Pradeepa, > > I suspect there is something missing from your description of the problem. > The kernel does not, normally, require root permissions during build. It > follows, then, that it does not call mknod. I suspect what you're actually > trying to do is to *install* a kernel. > > Fakeroot-ng is an unprivileged program. When you "mknod" inside the > fakeroot-ng environment, it does not really create a device file. Instead, > it creates a regular file, and marks for itself to lie to you about what > that file actually is later on. This works great if you are trying to > create installation images using an archive tool. It does not work if you > are trying to actually install something on your live system. For that, you > will need actual root. > > I suspect that the EPERM error you're seeing is because your user does not > have permission to create regular files under /dev. If that's the case, > then that is not a bug in fakeroot-ng. It is working as intended. > > The workaround depends on what you're actually trying to achieve. If you > elaborate, we can figure out what is the best way to do it. > > Shachar > |
