[Gelöst] cp: failed to extend

stefanoIT

Neuer User
Mitglied seit
11 Jul 2007
Beiträge
67
Punkte für Reaktionen
1
Punkte
0
I'm using the updated trunk of freetz on ubuntu 14.04.
When I try to pack the firmware I get the following errors on all files modified.
There is a fix for that? Thanks.
Code:
cp: error reading â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/enâ: Is a directory
cp: failed to extend â../FRITZ.Box_7362_SL.131.06.20.image.mod/modified/filesystem/etc/default.Fritz_Box_HW203/avme/enâ: Is a directory
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/fboxdesc-template.xmlâ: Invalid argument
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/wlan_defaults.cfgâ: Invalid argument
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/l2tpv3.xmlâ for reading: Too many levels of symbolic links
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/providers-027.tarâ: Invalid argument
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/ar7.cfgâ: Invalid argument
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/MediaServerDevDesc-xbox.xmlâ for reading: Too many levels of symbolic links
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/providersâ for reading: Too many levels of symbolic links
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/igddesc.xmlâ for reading: Too many levels of symbolic links
cp: cannot access â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/providers-0352.tarâ: Not a directory
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/aura.xmlâ for reading: Too many levels of symbolic links
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/providers-041.tarâ: Invalid argument
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/GPMDevDesc-template.xmlâ: Invalid argument
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/FRITZ-Logo-48x48.pngâ: Invalid argument
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/root_ca_mnet.pemâ: Invalid argument
cp: cannot access â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/calllist.luaâ: Not a directory
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/.start_indexation.mp3â: Invalid argument
cp: cannot open â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/mediapathâ for reading: Too many levels of symbolic links
cp: cannot read symbolic link â../FRITZ.Box_7362_SL.131.06.20.image.mod/original/filesystem/etc/default.Fritz_Box_HW203/avme/providers-043.tarâ: Invalid argument
 
Zuletzt bearbeitet:
It looks like you're using some unexpected or unusual language settings ...

I'm unable to see it due to shortage of context around the posted error messages, but I'd assume, it happens after the "Step 3: ..." message immediately ?

Probably the "cp" command at line 1429 of "fwmod" fails, because it can't handle a difference between the english charset and your current selection ? Your copied lines are looking strange with the 'â' character as delimiter around the source path name.
 
What I'm trying to do is this:

I unpack the original firmware, (fwmod -u)
I modify some files to add another language. I just copy the new files from a different firmware using command "cp -r"
I try to repack (fwmod -p) the result and I have the error on all the files changed.

My regional setting is english, the â is present in all ubuntu error message.
 
Ok, I see ...

1. Using the â as string delimiter stays to be an unexpected behaviour ... but it may be a curious codepage mapping for terminal display only. Perhaps your terminal program (I'd think, you aren't using the Ubuntu as your "native" system, are you ?) is using the wrong(?) setting here.

2. Please provide some lines in front of the cited messages above next time, it's much easier to find the failing command, if we know where to look for.

3. Please make sure the access permissions of the injected files (copied with your own cp command) match the originals, you could compare them to the previous ones.

4. As long as you're using the fwmod script to pack the modified image only, it's not difficult to manage a logging of executed commands using "bash -x fwmod -p -d <dir> dummy" instead of the pure call. The fwmod script tries to copy the unpacked tree to a new 'modified' directory, imho this copy fails ... but I've no idea, where you made the mistake. If you want to make sure it's not a problem of Freetz by itself, you can try to pack a new image without your own files first.

There is a fix for that?
I'd think, the correct answer is: "There's always a fix (or mostly).", but it's quite different from your expectations.
Imho there's something wrong with your copied files, not with the AVM image content or the fwmod script. Personally I'd try to bear in mind point 3 above and find the difference between the original files and my own modifications.
 
If I unpack, left the files untouched and pack, there is no issue. All works properly.
I double checked the files copied and the permissions are the same. I used also cp -a to preserve all.

I tried to debug the script but it won't

bash -x ./fwmod -p ../FRITZ.Box_7362_SL.131.06.20.image

ERROR: fwmod must not run in a fakeroot environment
 
You're right, the internal use of fakeroot - to extract/pack files owned by root without hassle - makes it impossible to use an explicit call to bash in front of it.

You could edit the fwmod script and add an extra line with "set -x":
Code:
--- fwmod       2014-11-16 13:46:54.679763409 +0100
+++ ../trunk_7490/fwmod 2014-10-28 17:15:37.803031801 +0100
@@ -1403,8 +1403,6 @@
 # -- Common initial actions for pack, zip, copy --
 # ------------------------------------------------

-set -x
-
 if [ "$action_names" ]; then
        echo0 -b "STEP 3: ${action_names}"
(patch generated for the wrong direction, sorry ... but you should be able to catch a meaning of my intention)

One more time: Please do me a favour and add some context to the error messages. Until now the failing command is still guesswork ...

You did agree, it's a problem with your own files, didn't you ? I'm still bent on helping you ... but you've to provide enough information to make it possible.

If the suspected command at line 1427 (original lines counted now, the previous line number was wrong due to some earlier changes by myself) fails, it needs a reason to do this. Because it's a directory based recursive copy command without any wildcards, the only meaningful explanation is a problem enumerating subdirectories and their content. There has to be something different in comparision with the original tree content.
 
And now the command line used to call the fwmod script too, pls ...
 
Just this

Code:
./fwmod -p ../FRITZ.Box_7362_SL.131.06.20.image

Thank you
 
./fwmod -p ../FRITZ.Box_7362_SL.131.06.20.image
That's wrong ... did you ever read this posting and some of the following (they're in german, so I'd accept the answer: no) ?

You've missed to specify the directory with the unpacked firmware image. Insert an additional "-d <directory>" between fwmod and -p and you're one step behind the current problem.
 
I used the command

Code:
./fwmod -p -d ../FRITZ.Box_7362_SL.131.06.20.image.mod  ../FRITZ.Box_7362_SL.131.06.20.image

but nothing changed
The log is attached.

Anhang anzeigen log2.txt

If I do the following command by hand it works
Code:
cp -r ../FRITZ.Box_7362_SL.131.06.20.image.mod/original ../FRITZ.Box_7362_SL.131.06.20.image.mod/modified
in the fwmod script it doesn't
 
Zuletzt bearbeitet:
1. Execute:
Code:
cp ../FRITZ.Box_7362_SL.131.06.20.image dl/fw/
2. Execute:
Code:
./fwmod -u -d repack7362 dl/fw/FRITZ.Box_7362_SL.131.06.20.image
3. Apply your own patches.
4. Execute:
Code:
./fwmod -p -d repack7362 dl/fw/FRITZ.Box_7362_SL.131.06.20.image
(appending the image name is meaningless but still needed)
If an error occurs, I'll have a look at your patches ... didn't it yet.
 
It's really weird.
How did you create the patch file ?

Everything mentioned until now is still valid ... but your patch file contains DOS/Windows line endings (cr/lf).

That could be an explanation for the weird display of the path names in your first posting.

As far as there is an additional ^M character after your file names, Linux simply adds it to the path name. That means, a command like
Code:
cp -r  $SRC/usr/www.myfritz/avme $DST/usr/www.myfritz/.^M
will not store the 'avme' directory underbelow the /usr/www.myfritz directory ... it will be created as /usr/www.myfritz/.^M/avme instead -> the result is an unwanted directory structure and I think, later commands become puzzled.

I'd suggest, you take an editor with the ability to display line end characters and edit your patch file. After that, try again ... but wipe out the repack7362 directory first to make sure, there are no more directories with an ^M within their name.

If it still fails, report again ...
 
Zuletzt bearbeitet:
I created the patch.sh file on UNIX using vi. There are no CRs at the end of the line.

This is the original Unix (sealed in a tar archive) version without SFTP to windows (that could add one CR to the end of the line).

Anhang anzeigen patch.tar
 
If you download the patch file from your link at #7, you get a file with cr/lf too, don't you ?

I did it and after recognizing the line endings, I thought to be on the right way.

Anyway ... while I write that text, a build of the toolchain to extract 7360v2 files from images is running in the background. My patience is about to run out and now I'm going to check the same setup, step by step. It'll take some time, but I'd like to find the real cause ... it's really ridicolous, that we can't find it.
 
I can provide the access to my setup via ssh if you need.
Thanks for your patience.
 
Unnecessary ... meanwhile I'm able to reproduce the problem with a duplicate setup.

My patience is not exhausted from your questions and tests, I'm furious about the impossibility to catch that nasty error.
 
Ok, tracked it down to a libfakeroot issue ... but I'm not even going to try to fix it.

Instead I've modified the patch file to prepare the 'modified' subdirectory outside the fwmod script:
Code:
#!/bin/bash
WORKDIR="$1"
SCNDSRC="$2"
ORG=$WORKDIR/original/filesystem
SRC=$SCNDSRC/original/filesystem
DST=$WORKDIR/modified/filesystem

DEFSRC=$SRC/etc/default.Fritz_Box_HW196
DEFDST=$DST/etc/default.Fritz_Box_HW203

#modified
mkdir -p $WORKDIR/modified
cp -a $WORKDIR/original/* $WORKDIR/modified/
touch $WORKDIR/.modified

#libreria
cp -f $SRC/lib/libtiinterpreter.so.0.0.0 $DST/lib

#html
cp -f $SRC/etc/htmltext_*.db $DST/etc/
rm -f $DST/etc/htmltext.db
ln -s /etc/htmltext_en.db $DST/etc/htmltext.db

#language
cp -f $SRC/etc/*.language $DST/etc/

#default
cp -rf $SRC/etc/default.0* $DST/etc/
cp -rf $SRC/etc/default.99 $DST/etc/

#default.Fritz
rm -rf $DEFDST/1und1
rm -rf $DEFDST/avm
cp -rf $DEFSRC/avme $DEFDST/

#www
rm -rf $DST/usr/www/1und1
rm -rf $DST/usr/www.myfritz/1und1 $DST/usr/www.myfritz/avm
rm -rf $DST/usr/www.nas/1und1 $DST/usr/www.nas/avm

mv  $DST/usr/www/avm $DST/usr/www/avme
cp -r  $SRC/usr/www.myfritz/avme $DST/usr/www.myfritz/
cp -r  $SRC/usr/www.nas/avme $DST/usr/www.nas/

#tam
rm -rf $DST/usr/share/tam/msg/default
cp -rf $SRC/usr/share/tam/msg/default $DST/usr/share/tam/msg/
I was able to build a modified image with the following steps:

1. Unpack the 7362SL image (use the proper command with -d option, only as a precaution)
2. Prepare the second source directory with 7360 files
3. Call the patch with the unpacked 7362SL directory as first and the 7360 directory as second argument
4. Pack the new image

I've never tested the new image due to lack of such a device ... only checked the expected content after unpacking the new core squashfs again.
 
It works like a charm :rosen:
Thank you vary much.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.