[Gelöst] cp: failed to extend
- Ersteller stefanoIT
- Erstellt am
Hi @PeterPawn,
something is wrong copyng original directory by hands as you suggested.
Unpacking the original firmware this is the result
after cp -r original to modified and touch .modified
I packed it.
If I unpack the new firware the result is
There are a lot of new files in both filesystems I dont know where they came from.
The new firmware is not working anymore and freezes on
I think that cp -r is not enounght and there is necessary some type of cleaning before packing again.
something is wrong copyng original directory by hands as you suggested.
Unpacking the original firmware this is the result
Code:
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
Reading a different endian SQUASHFS filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/firmware/var/tmp/filesystem.image
Filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/firmware/var/tmp/filesystem.image is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
184 inodes (485 blocks) to write
created 7 files
created 11 directories
created 91 symlinks
created 86 devices
created 0 fifos
unpacking filesystem image
Reading a different endian SQUASHFS filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/filesystem_core/filesystem_core.squashfs
Filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/filesystem_core/filesystem_core.squashfs is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
3777 inodes (4264 blocks) to write
created 3179 files
created 217 directories
created 512 symlinks
created 86 devices
created 0 fifos
unpacking var.tar
done.after cp -r original to modified and touch .modified
I packed it.
If I unpack the new firware the result is
Code:
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
Reading a different endian SQUASHFS filesystem on ../7362SL.image.mod/original/firmware/var/tmp/filesystem.image
Filesystem on ../7362SL.image.mod/original/firmware/var/tmp/filesystem.image is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
184 inodes (399 blocks) to write
created 93 files
created 11 directories
created 91 symlinks
created 0 devices
created 0 fifos
unpacking filesystem image
Reading a different endian SQUASHFS filesystem on ../7362SL.image.mod/original/filesystem_core/filesystem_core.squashfs
Filesystem on ../7362SL.image.mod/original/filesystem_core/filesystem_core.squashfs is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
3778 inodes (4179 blocks) to write
created 3266 files
created 217 directories
created 512 symlinks
created 0 devices
created 0 fifos
unpacking var.tar
done.There are a lot of new files in both filesystems I dont know where they came from.
The new firmware is not working anymore and freezes on
Code:
[ 5.240000] Warning: unable to open an initial console.
[ 5.240000] trying /sbin/initI think that cp -r is not enounght and there is necessary some type of cleaning before packing again.
The files added by the copy and not removed during packing are the files in /dev (86 files in filesystem_core and 87 files in filesystem).
I don't know if I have to remove them by hand to avoid the stucking during the boot.
In my opinion the devices are not created properly during paking.
I don't know if I have to remove them by hand to avoid the stucking during the boot.
In my opinion the devices are not created properly during paking.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Meanwhile I don't understand, where you differentiate between "by hands" and "by script".
Please describe the whole process including all entered commands and all used scripts and your counterpart will/should be able to reproduce the result.
If I understood it right now, the oriiginal filesystem does not contain some entries below the /dev directory ... but the modified subdirectory contains them after copying from the original subtree? Where do they come from so suddenly? They shouldn't be created by the copy action and so I've no idea, what you're doing there.
Furthermore the old issue from the "fakeroot" packet surely still exists and you're sure, that you do every time a fresh "unpack" after removing the old content completely? Using the same directory more than once leads to unpredictable behavior ... according to my findings with a 7270v3 and "repacking tests" with "fwmod". That's why I do not use "fakeroot" and Freetz for repacking purposes - nowadays it's not necessary to use "fakeroot" to get the correct file ownership and permissions, because there are options for the filesystem creation utilities to set a "fixed owner" (the "--all-root" option of "mksquashfs" for example).
Please describe the whole process including all entered commands and all used scripts and your counterpart will/should be able to reproduce the result.
If I understood it right now, the oriiginal filesystem does not contain some entries below the /dev directory ... but the modified subdirectory contains them after copying from the original subtree? Where do they come from so suddenly? They shouldn't be created by the copy action and so I've no idea, what you're doing there.
Furthermore the old issue from the "fakeroot" packet surely still exists and you're sure, that you do every time a fresh "unpack" after removing the old content completely? Using the same directory more than once leads to unpredictable behavior ... according to my findings with a 7270v3 and "repacking tests" with "fwmod". That's why I do not use "fakeroot" and Freetz for repacking purposes - nowadays it's not necessary to use "fakeroot" to get the correct file ownership and permissions, because there are options for the filesystem creation utilities to set a "fixed owner" (the "--all-root" option of "mksquashfs" for example).
My process is:
1) unpacking the firmware
2) do patching (using script)
3) repacking firmware
As you suggest the script create a copy of original folder (cp -r original modified) then create the .modified file.
During the packing the /dev/* should be ignored and all 86 devices should be rcreated by makedevices tool. That does not happen and in the new image I have no devices and 86 files more that before. Both on filesystem_core and file_system.
That does not happens if I unpack the firmware and pack it without any modification. The pack is correct.
1) unpacking the firmware
2) do patching (using script)
3) repacking firmware
As you suggest the script create a copy of original folder (cp -r original modified) then create the .modified file.
During the packing the /dev/* should be ignored and all 86 devices should be rcreated by makedevices tool. That does not happen and in the new image I have no devices and 86 files more that before. Both on filesystem_core and file_system.
That does not happens if I unpack the firmware and pack it without any modification. The pack is correct.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Are the additional files present immediately after unpacking? I don't think so ... if they were, they would be packed again even without modification in between. If they are not packed, they do either not exist or they are ignored. If you use "fwmod" to unpack and immediately after unpacking to pack the same tree, copying the "original" tree to "modified" is done by "fwmod" (and a warning is issued).
If the unwanted files are not present after unpacking and even not after the implicit copy process, they can only be the result of the modification process, do you agree?
If your own modifications include copying the files, it does matter, which "cp" command is used.
The "cp" applet of the "busybox" has other parameters than the "cp" utility from the "GNU coreutils" package.
You want to copy at first the whole subtree recursively (from "original" to "modified") preserving any symlinks (and dates/permissions, if possible) and how you do this (a pipe with tar and untar is another possibility, IMHO "fwmod" uses this opportunity), is solely your decision.
Using "cp -a" should work reasonable with both implementations ... if - and only if - you want to preserve symlinks. You shouldn't use this to copy files from a third source, because it would copy only the symlinks to files instead of the content, if there are such symlinks in use.
The behavior of the busybox applet should vary, if you use "-r" instead of "-R". The first variant does not preserve symlinks, the second one should do so (if the help text isn't wrong there).
Which "script" do you use to modify the subtree in your step 2? That was the heart of the matter in my text in #24.
And if you mean my writing in #19, there I've used
nearly a year ago (and the post wasn't changed later) already and that's a difference to "cp -r" as I wrote above.
Do you see my confusion what you're meaning? :gruebel:
If the unwanted files are not present after unpacking and even not after the implicit copy process, they can only be the result of the modification process, do you agree?
If your own modifications include copying the files, it does matter, which "cp" command is used.
The "cp" applet of the "busybox" has other parameters than the "cp" utility from the "GNU coreutils" package.
You want to copy at first the whole subtree recursively (from "original" to "modified") preserving any symlinks (and dates/permissions, if possible) and how you do this (a pipe with tar and untar is another possibility, IMHO "fwmod" uses this opportunity), is solely your decision.
Using "cp -a" should work reasonable with both implementations ... if - and only if - you want to preserve symlinks. You shouldn't use this to copy files from a third source, because it would copy only the symlinks to files instead of the content, if there are such symlinks in use.
The behavior of the busybox applet should vary, if you use "-r" instead of "-R". The first variant does not preserve symlinks, the second one should do so (if the help text isn't wrong there).
Which "script" do you use to modify the subtree in your step 2? That was the heart of the matter in my text in #24.
Where and when did I suggest this? I can't remember ... at least not within the last two weeks.stefanoIT schrieb:
And if you mean my writing in #19, there I've used
Code:
cp [COLOR="#FF0000"][B]-a[/B][/COLOR] $WORKDIR/original/* $WORKDIR/modified/Do you see my confusion what you're meaning? :gruebel:
Thanks for your help
I did many attempts to find out what is the problem with that.
I done this test:
1) unpacking the firmware
2) copy the original to modified with cp -a
3) touch file .modified
4) packing
The result is that the devices are disappeared from the packed firmware and turned into files.
Could be that the creation of file .modified prevents fwmod to execute MAKEDEVICES and ricreate the devices before the packing.
I can show you the debug log of fwmod during the packing.
I did many attempts to find out what is the problem with that.
I done this test:
1) unpacking the firmware
2) copy the original to modified with cp -a
3) touch file .modified
4) packing
The result is that the devices are disappeared from the packed firmware and turned into files.
Could be that the creation of file .modified prevents fwmod to execute MAKEDEVICES and ricreate the devices before the packing.
I can show you the debug log of fwmod during the packing.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Did you have a look into the "modified" directory immediately after copying the subtree from "original"? Are the source and destination tree identical? If you copy a "special file" mentioning a linux device (character or block doesn't matter) with "cp -a", the destination should contain the inode for the "special file" and neither its content nor anything else. You should verify the intermediate result after each step and not only watch the final result.
PS: And the wanted script is still missing ... anybody interested in the problem is unable to reproduce your issue(s), if you don't publish the used script. If you do not use a script to modify the copied subtree, write down the used commands here. You've to dare it ... only reading the used commands (and perhaps execute them ourself) may reveal the problem.
PS: And the wanted script is still missing ... anybody interested in the problem is unable to reproduce your issue(s), if you don't publish the used script. If you do not use a script to modify the copied subtree, write down the used commands here. You've to dare it ... only reading the used commands (and perhaps execute them ourself) may reveal the problem.
Zuletzt bearbeitet:
I unpacked the original firmware from sratch.
The file in the /dev are normal file.
I think that they are changed into devices after chroot and before packing by fwmod script (using makedevices tool).
If I pack now all is fine, but if I manually create the modified directory (cp -a) and touch the .modified file the makedevices tool is not used and the new fimware contains no devices at all but only files.
You can try this by yourself.
This is my result:
Code:
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
Reading a different endian SQUASHFS filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/firmware/var/tmp/filesystem.image
Filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/firmware/var/tmp/filesystem.image is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
184 inodes (485 blocks) to write
created [COLOR="#FF0000"]7 files[/COLOR]
created 11 directories
created 91 symlinks
created [COLOR="#FF0000"]86 devices[/COLOR]
created 0 fifos
unpacking filesystem image
Reading a different endian SQUASHFS filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/filesystem_core/filesystem_core.squashfs
Filesystem on ../FRITZ.Box_7362_SL.131.06.30.image.mod/original/filesystem_core/filesystem_core.squashfs is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
3777 inodes (4264 blocks) to write
created [COLOR="#FF0000"]3179 files[/COLOR]
created 217 directories
created 512 symlinks
created [COLOR="#FF0000"]86 devices[/COLOR]
created 0 fifos
unpacking var.tar
done.The file in the /dev are normal file.
Code:
ls -al original/filesystem_core/dev/
total 12
drwxr-x--- 3 steve steve 4096 Jul 13 15:36 .
drwxr-x--- 11 steve steve 4096 Jul 13 15:37 ..
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace0
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace128
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace129
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace130
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace131
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace132
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace133
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace134
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace135
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace136
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace137
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace138
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace139
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace140
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace141
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace142
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace143
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace160
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace161
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace162
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 avm_net_trace163
lrwxrwxrwx 1 steve steve 12 Sep 24 05:20 caldata -> /var/caldata
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 console
lrwxrwxrwx 1 steve steve 19 Sep 24 05:20 kdsld_misc -> /var/dev/kdsld_misc
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 kmem
-rw-rw-rw- 1 steve steve 0 Jul 13 15:36 led
lrwxrwxrwx 1 steve steve 10 Sep 24 05:20 log -> ../tmp/logI think that they are changed into devices after chroot and before packing by fwmod script (using makedevices tool).
If I pack now all is fine, but if I manually create the modified directory (cp -a) and touch the .modified file the makedevices tool is not used and the new fimware contains no devices at all but only files.
You can try this by yourself.
This is my result:
Code:
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
Reading a different endian SQUASHFS filesystem on ../7362SL.image.mod/original/firmware/var/tmp/filesystem.image
Filesystem on ../7362SL.image.mod/original/firmware/var/tmp/filesystem.image is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
184 inodes (399 blocks) to write
[COLOR="#FF0000"]created 93 files[/COLOR]
created 11 directories
created 91 symlinks
[COLOR="#FF0000"]created 0 devices[/COLOR]
created 0 fifos
unpacking filesystem image
Reading a different endian SQUASHFS filesystem on ../7362SL.image.mod/original/filesystem_core/filesystem_core.squashfs
Filesystem on ../7362SL.image.mod/original/filesystem_core/filesystem_core.squashfs is gzip compressed (3:0)
Parallel unsquashfs: Using 1 processor
3778 inodes (4179 blocks) to write
[COLOR="#FF0000"]created 3266 files[/COLOR]
created 217 directories
created 512 symlinks
[COLOR="#FF0000"]created 0 devices[/COLOR]
created 0 fifos
unpacking var.tar
done.PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Nice, that's why I had asked multiple times to provide the whole procedure including all commands.
If you had used the proposed way to start own scripts for such a modification (via fwmod_custom), the needed fakeroot environment should have been set up already for this script (if that's not the case, it's an error/malfunction of fwmod) and you haven't to consider it separately.
So this isn't a real issue ... at least not one with Freetz - as long as it's functioning as expected, if your own script is called from (or embedded into) "fwmod_custom".
If you had used the proposed way to start own scripts for such a modification (via fwmod_custom), the needed fakeroot environment should have been set up already for this script (if that's not the case, it's an error/malfunction of fwmod) and you haven't to consider it separately.
So this isn't a real issue ... at least not one with Freetz - as long as it's functioning as expected, if your own script is called from (or embedded into) "fwmod_custom".
Neueste Beiträge
-
Deutsche Glasfaser - Telefonnr. nicht registrierbar
- Letzte: sulihari
-
FRITZ!Box 7590AX - INHAUS - Smart24P1 - 7.90 - Sammelthema- Letzte: Robert T-Online
-
[Frage] Erklärung Entstehung/Aufbau SIP/SDP gesucht- Letzte: chrsto
-
FRITZ!Box 7590 - INHAUS - Smart24P1 - 7.90 - Sammelthema
- Letzte: Heisenberg2018
-
1&1 Anschluss keine 100Mbit mehr- Letzte: frank_m24
-
Grandstream HT 818 an Fritzbox 7590
- Letzte: KunterBunter
