Re: [gentoo-dev] ebuilds creating mountpoints
On 1/11/06, Aron Griffis <[EMAIL PROTECTED]> wrote:
> Bug 9849 has been marked a duplicate of 23851, but there is
> a distinction between the two: 23851 would be "solved" by pre-failing
> the merge phase if it is predicted to fail (permissions, diskspace).
> But 9849 is pretty specific to .keep files and directory creation, and
> needs to finish the merge even if some of those fail.
The only solution I can think of, is to merge to a "duplicate ROOTDIR"
like this (pseudo-code):
mount -o bind / /mnt/dup
ROOTDIR=/mnt/dup emerge {package}
Like this, mounts under / aren't mounted under /mnt/dup (e.g.
/mnt/dup/proc only contains .keep), so one can access the underlying
filesystem. Problem with this is: if you have /usr on a different
partition, you probably want to mount -o bind that as well, so you'll
have to make a distinction between mounts of instalation directories,
and mounts of run-time usage directories.
Stefaan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
Donnie Berkholz wrote: [Sat Jan 07 2006, 06:20:48PM EST] > That's actually not the case; I've never gotten around to filing a bug > for it, but I mount my /media read-only (so I don't accidentally delete > all my music) and pmount dies every time. AFAIK, the original bug pertaining to this issue is 9849, which specifically dealt with baselayout installation failures due to writing .keep files on r/o filesystems. Baselayout now has a workaround (kdir and unkdir) which avoids the issue, but breaks portage's tracking of .keep files. Bug 9849 has been marked a duplicate of 23851, but there is a distinction between the two: 23851 would be "solved" by pre-failing the merge phase if it is predicted to fail (permissions, diskspace). But 9849 is pretty specific to .keep files and directory creation, and needs to finish the merge even if some of those fail. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp4sHfyCDFgj.pgp Description: PGP signature
Re: [gentoo-dev] ebuilds creating mountpoints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefaan wrote: | I don't use pmount myself, but my guess is that /media is just a | directory that contains mountpoints, and which remains at all time | writeable for root. /afs is not writeable when mounted, just like | /dev/cdrom etc... That's actually not the case; I've never gotten around to filing a bug for it, but I mount my /media read-only (so I don't accidentally delete all my music) and pmount dies every time. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDwEzQXVaO67S1rtsRAuNjAKDo9elzOyfHgIn3Ifnz1Q24se2pzACg9h6f TuvFF6IyGs1vtq02p1x3sLc= =7jNI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
On 1/7/06, Petteri Räty <[EMAIL PROTECTED]> wrote: > Stefaan wrote: > > The obvious solution seems to do "keepdir", so portage would attempt > > to make the directory and put a .keep file in there. I say attempt, > > because the following problem will occur during an re-merge or > > upgrade, while the mountpoint is in use: > > Strange that I haven't seen any problems with pmount which does keepdir > for /media. I don't use pmount myself, but my guess is that /media is just a directory that contains mountpoints, and which remains at all time writeable for root. /afs is not writeable when mounted, just like /dev/cdrom etc... Stefaan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
Petteri Räty wrote: > Stefaan wrote: > >>Hi! >> >>I'm having an issue with the openafs-ebuild, and I don't see a >>solution for the moment. I wondered if someone on the list would: >> >>Prerequisite: >>The ebuild needs to create the /afs directory, and remove that same >>directory when it is uninstalled. >> >>The obvious solution seems to do "keepdir", so portage would attempt >>to make the directory and put a .keep file in there. I say attempt, >>because the following problem will occur during an re-merge or >>upgrade, while the mountpoint is in use: > > > Strange that I haven't seen any problems with pmount which does keepdir > for /media. > Plaah. Figured out my mistake. Would it be possible to adjust afs utilities to create that directory when needed and delete when done? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuilds creating mountpoints
Stefaan wrote: > Hi! > > I'm having an issue with the openafs-ebuild, and I don't see a > solution for the moment. I wondered if someone on the list would: > > Prerequisite: > The ebuild needs to create the /afs directory, and remove that same > directory when it is uninstalled. > > The obvious solution seems to do "keepdir", so portage would attempt > to make the directory and put a .keep file in there. I say attempt, > because the following problem will occur during an re-merge or > upgrade, while the mountpoint is in use: Strange that I haven't seen any problems with pmount which does keepdir for /media. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuilds creating mountpoints
Stefaan wrote: You suggest keeping the /afs dir, this would be an easy solution of course, but it does seem untidy, doesn't it? (Makes me think of the windows uninstallers saying "not all files could be removed, have a nice day") Ah, I of course didn't pay enough attention and didn't realize it was a mountpoint, not a storage place. Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
On 1/7/06, Brian Jackson <[EMAIL PROTECTED]> wrote: > You could handle it the way the baselayout ebuild does. But baselayout also just creates the directories in pkg_postinst (if my interpretation of the ebuild is correct). The list is not kept, so when uninstalling baselayout the directories are still around. I know, who on earth uninstalls baselayout. Removing openafs from your system is a bit more sensible though. I'm still hoping there is a clean solution. Else I will (as suggested) need to resort to just creating the directory manually and leaving it be afterwards, also after an unmerge. Stefaan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
On 1/7/06, Joshua Baergen <[EMAIL PROTECTED]> wrote:
> Why not just create the directory in ${D} or ${IMAGE} and let Portage
> handle the rest? Do you really want to be removing /afs unconditionally
> on unmerge?
Because this results in this: (directory /t existed and /dev/cdrom was
mounted to it while merging this)
>>> Merging sys-apps/test-0.2 to /
!!! Cannot write to '/t'.
!!! Please check permissions and directories for broken symlinks.
!!! You may start the merge process again by using ebuild:
!!! ebuild /usr/portage/sys-apps/test/test-0.2.ebuild merge
!!! And finish by running this: env-update
You suggest keeping the /afs dir, this would be an easy solution of
course, but it does seem untidy, doesn't it? (Makes me think of the
windows uninstallers saying "not all files could be removed, have a
nice day")
Stefaan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
You could handle it the way the baselayout ebuild does.
--Iggy
Stefaan wrote:
Hi!
I'm having an issue with the openafs-ebuild, and I don't see a
solution for the moment. I wondered if someone on the list would:
Prerequisite:
The ebuild needs to create the /afs directory, and remove that same
directory when it is uninstalled.
The obvious solution seems to do "keepdir", so portage would attempt
to make the directory and put a .keep file in there. I say attempt,
because the following problem will occur during an re-merge or
upgrade, while the mountpoint is in use:
!!! Cannot write to '/afs'.
!!! Please check permissions and directories for broken symlinks.
etc.
(This is related to bug #9849, if I'm not mistaken)
The currently implemented solution is to do
pkg_prerm()
{
rmdir /afs 2> /dev/null
}
pkg_postinst()
{
mkdir /afs 2> /dev/null
}
which works fine when remerging an already emerged ebuild. That's
because pkg_prerm is ran first, and pkg_postinst afterwards.
However, during an upgrade, pkg_prerm of the old version is ran
_after_ pkg_postinst of the new version. This results in the
directory disappearing, and therefore afs failing to start.
Any input is greatly appreciated,
Thanks,
Stefaan
--
Stuff for sale -- http://www.brianandsara.net/temp/forsale.html
Gentoo Linux -- http://www.gentoo.org
IVTV -- http://ivtv.writeme.ch
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
Stefaan wrote:
Prerequisite:
The ebuild needs to create the /afs directory, and remove that same
directory when it is uninstalled.
Why not just create the directory in ${D} or ${IMAGE} and let Portage
handle the rest? Do you really want to be removing /afs unconditionally
on unmerge?
Joshua Baergen
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] ebuilds creating mountpoints
Hi!
I'm having an issue with the openafs-ebuild, and I don't see a
solution for the moment. I wondered if someone on the list would:
Prerequisite:
The ebuild needs to create the /afs directory, and remove that same
directory when it is uninstalled.
The obvious solution seems to do "keepdir", so portage would attempt
to make the directory and put a .keep file in there. I say attempt,
because the following problem will occur during an re-merge or
upgrade, while the mountpoint is in use:
!!! Cannot write to '/afs'.
!!! Please check permissions and directories for broken symlinks.
etc.
(This is related to bug #9849, if I'm not mistaken)
The currently implemented solution is to do
pkg_prerm()
{
rmdir /afs 2> /dev/null
}
pkg_postinst()
{
mkdir /afs 2> /dev/null
}
which works fine when remerging an already emerged ebuild. That's
because pkg_prerm is ran first, and pkg_postinst afterwards.
However, during an upgrade, pkg_prerm of the old version is ran
_after_ pkg_postinst of the new version. This results in the
directory disappearing, and therefore afs failing to start.
Any input is greatly appreciated,
Thanks,
Stefaan
--
gentoo-dev@gentoo.org mailing list
