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

[Adolf Belka <adolf.belka@ipfire.org>]

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

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.

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.

Thanks for your help in figuring it out.

I will create a patch to fix backup for CU171.

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