Hi Matthias,
On 17/09/2022 13:00, Matthias Fischer wrote:
Hi,
please find my comments below... ;-)
On 17.09.2022 12:22, Adolf Belka wrote:
Hi Matthias,
On 17/09/2022 11:28, Matthias Fischer wrote:
Hi,
Confirmed. Somehow the name of the ISO has changed.
But - correct me if I'm wrong! - the naming of the ISO file takes place in '/usr/local/bin/backupiso':
That is correct but before that occurs the first step is to download the original iso from the IPFire download site and it looks in that download site for an iso named ISO="ipfire-$IPFVER.$arch-full-core$COREVER.iso" which is fine for CU169 and earlier but CU170 has had the arch portion moved to a different location in the filename.
Either the new filename structure for the IPFire CU170 download has been changed accidentally or it has been done deliberately but forgotten to change the template in backup.pl etc.
Current is: ... ISO="ipfire-$IPFVER.$arch-full-core$COREVER.iso" ...
IMHO it could be sufficient to change this to: ... ISO="ipfire-$IPFVER-core$CORVER-$arch.iso"
Changing that would fix the problem but only if the change of the download filename on the IPFire server was changed deliberately.
As I see it - ${URL} is OK, but the name of the *file to download* (the ${ISO}-variable) changed - somehow...:
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire-2.27-co...
And ${ISO} is exactly the variable 'wget' needs (e.g):
Line 81 in 'backup.iso': ... wget --quiet -c ${URL}${ISO} ...
Line 84f: ... echo "Fetching ${URL}${ISO}.b2" wget --quiet -O ${ISO}.b2 ${URL}${ISO}.b2
$(ISO) has not been changed in backup.pl or backup.iso. It is still looking for a file named ipfire-$IPFVER.$arch-full-core$COREVER.iso which for CU170 would be
ipfire-2.27.x86_64-full-core170.iso
but on the CU170 download site the file is actually named
ipfire-2.27-core170-x86_64.iso so the word full is missing and the arch (x86_64 or aarch64) has moved to just before the .iso part. So wget will not find the file because the name on the download site will have changed.
I am not sure I am understanding the point you are making. Maybe I am confusing what you are saying.
My understanding is that the name of the download file on the IPFire server has changed and nothing has changed in backup.pl/backup.iso but my understanding is that you think something has changed in backup.iso and that is the cause of the problem. Am I misunderstanding you?
Regards,
Adolf.
...
Or do I miss something? [(Brett vorm Kopf!?)]
Best, Matthias
Regards, Adolf.
...
I haven't searched for other occurences yet, but I think that could be the culprit...
jm2c
Matthias
On 16.09.2022 16:24, Adolf Belka wrote:
Hi All,
On 16/09/2022 16:02, Adolf Belka wrote:
Hi everyone,
On the forum there have been a couple of people who tried creating an iso backup and it only showed a 0 byte file.
I have confirmed with my vm testbed. The same thing works fine for CU169.
After looking through code I have found that Core Update 169 and 170 file name order is different. The arch is placed in a different location
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core169/ipfire-2.27.x8...
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire-2.27-co...
This means that backup.pl is not able to find the Core Update 170 iso from the downloads site.
If the change in iso file naming convention was intended then backup.pl also needs to be modified for the iso naming convention.
Regards,
Adolf.
Regards,
Adolf.