Project

General

Profile

Bug #12474

tftpboot files are not deleted when OS name is changed

Added by Bryan Kearney over 3 years ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
TFTP
Target version:
-
Difficulty:
Triaged:
Bugzilla link:
Pull request:
Team Backlog:
Marek
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1279979
Description of problem:

If an OS is changed or renamed to a name a different OS had the boot files in /var/lib/tftpboot/boot are not deleted.

We have two OSs RedHat 6.6 server and RedHat 6.6 Workstation. When creating an OS we are only able to specify Name = RedHat, Major Version = 6, Minor Version = 6 but we cannot do that because the names conflict. Instead we have named our server version RedHat and workstation version RedHat-1. We found out that this caused an error so we switch the names. Now server is RedHat-1 and workstation is RedHat. However when we try to build a workstation or server it was kernel panicing. The solution was to remove the files in /var/lib/tftpboot/boot so they would be re-cached from the installation media the next time a machine is going to be built. The deletion of those files should happen automatically when the OS name is change. There also should be a way to specify the flavor or version or even distid from factor so we can differentiate our OS types.

Version-Release number of selected component (if applicable):

Satellite 6.1.3


Related issues

Related to Smart Proxy - Bug #5069: TFTP automatic boot file download does not track updatesNew2014-04-03

History

#1 Updated by Dominic Cleal over 3 years ago

  • Related to Bug #5069: TFTP automatic boot file download does not track updates added

#2 Updated by Dominic Cleal over 3 years ago

  • Category set to TFTP

You need to file the issue with Facter on their issue tracker, this isn't part of Foreman.

#3 Updated by Bryan Kearney over 3 years ago

Dominic Cleal wrote:

You need to file the issue with Facter on their issue tracker, this isn't part of Foreman.

Dominc, why is this related to Facter?

#4 Updated by Dominic Cleal over 3 years ago

Bryan Kearney wrote:

Dominic Cleal wrote:

You need to file the issue with Facter on their issue tracker, this isn't part of Foreman.

Dominc, why is this related to Facter?

You wrote: "There also should be a way to specify the flavor or version or even distid from factor so we can differentiate our OS types."

#5 Updated by Justin Garrison over 3 years ago

Facter provides the facts needed but foreman doesn't use them. On hosts I can run facter and use either lsbdistid, lsbdistdescription. Both specify if they are server, workstation, hpc, atomic etc. The way foreman has provisioning implemented assumes all of 1 type. there needs to be a way to deploy more than 1 type of a OS version.

#6 Updated by Tomáš Strachota over 1 year ago

  • Target version set to 115

Also available in: Atom PDF