Bug 12757

@Adolf, may I be so blunt to assign this one to you? It sounds like being an easy one, and since you already worked on the backup scripts, perhaps you come up with a solution just like that. :-)

Thank you in advance!

Hi @Peter
No problems, I will pick this up and have a go at it.

So my first step was to try and duplicate the problem so I would be able to test that it had been fixed.

I ran into a problem. I used CU162 on my vm testbed and ran a backup to iso and then used that to do the install on another vm.

The backup in the iso was found and I said yes to use it but then it failed to run because of another bug 12737 which @michael has raised a patch for and is merged into next for CU163

@deyan what core update did you use when the problem was detected.

My plan is to wait for the backup bug fix to be available with CU163 Testing and to then repeat the duplication and confirm that I have the same problem.

(In reply to Adolf Belka from comment #3)
> So my first step was to try and duplicate the problem so I would be able to
> test that it had been fixed.
> 
> I ran into a problem. I used CU162 on my vm testbed and ran a backup to iso
> and then used that to do the install on another vm.
> 
> The backup in the iso was found and I said yes to use it but then it failed
> to run because of another bug 12737 which @michael has raised a patch for
> and is merged into next for CU163
> 
> @deyan what core update did you use when the problem was detected.
> 
> My plan is to wait for the backup bug fix to be available with CU163 Testing
> and to then repeat the duplication and confirm that I have the same problem.

Hi Adolf, I don't remember but I've never gotten too far behind upgrading and based on the time of my forum post I'd guess that the version was this one - IPFire 2.25 - Core Update 153. I had no issues with restoring the backup other than the DHCP server problem.

Hi Deyan,

Thanks. Then it is clear that the backup bug is not related to the problem you had as that occurred after CU153.

CU163 is due to go to Testing shortly so I will wait for that to ensure I have a good working backup iso process.

I will report back when I have more news.

My apologies for no input for a while. This bug dropped of my radar screen.

I have now come back to it and I created an iso backup on a CU171 vm with red, green, blue and orange interfaces.

Then I installed from that iso backup into a cloned vm. After completing the install and selecting to take the backup contents into the install I found that dhcpd was not running but I also got a message that the variables RED_TYPE and RED_DEV were uninitialised and therefore there was no red0 interface.

Additionally I had the message that ADDRESS and/or NETMASK variable missing from input, cannot continue   FAIL

Running ip address show I found only eth0, eth1 eth2 & eth3. the interfaces red0, green0, blue0 and orange0 have not been created.

I repeated the install using the same iso file and got the same result.

I then created another iso backup file and did the install from that and again got the same issue.

This is definitely different from what was found by @Deyan where the interfaces were created but dhcpd was not running.

This might be a new bug that has been created since this bug was originally raised. If it is I will make another bug report and make these two bugs have a reference to each other.

To test this I will create a CU170 vm and run the iso backup on that and then CU169 until I find a point where the install from the iso backup gives a system that has the red0, green0 etc interfaces all properly created.

Ignore my comment 6.

I forgot that the backup cannot set up the interface ip addresses and that after running the install with backup you have to login on the console and run setup to set up the interfaces to nics and the ip addresses.

Have done that and found that dhcpd was not running as mentioned.

Tried just starting dhcp on the command line and it failed.

I then edited the initscript for dhcpd to remove the quiet option. Then retried starting dhcpd and got back the message that the router adress was not a correct ip from the dhcpd.conf file.
I checked the file and it had the green interface IP address twice. So instead of

option routers 192.168.200.254;

for the green0 interface it had

option routers 192.168.200.254192.168.200.254;

dhcpd when starting too the first four ctets which then were 192.168.200.254192 and clearly found that the last octet was too large.

Manually editing the dhcpd.conf file for both green and blue to correct that allowed dhcpd to start properly.


Then question is then why the option routers entry had the ip address twice.

I mounted the iso with backup and looked at the dhcpd.conf file in the iso and the entry in there was as it should be with the ip address only once.

This suggests that somewhere in the installer coding it is appending the option routers ip address a second time somewhere.

I will now have a look through the installer code to see if I can find where the problem is occurring causing the incorrect option routers ip address to end up in the dhcpcd.conf file.

Reran the install and backup and then when that was finished, before running setup I checked the dhcpd.conf file. It had the correct entrie option routers entry in it.

That means that the installer section did the entries correctly.

Then I ran the setup command, just for the Networking section and added in the green and red information - nic and ip assignments. Then exited setup which restarted the networking.

Then I checvked the dhcpd.conf file and it now had the incorrect options router entry in it.

This means that the error is occurring as part of the setup command. Most of the code for this is c based and I am not familiar with that at all. Will attempt to have a look through the code and use this as a learning opportunity as a first start.

Reading through the original bug report and the forum post it is clear that originally just adding in the starting link for dhcp worked.

I have tested this on my vm testbed and that does not work on its own. Even with the link in place the  dhcp server fails to start and by making the initscript non quiet it reports that there are configuration errors in dhcpd.conf. These are due to the additional ip address entered into the options router entry.

Looking through the networking.c code in the setup file I have found the place where this is occurring.

I have not been able to find any commit on the networking.c file.

I would like to ask @Deyan if it would be possible to repeat the exercise with the current versions and see if the only issue is the startup link or if the problem with the double ip address in the dhcpd.conf is also found.

I want to determine if some new change came in after CU153 that caused what I am finding or if I am not following the steps as done by @Deyan when trying to reproduce the problem.

@Adolf - I have only restored from an ISO backup once and I had the issue. I tried documenting the steps correctly but it is possible that I did something out of order also that put the correct gateway in the options.

*** Bug 12741 has been marked as a duplicate of this bug. ***

Hi @Michael,

This is the bug we discussed a few conf calls ago. I am unable to figure out how to fix it.

The problem is that the routers line in dhcpcd.conf ends up with the router IP being listed twice in succession from the install/restore from ISO and this causes dhcpd to not start.