ebuild: baselayout-1.8.4.1(latest) gcc: 2.95-r7 arch: ~x86 portage: 2.0.43 When i attempted to update my system, the ebuild failed due to the fact that i had mounted /mnt/cdrom for my cdrom. This problem can probably be avoided by a mount-check script, for mounted devices in /mnt.
Same problem here because /home is an NFS mount: [...] >>> /var/lib/misc/.keep !!! Cannot write to '//home'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.8.4.1.ebuild merge !!! And finish by running this: env-update cube root # mount|grep /home sphere:/home on /home type nfs (rw,noatime,addr=192.168.1.3) cube root #
Nick .. not sure with this one, as it is baselayout's fault that it creates these dirs, but then portage that actually fails when merging to /.
Ok. I'll take this one for a future release... It's a portage thing. I guess I can try to move the access check after a conditional... Do you have root squashing in effect for the NFS issue? (root_squash is default) That'd kill the NFS issue. Other than that... there really isn't a reason to have anything mounted except maybe a distfiles CD.
I am getting the same error as Sascha, and yes, it would be because my NFS server squashes root. The only way I see around this (apart from changing the NFS server settings, which not everyone can do) is to unmount /home, install the baselayout, and then mount /home from NFS again. I'll give that a shot sometime, but it would be better if it weren't necessary.
Yes, I do have root_squash enabled (you cannot convince me to change that, that would be a security hazard) and that's causing it to fail. I really don't like having to put the machine into single-user just to update sys-apps/baselayout, especially not if it gets changed regularly (as it is currently). How about checking (and possibly creating) /home in postinstall for a temporary solution? Especially /home is a network mount on many systems.
*** Bug 11192 has been marked as a duplicate of this bug. ***
Just to add an additional 2 cents worth - the problem also crops up if you have a cd mounted (baselayout wants to write a .keep file to /mnt/cdrom, which happens to be ro at the time).
I'm an idiot - thanks to SpanKy for pointing out the opening bug comment.
It got even worse: After an unsuccessful update attempt (i.e. after an emerge -u system), my system could not boot properly anymore (thus it failed to get up after a power outage). I had to boot it in single user mode (which requires physical access, so it cannot be done remotely) and remerge baselayout. As you see, it breaks running systems, so please raise the severity to critical and the priority to P1. And accepting the bug (instead of leaving it as new) would be fine, too. Unfortunately, I don't have a copy of the error messages (too much to write down, no working system to cut&paste them). The most important problem was that /mnt/.init.d did not get mounted, so the whole rc-scripts system failed utterly.
*** Bug 11939 has been marked as a duplicate of this bug. ***
Decided to raised severity & priority to critical, since it seems to fail for a number of NFS users. Personally i didn't experience this bug anymore with my current setup. Do note though, that i don't use NFS, thus i cannot verify if the bug is fixed for NFS users. my setup: gcc: 2.95-r7 arch: ~x86 portage: 2.0.45-r3 baselayout: 1.8.5.5
I am experiencing the same problem with /mnt/floppy and /mnt/cdrom. This problem popped up after I added automout capabilities to my kernel. If I got all of this correctly, the baselayour script writes a .keep in all of these /mnt directories, hence triggering the automount mechanism. You can bypass the /mnt/floppy write error by inserting one in the drive... but have fun writing to the cdrom though!
*** Bug 12825 has been marked as a duplicate of this bug. ***
*** Bug 13331 has been marked as a duplicate of this bug. ***
Nick, status on this ?
Nothing I can really do about it... It'd be one heck of a performance hit to check every filename and guess if it can be merged or not... It'd be best if baselayout would be kind and check for ro mounts and just avoid dropping the .keep files in those dirs.
Ok, Ill try to get some sort of fix into the baselayout ebuild then.
*** Bug 13720 has been marked as a duplicate of this bug. ***
*** Bug 15264 has been marked as a duplicate of this bug. ***
Just to add to this bug report I get: !!! Cannot write to '/usr/portage'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.8.6.4.ebuild merge !!! And finish by running this: env-update /usr/portage is NFS and read-only. The ebuild wants to write a .keep file in there and fails. Thanks for reading, Norberto
*** Bug 18561 has been marked as a duplicate of this bug. ***
*** Bug 20334 has been marked as a duplicate of this bug. ***
*** Bug 23750 has been marked as a duplicate of this bug. ***
*** Bug 24806 has been marked as a duplicate of this bug. ***
*** Bug 25542 has been marked as a duplicate of this bug. ***
*** Bug 27721 has been marked as a duplicate of this bug. ***
*** Bug 27865 has been marked as a duplicate of this bug. ***
*** Bug 28231 has been marked as a duplicate of this bug. ***
*** Bug 29043 has been marked as a duplicate of this bug. ***
Created attachment 18106 [details, diff] changed some keepdir's to keepdir_mount With this patch, I can update baselayout cleanly on my system. Is there any reason not to replace keepdir with keepdir_mount completely?
*** Bug 29629 has been marked as a duplicate of this bug. ***
*** Bug 29670 has been marked as a duplicate of this bug. ***
*** Bug 29867 has been marked as a duplicate of this bug. ***
Created attachment 18614 [details, diff] fix for devfs-using installers This patch fixes problems with baselayout during install if /dev is a mounted devfs file system (which is needed for ATA RAID systems). Should fix Bug #29867 ("bootstrap fails with ErrorCode 13 Access Denied when following ataraid directions").
*** Bug 29991 has been marked as a duplicate of this bug. ***
Comment #34: > This patch fixes problems with baselayout during install if /dev is a mounted > devfs file system (which is needed for ATA RAID systems). > Should fix Bug #29867 ("bootstrap fails with ErrorCode 13 Access Denied when > following ataraid directions"). Good catch - I'll add it soonish ...
*** Bug 30939 has been marked as a duplicate of this bug. ***
Could someone please upgrade 'soonish' to urgently? I can't get passed bootstrap becuase it wants to move .keep to /dev/.keep (or similar, the full ouput has been moved to one of the duplicates above. It is quite simply preventing Gentoo from installing, which I imagine is a pretty serious bug. Q
!!! copy /var/tmp/portage/baselayout-1.8.6.10-r1/image/home/.keep -> /home/.keep failed. !!! [Errno 2] No such file or directory: '/home/.keep#new' automount(pid12932) on /home type autofs (rw,fd=5,pgrp=12932,minproto=2,maxproto=3) turn off automount and it merges fine.
How do I do that please? If this is the answer then thank you very much. I hope the devs take this into account in the currently avaiable tarballs... Q
Has any progress been made on this? I'm getting the same error but the file is /dev/.keep Can't move past this error. Plese help. I'm doing a stage 1 install on a laptop.
Have you tried Sascha Silbe's fix (available as fix_for_devfs-using_installers) ?
Yes, I've applied it and am now testing it. When will this patch be rolled into baselayout though? (assuming it works, and from looking at it, it should.) Can anyone explain why mkdir /dev/.keep works but touch /dev/.keep does not? (I'm jsut curious here) =C=
As I have said, it would be cool if someone would acutally say 'how' to turn automount off, if this is indeed the cause of this bug. I have no clue how to do this - and I fear anyone searching through gentoo bugs may also bw equally bemused. It is very kind of the above individual to point out this is what is required, but it cannot trully be considered a resolution until someone actually states how this should be done. Please can someone supply this answer? I can only asume that it will serve at least to make the bugs database a fraction more coherant than is currently the case. Any input in this regard is welcome. Q
In my system, I have a autofs script in /etc/init.d/ which has been installed by package net-fs/autofs. I just have to issue a /etc/init.d/autofs stop To stop it. Don't know if it the case for you. But anyway, you can be a naughty boy and kill the automount process killall -9 automount I think that it will work for you... But I haven't tested (only the first method) and thus I cannot say if it will bork your system or not. Should not IMO
Quote:>In my system, I have a autofs script in /etc/init.d/ which has been >installed by package net-fs/autofs. I just have to issue a >/etc/init.d/autofs stop >To stop it. Don't know if it the case for you. But anyway, you can be a >naughty boy and kill the automount process >killall -9 automount No thanks for that but it didn't work. I did /etc/init.d/autofs stop and all that happend was I got an error message saying "No such file file or directory". When I tried to do killall -9 automount I got an message saying automount: no processes killed. What does all this mean and how can I stop this setvice? Is it even started? If so, how can I tell?
Please everyone note that this isn't a /dev issue, or a /mnt issue, or a /home issue, or an automount issue, so there is no real point in trying to fix those with chewing gum and a piece of string. This is about baselayout writing to directories it is not allowed to write to, for one reason or another. As most people in a semi-large scale environment, I mount /home from a fileserver and certainly not as root. So it fails for me unless I unmount /home and try again. Pain in the neck. A more generic way of avoiding the problem should be thought of, even if it just means having a make.conf option with a shortlist of directories to avoid (both when writing to, when trying to remove empty dirs and any other access). Having emerge prune according to this list and give an appropriate warning shouldn't be both easy to implement and fast. The option could be empty by default, thus all dirs will be created upon installation of the machine in question. However, the user is subsequently allowed to add say /home, /whatnot there if needed. Appropriate warnings against putting / in the list is probably a good idea. :-)
@Cal: Did my patch work for you?
Yes, it did. When can we expect it to be incorporated into the main codebase? =C=
Its in .11.
*** Bug 34970 has been marked as a duplicate of this bug. ***
per bug 34970 its still a problem in .12
*** Bug 38259 has been marked as a duplicate of this bug. ***
*** Bug 40044 has been marked as a duplicate of this bug. ***
*** Bug 40463 has been marked as a duplicate of this bug. ***
The problem is still in 1.8.6.13... >>> /mnt/.keep >>> /mnt/cdrom/ >>> /mnt/cdrom/.keep --- /mnt/floppy/ !!! copy /usr/tmp/portage/baselayout-1.8.6.13/image/mnt/floppy/.keep -> /mnt/floppy/.keep failed. !!! [Errno 123] No medium found: '/mnt/floppy/.keep#new'
Baselayout still fails to merge for me in 1.8.6.13 because I have /home mounted over nfs with root_squash enabled. Changing keepdir /home to keepdir_mount /home resolves this.
I wonder why "keepdir" is still in use at all... If portage is unable to add a ".keep" file to that directory now, it will be unable to delete that directory later anyways, so there is no danger of "accidently" deleting that directory during an unmerge... Why not rename "keepdir_mount" to "keepdir" and drop the old keepdir completely?
Another "brute force" fix could be the following: mount --bind / /somewhere/root mount --bind /usr /somewhere/root/usr etc. (for each locally rw mounted fs in fstab) now you have a complete "shadow" tree of your system in /somewhere/root, without all those nfs/autofs/whatever mounts that could cause trouble. now merge into /somewhere/root, instead of /, and everything should work fine... As a side effect, with this method you're even able to access those parts of the root filesystem that otherwise would be hidden by mounts, e.g. writing /somewhere/root/mnt/floppy/.keep would actually add the keep file to the floppy mountpoint, not on the floppy itself if one is mounted.
When upgrading to 1.8.6.13 this morning I got this: --- /home/ !!! copy /var/tmp/portage/baselayout-1.8.6.13/image/home/.keep -> /home/.keep failed. !!! [Errno 13] Permission denied: '/home/.keep#new' /home/ is under the control of autofs on my system as the workstation is bound into a NIS domain. Stopping autofs to do the install sorted it, but that isn't exactly a good solution for a server that has active mounts.
Another baselayout update, another failure: !!! Cannot write to '/home'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.8.6.13.ebuild merge !!! And finish by running this: env-update What is holding back my bugfix? I really hate having to apply local patches to base system packages for a regular system.
*** Bug 41957 has been marked as a duplicate of this bug. ***
*** Bug 42166 has been marked as a duplicate of this bug. ***
*** Bug 43037 has been marked as a duplicate of this bug. ***
*** Bug 43058 has been marked as a duplicate of this bug. ***
When i emerge baselayout-1.8.6.13-r1 i get this in the merge phase: --- /dev/ --- /dev/pts/ !!! copy /var/tmp/portage/baselayout-1.8.6.13-r1/image/dev/pts/.keep -> /dev/pts/.keep failed. !!! [Errno 13] Permission denied: '/dev/pts/.keep#new' The machine uses devfs (and devfsd running) on kernel 2.4.24.
sys-apps/baselayout-1.8.6.13 works, sys-apps/baselayout-1.8.6.13-r1 fails (/dev/pts as per comment #66)
*** Bug 43067 has been marked as a duplicate of this bug. ***
*** Bug 43068 has been marked as a duplicate of this bug. ***
*** Bug 43090 has been marked as a duplicate of this bug. ***
Having problem emerging baselayout-1.8.6.13-r1 here as well. (Running a pac-sources kernel with devfs.) Looking at baselayout-1.8.6.13-r1.ebuild I noticed the following: <code> if [ "${altmerge}" -eq "1" ] then # rootfs and devfs #dosym ../../sbin/MAKEDEV /lib/dev-state/MAKEDEV # This is not needed anymore... #keepdir /lib/dev-state/pts /lib/dev-state/shm keepdir_mount /dev /dev/pts /dev/shm else # Normal keepdir_mount /dev /dev/pts /dev/shm #dosym ../sbin/MAKEDEV /dev/MAKEDEV fi </code> It seems like both the branches does the same thing (the commented rows indicates that they have been doing different things). Is that expected? If so, why have the 'if' statement at all? Then I noticed the 'keepdir_mount ... /dev/pts ...' call. On a devfs based 2.4 kernel system I suppose that /dev/pts is part of the devfs based dev filesystem. At least I can't find /dev/pts in the output of "gawk '{ print $2 }' /proc/mounts" on my system, and that's why we do 'keepdir /dev/pts' which fails over here. I don't know how this is supposed to work, but that's something I think you know very well... ;-)
Thanks for the research, should be fixed in CVS now. Can we really start to do something about this right about now? This is a portage issue, _NOT_ a baselayout issue. And one of the biggest reasons why baselayout has been such an bitch to get to work as a .tbz2. I really do not want to go to more extremes to get it to work fine on different systems (not to talk when it can handle .tbz2, and is used as such).
*** Bug 43093 has been marked as a duplicate of this bug. ***
What a bummer, it's still not fixed! So here is a quick fix for everyone who is affected (and i guess thats a lot of people): Please edit /usr/portage/sys-apps/baselayout/baselayout-1.8.6.13-r1.ebuild and remove lines 299 to 310 and reemerge baselayout. HTH, Jan
Andreas, still not fixed your side as well?
Don't know yet! Will try it tomorrow when at work...
Martin, it installed alright here!
A lof of bugs are listed as a duplicate as this one. It is sort of misleading that the bug that's selected as the master of the duplicates (this one), involves NFS although that does not seem to be the problem. By the way. Commenting out the mentioned lines solves the problem. Thanks. oktay
--- /dev/ --- /dev/shm/ !!! copy /var/tmp/portage/baselayout-1.8.6.13-r1/image/dev/shm/.keep -> /dev/shm/.keep failed. !!! [Errno 13] Permission denied: '/dev/shm/.keep#new' I also get the error on PPC (2.4.22-ben2), worked fine until this release.
Any progress on this? It blocks alsa-driver from installing, so the list of non-usable updates on my system now contains 4 entries: baselayout, alsa-driver, alsa-tools and - apart from this - gramps.
Btw, I recieved a suggestion from one of the Gentoo folks that this bug can be fixed by changing the line: keepdir /home to: keepdir_mount /home However, this simply will not fix the problem in my environment. The keepdir_mount subroutine checks /proc/mounts to see if "/home" is mounted. In my environment, it is not mounted, but a link to another directory which is mounted. Therefore, the real solution is to also change keepdir_mount() so that it uses readlink. Here's my version which fixed the problem in our environment. This probably needs some cleaning for general use: keepdir_mount() { local x= local y= local doit=0 [ -z "$1" ] && return 1 [ ! -e /proc/mounts ] && return 1 for y in $* do doit=0 if [ $(readlink ${y}) ] then link=`readlink -f ${y}` else link=${y} fi for x in $(gawk '{print $2}' /proc/mounts) do [ "${x}" = "${link}" ] && doit=1 done if [ "${doit}" -ne 1 ] then keepdir "${y}" fi done return 0 }
*** Bug 46689 has been marked as a duplicate of this bug. ***
I guess I'm now on the baselayout team with Martin. Reading through this bug, I'm under the impression that keepdir is broken for mounted read-only (or root_squash) filesystems because portage is unable to add the .keep file to the directory. keepdir_mount was attempted, but is broken because it assumes that src_install() is running on the same system as pkg_postinst(), and it also doesn't cope with symlinks to mounted filesystems. Additionally the directories don't show up in the package CONTENTS so they will never be removed automatically. Since this problem can't really be solved in the ebuild, it's only really solvable in portage. Here are a couple options: 1. Portage could ignore when directory creation and/or .keep creation fails on a mounted directory. Anything else should cause merge failure. 2. Should this be tunable via a make.conf variable? I.e. similar to CONFIG_PROTECT, maybe there should be a variable IGNORE_FAIL which could default to some of the more common directories (/mnt /home /dev etc)
How about dropping this .keep stuff and instead only creating the directories during postinstall if they do not already exist?
Regarding comment #84, no, then directories will never be removed by portage because they are not owned by the package according to CONTENTS
> then directories will never be removed by portage I would regard that as a feature, not a bug. :) On a real system, I would not want Portage to remove any of these directories. It's all right if it creates them (if they don't already exist), but it must not remove them. Even the permissions must remain unchanged.
I myself can live with both solutions mentioned in comment #83. On a normal system you would probably not have more than 1 or 2 directories mounted on a read-only fs. So it won't be a problem to put them in make.conf. I don't think it's an option to not remove the directories when unemerging. This would lead to lots and lots of empty directories in for instance /usr/share/doc.
> I don't think it's an option to not remove the directories when unemerging. This would lead to lots and lots of empty directories in for instance /usr/share/doc Since there is no "keepdir" directive for /usr/share/doc/baselayout-<whatever> etc., that's no problem. We're just talking about initially empty directories that are to be generated during installation. Once they exist, there's no need to change them. Most of them also cannot be removed without damaging the system.
Regarding comment #88, I appreciate the sentiment, but I'm trying to solve this for the general case as well as baselayout. All you're suggesting is a hack for this specific ebuild, which is probably needed in the interim. But the portage change is necessary for ebuilds other than baselayout that suffer from the same problems.
In reply to comment #88: There are a lot of keepdir directives in the portage tree. In a worst case scenario you would have all those directories on your system with just a .keep file in it. Some of these directories even depend on the version of the package. This means they will accumulate over time and there is no easy way to remove them. It is true that baselayout creates most of them, but still there are many packages a user might want to uninstall that create directories with 'keepdir', ie. superkaramba, cracklib, tomcat, apache and openoffice.
Created attachment 28872 [details, diff] Portage-2.0.50-r4 patch to ignore failed directory or .keep file creation This patch works by ignoring failures on directory creation or ".keep" files. Instead it only fails when a regular file copy fails. Here's sample output from baselayout with /mnt and /etc/skel mounted as read-only tmpfs: >>> /bin/rc-status --- /mnt/ !!! /mnt/cdrom/ !!! /mnt/cdrom/.keep !!! /mnt/floppy/ !!! /mnt/floppy/.keep !!! /mnt/.keep --- /etc/ --- /etc/skel/ !!! Cannot write to '/etc/skel/.bashrc'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.8.6.13-r1.ebuild merge !!! And finish by running this: env-update Negative side-effects are that /mnt/{cdrom,floppy} were not created and there was minimal notification (if /etc/skel is r/w it completes successfully). Whether this is acceptable is another matter.
removing azarah and aron from cc, as they are both in base-system
Created attachment 28874 [details, diff] patch to die AFTER package is merged This patch is similar to the previous one, except that it will die after the package is merged so that failures on packages such as *cron and postfix are easily recognised and addressable before using the package. Output is as follows: >>> Merging sys-apps/baselayout-1.8.7 to / <snip> --- /mnt/ !!! /mnt/cdrom/ !!! /mnt/cdrom/.keep !!! /mnt/floppy/ !!! /mnt/floppy/.keep !!! /mnt/.keep <snip> >>> Safely unmerging already-installed instance... <snip> >>> original instance of package unmerged safely. <snip> >>> sys-apps/baselayout-1.8.7 merged. !!! Creation of the following directories failed. !!! Please adjust permissions and re-emerge this !!! this package or create the directories manually. !!! /mnt/cdrom !!! /mnt/floppy
Same Proplem with /home mounted on nfs fileserver without root access. When will this bug fixed. IMHO changing keepdir's to keepdir_mount resolv the home mount problem. In our environment 10-20 users are logged in and there is no possibilty to stop the automounter.
After a second thought, I think the best solution will be to add a config variable to mark read-only directories. Failing after emerging is not very practical, because it will stop upgrades of multiple packages.
Re comment #89: For the general case you're right, of course. I was just talking about baselayout. What other packages do have the same problem (i.e. trying to re-create existing read-only directories)? What about modifiying keepdir in Portage so only the directory is created (no .keep file) and only if it does not already exist? That would probably require additional information in binary packages, but seems to be the cleanest solution.
I should have made it more clear, but my patch will not fail if all directories exist even if the .keep file could not be written. Specifically, the logic goes: When creating directories, ignore failures. When copying .keep files, check if directory exists upon failure. When copying other files, fail straight away if a file cannot be copied. If any .keep files couldn't be copied and the containing directories don't exist, fail after the emerge has been completed. This can be seen by both example outputs. The second one shows that /mnt/.keep could not be created but is not in the list of missing directories. I think this logic would stop baselayout from failing for every single report in this bug. In the extreme case where a directory does not exist and cannot be created, the user/administrator really needs to know about it.
Just to de-confuse the meaning of keepdir on comment #85: without the .keep files portage will remove empty dirs on autoclean, this would result in empty dirs being removed on baselayout upgrades for example (it's called KEEPdir for a reason). As for a good solution, I'd second a IGNORE_FAIL variable (but with no default) in combination with Jason's patch. Not sure if it's necessary to error out or if printing an ewarn and continuing would be better.
Created attachment 28926 [details, diff] Same but supports new ebuild var NONCRITICAL_KEEPDIRS Output is the same as the previous two patches except that the merge will continue with the next package if the parent of one of the specified dirs is listed in a new ebuild var NONCRITICAL_KEEPDIRS. For example, baselayout could specify: NONCRITICAL_KEEPDIRS="/mnt/floppy /mnt/cdrom" for those specific directories, NONCRITICAL_KEEPDIRS="/mnt/" for anything UNDER /mnt, or NONCRITICAL_KEEPDIRS="/mnt" for /mnt and anything under it.
scratch my explanation of my last patch. it wont work if the var is in the ebuild. s/NONCRITICAL_KEEPDIRS/IGNORE_FAIL/ and it's what Marius described.
*** Bug 47342 has been marked as a duplicate of this bug. ***
Problems with the patch: * It doesn't remove -MERGING-baselayout-1.8.6.13-r1 * It doesn't unmerge the previous instance Dealing with this and still exiting is possible, but would be a bit ugly code-wise. Are there any objections to a noisy warning and continuing with the emerge?
Created attachment 29121 [details, diff] Simpler patch that keeps current behaviour except dying when .keep cannot be written
To reply to comment 102, by jason > Problems with the patch: > * It doesn't remove -MERGING-baselayout-1.8.6.13-r1 that's a file portage leaves hanging around that you need to remove by hand since portage can't seem to deal with finsihing the merge due to the inablity to create .keep the files live somewhere down in /var/cache or /var/db (I don't recall exactly) and are labeled: -MERGING-<package> That's how portage knows it hasn't finished merging a package, so if you don't care.. just rm the files.
Btw, to take the pressure off of Jason a bit, baselayout-1.8.9 has a hack that should completely workaround this problem, but for that package only. Other packages can equally be affected by this problem, so portage isn't completely off the hook ;-)
Now that baselayout has a (working) workaround, reassigning this to the portage team so they can get a real fix in there!
baselayout still bails out: [...] --- /usr/X11R6/ --- /usr/X11R6/share/ >>> /usr/X11R6/share/info -> ../../share/info >>> /usr/tmp -> ../var/tmp >>> /usr/man -> share/man >>> /usr/doc -> share/doc >>> /usr/info -> share/info !!! Cannot write to '/boot'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.8.10.ebuild merge !!! And finish by running this: env-update
I examined the ebuild and found out that /boot is special because baselayout tries to create a SymLink on it: # Symlink /boot/boot to . so that /boot can be a separate # filesystem and config files still work dosym . /boot/boot /boot is read-only on my system: /dev/discs/disc0/part2 /boot ext2 ro,noatime 1 1
Thansk Sascha, I'll figure out a workaround for that
Sascha, I realized there is no further workaround I can (or am willing, at least) to kludge in the baselayout ebuild. As it stands it fixes problems at least for directory and .keep file creation. If I attempt to extend that kludge to symbolic links then the entire ebuild is going to fall apart in my hands. The only way I think your particular case will be fixed is with IGNORE_FAIL in portage, when that becomes available (hopefully soon!) Otherwise I'd suggest that rather than mount /boot read-only, you simply refrain from mounting it (similar level of protection, but less choice in the matter than you'd probably like...) Thanks for your patience.
What about just creating that SymLink in postinstall (only) if it does not exist? I need (read-only) access to /boot, e.g. for System.map.
I doubt that any portage fix/feature will extend anywhere beyond the keepdir problem. The main question is the best way to implement that. With the /boot/boot/ symlink, the closest that might occur is that symlinks wont fail if they already exist and point to the right destination. The main problem is that handling these sorts of abnormalities leads to code that is messy, hard to read and most importantly hard to maintain.
Jason, in comment 87 you said the following: > When creating directories, ignore failures. > When copying .keep files, check if directory exists upon failure. > When copying other files, fail straight away if a file cannot be copied. > If any .keep files couldn't be copied and the containing directories don't exist, fail after the emerge has been completed. What if you change that slightly to: When creating directories, ignore failures. When copying .keep files, ignore if subpath of IGNORE_FAIL, otherwise forestall failure until after emerge is completed, then fail if parent dir doesn't exist. When copying files (including symlinks), fail immediately unless it's a subpath of one of the elements of IGNORE_FAIL Then Sascha could have IGNORE_FAIL=/boot and it would work because portage would ignore ALL failures for that directory.
IGNORE_FAIL would be fine for me.
The current solution breaks installation from stage3 (/proc is mounted during extraction): Unpacking /inst/dist/stage3-x86-20040503.tar.bz2... tar: ./proc/.keep: Cannot open: No such file or directory tar: Error exit delayed from previous errors :(
Sascha: Huh? That has nothing to do with this bug, the directory mentioned just happens to coincide with baselayout. That's just normal behavior for tar and read-only directories. Please don't muddy the water.
*** Bug 50369 has been marked as a duplicate of this bug. ***
*** Bug 44778 has been marked as a duplicate of this bug. ***
*** Bug 44321 has been marked as a duplicate of this bug. ***
Chris White brought it to my attention that this bug is still open. Since we work around the problem in the baselayout ebuild, there's nothing more for base-system to do. The ball is now in the portage court to fix the problem.
Is this even a valid bug anymore, since the 1.8.x baselayout isn't even in portage anymore? Or does this problem persist with the current versions of baselayout and portage?
None of my ~x86 packages currently own /home or /mnt. Portage will still produce a "Cannot write" error and exit if it cannot write to a directory, but that is reasonable, IMO.
Baselayout currently has a hack to work around this bug. I'd say best case, we can: 1) Get rid of the .keepdir files (which will happen with the CONTENTS rewrite) 2) Check appropriate access before beginning the move/copy. 3) If an error still happens during merge, try to revert the work already done.
Check appropriate access falls under collision protect code, or moreso, that feature can be 'tweaked' to make it so.
This is a combination of bug #23851 + bug #16162 as far as portage goes. *** This bug has been marked as a duplicate of 23851 ***
