Hi Adolf,

comments below...

On 17.09.2022 17:06, Adolf Belka wrote:
> Hi Matthias,
> 
> On 17/09/2022 15:12, Matthias Fischer wrote:
>> Hi,
>> 
>> comments below... ;-)
>> 
>> On 17.09.2022 13:29, Adolf Belka wrote:
>>> 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-core170-x86_64.iso
>>>>
>>>> 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.
>> 
>> Exactly.
>> 
>>> I am not sure I am understanding the point you are making. Maybe I am
>>> confusing what you are saying.
>> 
>> No problem, we'll sort this out... ;-)
>> 
>>> My understanding is that the name of the download file on the IPFire
>>> server has changed...
>> 
>> Exactly. "Something" was changed during ISO-creation. On my devels the
>> final Core170-ISOs got new names, too. But why!?
>> 
>>> 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.
>> 
>> No.
>> 
>>> Am I misunderstanding you?
>> 
>> Perhaps. A bit...;-)
> I was misunderstanding you. We were actually saying the same thing.
> 
> I also missed that you were saying the build ISO name had changed. I went and had a look at my recent build and found exactly what you said.

:-)

> I had a look through make.sh and eventually figured out that it was the cdrom package that was modified by Michael to make the iso and image filenames more aligned.

Oh my. I never thought of searching there. I must have overlooked this
commit somehow.

> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fbd0608c2cb5372fff7857065ec7e605b1bf9cf7
> 
> So the change was deliberately done but backup.pl etc was missed.

Yep.

> Thanks for your help in figuring it out.

No problem. Had fun... ;-)

> I will create a patch to fix backup for CU171.

IMHO patching 'backup.iso' could perhaps be the easiest way. YMMV.

Best,
Matthias

> Regards,
> Adolf.
>> 
>> What I mean: *nothing* has changed in 'backup.iso' but *needs* to be
>> changed so the download works again. Could be the easiest way.
>> 
>> OR: change the ISO naming conventions - read: the way the ISO are named.
>> But where is this done!?
>> 
>> What I didn't find yet: what process or code line(s) is(are) responsible
>> for the new names. And I just can't find anything responsible in
>> 'backup.pl'. Perhaps some args have changed. But where!?
>> 
>> Best,
>> Matthias
>> 
>>>
>>> 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.x86_64-full-core169.iso
>>>>>>>>
>>>>>>>> https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire-2.27-core170-x86_64.iso
>>>>>>>>
>>>>>>>> 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.
>>