amd64 server installation has wrong default dhcpd.conf (s/i386/amd64/)

Bug #203954 reported by Martin Pitt
40
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ltsp (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

I just did a test LTSP mode install with the current Hardy amd64 alternate. The default /etc/dhcp3/dhcpd.conf had paths for i386, although the installation created an amd64 image (quite understandable, since we don't have i386 debs on the CD). A simple s/i386/amd64/ in that file was enough to get the thin client boot.

Tags: iso-testing

Related branches

Revision history for this message
Martin Pitt (pitti) wrote :

Just talked with Oliver, who confirmed.

Changed in ltsp:
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

My recommendation is to keep the file as a conffile, and make it Architecture: any instead, so that debian/rules can create the correct file for each architecture.

Revision history for this message
Martin Pitt (pitti) wrote :

Keep a placeholder in the source package's default file and do something like

  sed -i 's/_ARCH_/$DEB_BUILD_ARCHITECTURE/ debian/tmp/etc/ltsp/dhcpd.conf

Revision history for this message
Oliver Grawert (ogra) wrote :

as i said in our conversation back thzen, this breaks the CD install for users with amd64 server and clients we discussed that several times at several UDSes and teh conclusion was to not change it until we can actually build i386 chroots by default from an amd64 CD install (even though it sounds funny, we have a good bunch of users using 64bit capable clients on 64bit servers ... with teh ATOM based generation of clients this amount will raise)

Revision history for this message
Kees Cook (kees) wrote :

I saw this during my ISO testing as well.

Revision history for this message
Oliver Grawert (ogra) wrote :

a discussion will be held about a proper solution at UDS karmic, we need to find a way to not silently break upgrades of amd64 based servers (where people most likely use a i386 chroot and thus changed the file manually) and new installs from CD. the best solution here would be to:

a) detect if there is network connection at install time and offer the user to build a 386 chroot if possible (we cant include i386 packages on CD so a net connection is essential here)
b) modify or generate the first installed dhcpd.conf according to the actual client arch
c) do the right ucf magic to make sure this generated file is known to be good to avoid coffile prompts

Revision history for this message
Tarek Eldeeb (tarekeldeeb) wrote :

Confirmed on 9.10 RC

Revision history for this message
enedene (enedene) wrote :

The same thing for 10.04 beta.

Revision history for this message
Jeff Lane  (bladernr) wrote :

This is a bit silly... at the very least, why doesn't the d-i installer have just a little bit of logic and say, if I'm installing 64 bit, then install a dhcpd.conf file for 64bit thin clients...

I can understand the reasoning behind the idea of 64bit host/32bit clients, but I got no indication or information during install AT ALL that I needed to hack dhcpd.conf to make it work.

there needs to be SOMETHING, either in the way of documentation or using a newer PXE and install BOTH 32 and 64bit images for the thin clients to hit...

Changed in ltsp (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ltsp - 5.2.1-0ubuntu7

---------------
ltsp (5.2.1-0ubuntu7) lucid; urgency=low

  * Fix multi-NIC support in d-i plugin. (LP: #376933)
  * Fix wrong arch on non-i386 in dhcpd.conf (LP: #203954)
  * Add dependency on a plymouth theme so we have a splash.
 -- Stephane Graber <email address hidden> Sat, 10 Apr 2010 20:15:10 -0400

Changed in ltsp (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.