| Submitter | Mark Asselstine |
|---|---|
| Date | Aug. 28, 2012, 6:20 p.m. |
| Message ID | <1346178028-2036-1-git-send-email-mark.asselstine@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/35471/ |
| State | New |
| Headers | show |
Comments
On Tue, 2012-08-28 at 14:20 -0400, Mark Asselstine wrote:
> + if [ "${hostname}" != "none" ]; then
This magic string value seems a bit unwholesome. Can't you just check
against the empty string?
Also, if the problem is that the static hostname set here is overriding
the one from dhcp or the command line, I wonder whether this just
indicates that the priority of them is wrong and the scripting should be
adjusted so that the static file has lower priority than the other two
things.
p.
On August 28, 2012 19:38:04 Phil Blundell wrote: > On Tue, 2012-08-28 at 14:20 -0400, Mark Asselstine wrote: > > + if [ "${hostname}" != "none" ]; then > > This magic string value seems a bit unwholesome. Can't you just check > against the empty string? The 'none' was suggested by a colleague and I just ran with it, but yes an empty string would work just fine and be less 'unwholesome' as you say. > > Also, if the problem is that the static hostname set here is overriding > the one from dhcp or the command line, I wonder whether this just > indicates that the priority of them is wrong and the scripting should be > adjusted so that the static file has lower priority than the other two > things. hostname.sh doesn't leave much room for priority ---snip--- if test -f /etc/hostname then hostname -F /etc/hostname fi ---snip--- looking at this you can see my logic, don't create the /etc/hostname file get rid of the overwrite. Mark > > p.
On 28 August 2012 19:53, Mark Asselstine <mark.asselstine@windriver.com> wrote: > hostname.sh doesn't leave much room for priority > > ---snip--- > if test -f /etc/hostname > then > hostname -F /etc/hostname > fi > ---snip--- > > looking at this you can see my logic, don't create the /etc/hostname file get > rid of the overwrite. But surely this should be running very early in the boot, and a DHCP-assigned name should be running afterwards? Ross
On August 28, 2012 20:16:30 Burton, Ross wrote: > On 28 August 2012 19:53, Mark Asselstine <mark.asselstine@windriver.com> wrote: > > hostname.sh doesn't leave much room for priority > > > > ---snip--- > > if test -f /etc/hostname > > then > > > > hostname -F /etc/hostname > > > > fi > > ---snip--- > > > > looking at this you can see my logic, don't create the /etc/hostname file > > get rid of the overwrite. > > But surely this should be running very early in the boot, and a > DHCP-assigned name should be running afterwards? That hasn't been what I have observed, and doesn't cover the command line case. If you have an NFS root this would also not be the case as init will be run after the network is setup and root mounted. Mark > > Ross
On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com> wrote: >> But surely this should be running very early in the boot, and a >> DHCP-assigned name should be running afterwards? > > That hasn't been what I have observed, and doesn't cover the command line > case. If you have an NFS root this would also not be the case as init will be > run after the network is setup and root mounted. There was an implied "and if this isn't the case, a bug should be filed". I hadn't thought about NFS-root though. Ross
On August 28, 2012 21:11:47 Burton, Ross wrote: > On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com> wrote: > >> But surely this should be running very early in the boot, and a > >> DHCP-assigned name should be running afterwards? > > > > That hasn't been what I have observed, and doesn't cover the command line > > case. If you have an NFS root this would also not be the case as init will > > be run after the network is setup and root mounted. > > There was an implied "and if this isn't the case, a bug should be > filed". I hadn't thought about NFS-root though. > > Ross Thanks for your thoughts on this. Is there anything else I can contribute here? Mark
On 8/30/12 12:20 PM, Mark Asselstine wrote: > On August 28, 2012 21:11:47 Burton, Ross wrote: >> On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com> > wrote: >>>> But surely this should be running very early in the boot, and a >>>> DHCP-assigned name should be running afterwards? >>> >>> That hasn't been what I have observed, and doesn't cover the command line >>> case. If you have an NFS root this would also not be the case as init will >>> be run after the network is setup and root mounted. >> >> There was an implied "and if this isn't the case, a bug should be >> filed". I hadn't thought about NFS-root though. >> >> Ross > > Thanks for your thoughts on this. > > Is there anything else I can contribute here? I found a bug with this patch. If you are building with the deb packaging then the conffiles is set to /etc/hostname, but the file may not always be created... this causes a failure condition when generating .deb packages. i.e.: -CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname" +CONFFILES_${PN} = "${sysconfdir}/fstab ${@['', '${sysconfdir}/hostname'][(d.getVar('hostname', True) != '')]}" > Mark > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
Patch
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb index 6bab040..dfcca78 100644 --- a/meta/recipes-core/base-files/base-files_3.0.14.bb +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb @@ -107,10 +107,12 @@ do_install () { } do_install_basefilesissue () { - if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then - echo ${MACHINE} > ${D}${sysconfdir}/hostname - else - echo ${hostname} > ${D}${sysconfdir}/hostname + if [ "${hostname}" != "none" ]; then + if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then + echo ${MACHINE} > ${D}${sysconfdir}/hostname + else + echo ${hostname} > ${D}${sysconfdir}/hostname + fi fi install -m 644 ${WORKDIR}/issue* ${D}${sysconfdir}
The existence of a /etc/hostname file causes any hostname provided on the kernel command line or via dhcp to be overwritten by the initscripts 'init.d/hostname.sh'. This change allows you to set a value of 'none' for 'hostname' which will skip the creation of the /etc/hostname file by the base-files package. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> --- V2: Koen Kooi didn't want to see the handling of the hostname variable changed so I removed those changes and just focused on the creation of the /etc/hostname file. Changes from V1: * patch renamed, was "base-files: allow for more flexibility related to hostname", * removed the rename of hostname to MACHINE_HOSTNAME * removed the addition made to meta/conf/local.conf.sample meta/recipes-core/base-files/base-files_3.0.14.bb | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)