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

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

[Adolf Belka]

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

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.


Regards,

Adolf.

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

[Adolf Belka]

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

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

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

[Matthias Fischer]

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

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':

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

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

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

[Adolf Belka]

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

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.

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

-- 
Sent from my laptop

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

[Matthias Fischer]

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

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

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

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

[Adolf Belka]

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

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.

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

-- 
Sent from my laptop

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

[Matthias Fischer]

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

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

[Adolf Belka]

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

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

[Matthias Fischer]

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

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

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

[Michael Tremer]

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

Hello,

This fucking feature will kill me some time. Or I will kill it.

Matthias, are you going to submit this change as a patch?

-Michael

> On 17 Sep 2022, at 11:28, Matthias Fischer <matthias.fischer(a)ipfire.org> 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':
> 
> 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"
> ...
> 
> 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.
>>> 
>>> 
> 

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

[Adolf Belka]

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

Hi Michael,

On 18/09/2022 11:23, Michael Tremer wrote:
> Hello,
> 
> This fucking feature will kill me some time. Or I will kill it.
> 
> Matthias, are you going to submit this change as a patch?
I am doing a patch for this.

Regards,
Adolf.
> 
> -Michael
> 
>> On 17 Sep 2022, at 11:28, Matthias Fischer <matthias.fischer(a)ipfire.org> 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':
>>
>> 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"
>> ...
>>
>> 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.
>>>>
>>>>
>>
> 

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

[Matthias Fischer]

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

On 18.09.2022 11:23, Michael Tremer wrote:
> Hello,
> 
> This fucking feature will kill me some time. Or I will kill it.

+1

I would testify as a witness for you...
Three years probation and then you would be out again. ;-)

> Matthias, are you going to submit this change as a patch? 

Patch is on the road - see below:

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fbd0608c2cb5372fff7857065ec7e605b1bf9cf7

> -Michael
> 
>> On 17 Sep 2022, at 11:28, Matthias Fischer <matthias.fischer(a)ipfire.org> 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':
>> 
>> 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"
>> ...
>> 
>> 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.
>>>> 
>>>> 
>> 
>