Opening a terminal, at the top is a shell-init error: shell-init: error retrieving current directory: getcwd: cannot access parent directories: Success Also, pwd doesn't gives a bad address (see below). cd'ing to / gets rid of the problem for that terminal. Not seen when sshing in, but it is seen when scp'ing from the box. Not seen on crownbay. sh-4.2# ls -al job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory drwxr-xr-x 1 root root 100 Apr 18 16:42 . drwxr-sr-x 1 root root 60 Apr 18 16:37 .. -rw------- 1 root root 8 Apr 18 16:42 .bash_history drwx------ 1 root root 80 Apr 18 16:37 .dbus drwx------ 1 root root 60 Apr 18 16:37 .gconf sh-4.2# pwd pwd: error retrieving current directory: getcwd: cannot access parent directories: Success pwd: error retrieving current directory: getcwd: cannot access parent directories: Bad address sh-4.2# cd .. chdir: error retrieving current directory: getcwd: cannot access parent directories: Success sh-4.2# pwd pwd: error retrieving current directory: getcwd: cannot access parent directories: Success sh-4.2# cd .. chdir: error retrieving current directory: getcwd: cannot access parent directories: Success sh-4.2# cd .. sh-4.2# ls bin boot dev etc home lib lost+found media mnt proc sbin sys tmp usr var sh-4.2# pwd ../.. sh-4.2# cd sh-4.2# ls sh-4.2# pwd /home/root sh-4.2#
This seems to be a problem introduced by unionfs. Turning off the unionfs feature in the kernel makes this problem go away.
Interesting. Without a union mount, it should be completely benign, and is this really just for the one BSP ? What sort of boot is this ? Live image ? For 1.2, we can disable this for the BSP. For 1.3, we can dig deeper into unionfs.
(In reply to comment #2) > Interesting. Without a union mount, it should be completely benign, and > is this really just for the one BSP ? What sort of boot is this ? Live image ? > > For 1.2, we can disable this for the BSP. For 1.3, we can dig deeper into > unionfs. Actually, I did just see this on emenlow as well. It's a live image. The code in init-live.sh does do a union mount if CONFIG_UNION_FS = y, so since all the BSPs have this setting, they'd all be affected I guess.
Aha. That's yang's change. It was made to allow X to start from the live images. We should be able to do it via the BSP fragments or just disable the union mount in the script for now (and re-open the bug for 1.3). It's tricky stuff.
(In reply to comment #4) > Aha. That's yang's change. It was made to allow X to start > from the live images. We should be able to do it via the BSP fragments > or just disable the union mount in the script for now (and re-open the > bug for 1.3). It's tricky stuff. Yeah, it might be better to turn if off for now, since there's also another problem relating to script and the config option that I just filed a bug for (2350).
(In reply to comment #5) > (In reply to comment #4) > > Aha. That's yang's change. It was made to allow X to start > > from the live images. We should be able to do it via the BSP fragments > > or just disable the union mount in the script for now (and re-open the > > bug for 1.3). It's tricky stuff. > > Yeah, it might be better to turn if off for now, since there's also another > problem relating to script and the config option that I just filed a bug for > (2350). Or we can do it in the BSPs as well, which might be easier for now. 2350 is easily worked around. Actually, I'm wondering about the actual cause of this, maybe there's an easy fix?
This occurs on fri2 and uranus as well, so definitely generic. Marking as product=kernel as there seems to be a tie to unionfs, but definitely not BSP specific.
To confirm: everyone is ok with this waiting until 1.3 ? We can always disable unionfs in the BSPs showing the issue, but we'd have to get that done soon if we want it in 1.2. But since this still boots, with the issue only being a warning, I tend to agree that we can let this wait until 1.3.
Hmm, it's more than just a warning message, basically it's an error message that happens at every command in the terminal, and pwd doesn't work at all, until you cd to /, etc, who knows what else. Unless I'm missing something, we can't fix the script at this point because nothing is going into 1.2 any more, even bugfixes, so we have no choice but to fix it in the BSPs, which we still have time to work on (3 weeks following the 1.2 release is when the BSPs are released IIRC?). One question would be whether to disable unionfs in ktypes/standard or just from the individual BSPs? There's also the option of fixing the script in the BSPs by overriding initramfs-live-boot.
unionfs itself works, and it really should work for this. So I'd rather not disable it completely. There are other users of the 3.2 kernel, that are using the unionfs support (and it works there). There's just something about the hardware boot + filesystem stacking that is causing this. This was booted many times on qemu and it worked there. So either disabling it via turning off unionfs in the BSPs, or by overriding the scripts seem like the only two options at hand.
I agree that it would be nice to not have to disable unionfs at all, even for the BSPs (after all someone sometime will want to turn it on for other reasons), and the ability to boot LiveCDs as it was added for in the first place is itself a valuable feature, so if possible it would be nice to just override the script with a fixed version instead...
Agreed. We can start with trying to fix the script and issues at hand .. yang can you dig into this on Friday ?
Hmm, I'm thinking there's one BSP that can't be fixed this way - atom-pc, in which case the fix would be to fix the script directly. I don't have the hardware to test that - I guess QA does, and is testing those BSPs?
I can test atom-pc. But it is in meta-yocto, so are we effectively stuck with this for 1.2 on atom-pc?
(In reply to comment #14) > I can test atom-pc. But it is in meta-yocto, so are we effectively stuck with > this for 1.2 on atom-pc? Heh, I guess not - I had assumed atom-pc had been moved to 3.2 but it's still at 3.0 according to the machine config. So I guess this really only does affect the BSPs.
Tried some fix for the script, unfortunately nothing changed. As far as I can see, the script should be fine. It sounds a unionfs bug. getcwd breaks on unionfs in specific circumstance, some similar issues were raised in unionfs community, but it sounds not get fixed completely. However, I think we need more time to look into it and collaborate with upstream. The workaround is to cd any dir (like "cd /proc") before running commands, like pwd, ls, etc.
This should be fixed now with the unionfs fixes reverted. Can this be marked resolved?
(In reply to comment #17) > This should be fixed now with the unionfs fixes reverted. Can this be marked > resolved? Yes, this is no longer a problem.
Thanks Darren. Yes, I agree to mark it resolved since Tom already confirmed. BTW, what fixes were reverted for unionfs?
I believe this is the commit in question: commit 939e6947aed7a5747e2761e9b2f3c80f71503f49 Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Sun Apr 22 15:47:30 2012 +0100 initramfs-live-boot: Disable unionfs until its issue with the system rootdir are resolved There are issues with the current unionfs when making a union mount over "/". Until these are resolved we can't use unionfs for live booting so disable this temporarily as a workaround. unionfs is usable in other circumstances. [YOCTO #2331 workaround] (From OE-Core rev: 60ee26ae23132b916019d58e20b8c2e1ddd2b471) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
.