Re: Incorrect naming convention used on the Core Update 170 download file.

[Matthias Fischer <matthias.fischer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4958 bytes --]

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...;-)

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.