On Thu, 25 Jan 2024 13:32:00 +0100 Johannes Schauer Marin Rodrigues wrote:
> Hi Francesco,
Hello Johannes!
>
> Quoting Johannes Schauer Marin Rodrigues (2024-01-23 08:56:24)
[...]
> > Amongst other improvements, if "$IMAGE" cannot be accessed by the unshared
> > user, it will error out early
Hi Francesco,
Quoting Johannes Schauer Marin Rodrigues (2024-01-23 08:56:24)
> I'm planning to close this bug with this patch:
>
> https://paste.debian.net/hidden/844859ff/
>
> Amongst other improvements, if "$IMAGE" cannot be accessed by the unshared
> user, it will error out early with a
Control: tag -1 + pending
Hi,
I'm planning to close this bug with this patch:
https://paste.debian.net/hidden/844859ff/
Amongst other improvements, if "$IMAGE" cannot be accessed by the unshared
user, it will error out early with a (hopefully) helpful error message.
Thanks!
cheers, josch
Hi,
thank you Helmut for your (again) very thorough reply. Just as with your
last large mail to this bug, I can only second the things you said and
have very little to add.
On 2024-01-16 07:29, Helmut Grohne wrote:
On Tue, Jan 16, 2024 at 12:21:46AM +0100, Francesco Poli wrote:
Well,
On Tue, Jan 16, 2024 at 12:21:46AM +0100, Francesco Poli wrote:
> Why is my first subuid not my user, but a different user?
> Is it by design?
Yes, this is by design. The use of subuids provides isolation. It's not
that you have just one, but you have a whole range of uids - the first
of which
On Sun, 14 Jan 2024 20:27:58 +0100 Helmut Grohne wrote:
> On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote:
> > Of course, I have! ;-)
> >
> > For privacy reasons: I don't want other users to be able to enter my
> > home directory and to read any file within it that I might have
Hi,
Quoting Francesco Poli (2024-01-14 18:33:14)
> The partition table has been altered.
> Syncing disks.
> $ echo $?
> 0
> $ ls -lF --si sid_amd64.img
> -rw-r-xrwx 1 $USER $USER 670M Jan 14 17:21 sid_amd64.img*
>
> However, if I attempt to use the resulting image, autopkgtest
>
On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote:
> Of course, I have! ;-)
>
> For privacy reasons: I don't want other users to be able to enter my
> home directory and to read any file within it that I might have
> forgotten with world-readable permissions!
I agree that this is
On Sat, 13 Jan 2024 22:09:22 +0100 Johannes Schauer Marin Rodrigues wrote:
[...]
> Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34)
[...]
> > The problem occurs for Francesco when
> > using either /tmp or /dev/shm as a temporary directly. By default, those two
> > locations should
On Fri, 12 Jan 2024 23:39:34 +0100 Johannes Schauer Marin Rodrigues wrote:
[...]
> could you try applying this patch and then try again:
>
> --%<-
> --- a/mmdebstrap-autopkgtest-build-qemu
> +++
Hi,
Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34)
> Quoting Helmut Grohne (2024-01-12 21:58:00)
> > > What can cause mkfs.ext4 to fail with a "Permission denied" error?
> > I think this is our typical problem when dealing with user namespaces. I
> > guess that the thing that
Hi,
Quoting Helmut Grohne (2024-01-12 21:58:00)
> > What can cause mkfs.ext4 to fail with a "Permission denied" error?
> I think this is our typical problem when dealing with user namespaces. I
> guess that the thing that fails here is mkfs.ext4 opening the target image
> file (to be formatted).
Hi Francesco,
On Fri, Jan 12, 2024 at 08:05:02PM +0100, Francesco Poli wrote:
> Indeed, the error does not seem to have anything to do with a "No space
> left on device" failure:
>
> [...]
> mke2fs 1.47.0 (5-Feb-2023)
> mkfs.ext4: Permission denied while trying to determine filesystem size
>
Hi,
Quoting Francesco Poli (2024-01-12 20:05:02)
> On Thu, 11 Jan 2024 21:04:16 +0100 Johannes Schauer Marin Rodrigues wrote:
> > Do you see yourself debugging this further by yourself? You probably
> > understand that it's hard for me to investigate something that I cannot
> > test myself.
>
>
On Thu, 11 Jan 2024 21:04:16 +0100 Johannes Schauer Marin Rodrigues wrote:
[...]
> Do you see yourself debugging this further by yourself? You probably
> understand
> that it's hard for me to investigate something that I cannot test myself.
Well, you wrote the script, together with Helmut
Hi,
Quoting Francesco Poli (2024-01-11 08:58:49)
> On Thu, 11 Jan 2024 00:45:50 +0100 Johannes Schauer Marin Rodrigues wrote:
> > Interesting! I'm unable to reproduce either of these issues and I'm also
> > puzzled why you get this "permission denied" error. On my system, I'm able
> > run
> >
On Thu, 11 Jan 2024 00:45:50 +0100 Johannes Schauer Marin Rodrigues wrote:
[...]
> Interesting! I'm unable to reproduce either of these issues and I'm also
> puzzled why you get this "permission denied" error. On my system, I'm able run
> your command with the default (in /tmp) as well as in
Hi,
Quoting Francesco Poli (wintermute) (2024-01-10 23:54:30)
> I am giving mmdebstrap-autopkgtest-build-qemu a try.
thank you!
> The following command fails:
>
> $ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img
>
> during some package installation with "no space left on
Package: mmdebstrap
Version: 1.4.0-1
Severity: normal
Hello,
I am giving mmdebstrap-autopkgtest-build-qemu a try.
The following command fails:
$ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img
during some package installation with "no space left on device" error,
since I have
19 matches
Mail list logo
