I am trying to get this working...
I have created my chroot image as an i386 image
dpkg-architecture returns
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i486-linux-gnu
So that looks ok.
If I call pbuilder with linux32, the uname -m returns i686
Yet when building my packages, pbuilder dies with
dh_installdirs: dpkg-architecture failed
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-17-2008, 09:06 AM
"Fathi Boudra"
hot to build i386 on amd64 using pbuilder?
see attached helper scripts base on scripts provided with pbuilder.
cheers,
Fathi
01-17-2008, 12:28 PM
"Anton Piatek"
hot to build i386 on amd64 using pbuilder?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks,
Works on one machine, but not on another
I have noticed another error in the logs, there are permission errors
on /dev/null
Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
How can I fix the permissions of /dev/null under the chroot?
Are my problems likely to be cause by the fact that my machine is
running as a vserver?
Anton
On 17/01/2008, Fathi Boudra wrote:
> see attached helper scripts base on scripts provided with pbuilder.
>
> cheers,
>
> Fathi
>
>
>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-17-2008, 01:04 PM
"Anton Piatek"
hot to build i386 on amd64 using pbuilder?
On 17/01/2008, Anton Piatek <anton@piatek.co.uk> wrote:
> I have noticed another error in the logs, there are permission errors
> on /dev/null
> Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
>
> How can I fix the permissions of /dev/null under the chroot?
>
> Are my problems likely to be cause by the fact that my machine is
> running as a vserver?
Actually /dev/null is not even a character device inside the chroot:
# ls -l /dev/null
-rw-r--r-- 1 root root 0 Jan 17 14:00 /dev/null
Outside the chroot it is fine - I sounds like I have a problem with a
chroot/pbuilder image inside a vserver image (it works fine outside
the vserver image)
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-17-2008, 02:01 PM
Adam Borowski
hot to build i386 on amd64 using pbuilder?
On Thu, Jan 17, 2008 at 01:28:03PM +0000, Anton Piatek wrote:
> I have noticed another error in the logs, there are permission errors
> on /dev/null
> Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
>
> How can I fix the permissions of /dev/null under the chroot?
>
> Are my problems likely to be cause by the fact that my machine is
> running as a vserver?
Yes, on vserver root is not really root. You can't mknod, mess with device
files, mount filesystems, mess with network, etc. Even some of the
restrictions which have already been fixed on newer versions are by default
(proper paranoia) masked away with machine capabilities.
Both pbuilder and piuparts fail extremely badly, even though one would
expect them to have support for virtualization. But unless one of us
bothers enough to fix it, the support won't be there.
Even reading up on the intricaties of machine caps can be more work than I
care -- if you have a non-vserver machine nearby, I guess you won't care
that much too.
In theory, you can run pbuilder in vserver host, but if you follow proper
security practices and have the host tightly locked down with the minimum
access needed (server-like setup), it's a bad idea. If it's just a normal
machine with vserver-enabled kernel (desktop with VMs) just do it the old
way outside vserver... Or be a hero and fix it for the rest of us ;-)
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-17-2008, 05:29 PM
"Anton Piatek"
hot to build i386 on amd64 using pbuilder?
Where is that set? inside the tgz? Theres no fstab inside, and I cant
see any options in the pbuilder config.
Anton
On 17/01/2008, Luk Claes <luk@zomers.be> wrote:
> Anton Piatek wrote:
> > Thanks,
> > Works on one machine, but not on another
> >
> > I have noticed another error in the logs, there are permission errors
> > on /dev/null
> > Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
>
> You might want to mount devpts in the chroot.
>
> Cheers
>
> Luk
>
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-18-2008, 01:35 AM
Micah Anderson
hot to build i386 on amd64 using pbuilder?
On Thu, 17 Jan 2008 16:01:42 +0100, Adam Borowski wrote:
> On Thu, Jan 17, 2008 at 01:28:03PM +0000, Anton Piatek wrote:
>> I have noticed another error in the logs, there are permission errors
>> on /dev/null
>> Logging into the chroot reveals /dev/null is 644, not 666 as I would
>> expect.
>>
>> How can I fix the permissions of /dev/null under the chroot?
>>
>> Are my problems likely to be cause by the fact that my machine is
>> running as a vserver?
>
> Yes, on vserver root is not really root. You can't mknod, mess with
> device files, mount filesystems, mess with network, etc. Even some of
> the restrictions which have already been fixed on newer versions are by
> default (proper paranoia) masked away with machine capabilities.
>
> Both pbuilder and piuparts fail extremely badly, even though one would
> expect them to have support for virtualization. But unless one of us
> bothers enough to fix it, the support won't be there.
>
Because I am a "raving vserver zealot" I will point out that if you don't
mind compromising the host's security inside the vserver, you can add the
CAP_MKNOD capability to this vserver, which will enable the ability to
make device nodes via mknod and likely will cause pbuilder and piuparts
work as advertised.
If you add this capability the vserver, you are giving the root access to
make random devices inside the vserver, which effectively compromises the
entire security isolation point of the vserver model. If you can create
the /dev/hda device node and start poking around outside of the security
context, then you are asking for trouble.
But if its your own box, and you are fine with that, then all you need to
do is:
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-20-2008, 12:29 PM
"Alexandre Rossi"
hot to build i386 on amd64 using pbuilder?
Hi,
> > Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
> >
> > How can I fix the permissions of /dev/null under the chroot?
> >
> > Are my problems likely to be cause by the fact that my machine is
> > running as a vserver?
>
> Actually /dev/null is not even a character device inside the chroot:
> # ls -l /dev/null
> -rw-r--r-- 1 root root 0 Jan 17 14:00 /dev/null
As I use cowbuilder, my quick fix for this (and which works perfectly) was :
$ chmod 666 /var/cache/pbuilder/etch-amd64.cow/dev/null
I assume that modifying the base tgz for pbuilder would not achieve
the same thing, as mknod would be run after extraction, would it?
Anyway this was a better compromise for me than giving MKNOD
capabilities inside the vserver guest.
Alex
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org