[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Install report (2003-04-30)



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello again everyone!

I'm back with another installation report; and this one can finally be
called an installation since I managed to get all the way through <the
crowd goes wild!>.

I did this install using a PXE boot of the daily snapshot from today
(2003-04-30).  Although I was able to get a working install, I ran into a
number of issues.  Here's the list:

0) debootstrap now works!  WooHoo!!!  In celebration, I'm bcc-ing
{189058,189311}-done@bugs.debian.org.  Many thanks to everyone who helped
with this!

1) Ethdetect still attempted to load the eepro100 module for my network
card instead of e100 (see bug #189054).  I checked, and it seems that
version 0.23 of ethdetect was used in the daily image, not 0.25 (the
latest) which has a fix for this.  Upon investigation, it seems that the
daily build has been failing since April 19...Tollef??

2) mkswap wasn't found which caused much evil :-(  I worked around this by
not declaring any swap partitions, so it wasn't attempted.  I guess this
is because we are back to using busybox (1:0.60.5-2) instead of
busybox-cvs; Is this intentional?  Should I file another bug against
busybox?  against anna (?) for not using -cvs?  Add confirmation to bug
#183597?  Ignore it because busybox-cvs will (soon) be the default?

3) Bug #186443 is still alive and ticking since /target/etc/fstab is still
not being generated after the partitions are mounted.  I will do some more
detective work to see if I can nail this down.  Something still doesn't
make sense to me...  Can anyone confirm that it is partconf.postinst that
should be running /usr/lib/prebaseconfig.d/40fstab?

4) When I told lilo-installer (0.0.11) to install lilo into the new root
partition (call me old fashioned, but I don't like overwriting my MBR when
dual-booting), it didn't prompt me to set that partition as active for the
reboot/base-config.  I checked/fixed this before rebooting during my
install, otherwise this would have left me in a bad state and I'd have to
re-install.  I think that if lilo is installed anywhere except the MBR,
there should be a prompt offering to do this for the user (defaulting to
yes).  Agree/Disagree?  This situation/argument would be equally
applicable to grub-installer, I suppose.  After examination, I see that
this is listed in the TODO for lilo-installer with a possible solution; I
will file a bug and see if I can send in a patch to implement this as
well.

5) After the reboot, the console had some problems.  First of all,
lilo-installer decided to set ttyS0 as the console -- without so much as a
message to that effect.  Luckily, I had the necessary cable so that I
could continue base-config via minicom, but this was definately a rude
suprise.  After examination, I see this happened b/c my PXE server sends
two console options to the kernel when booting -- one for the serial port
and one for vc0.  Since vc0 is last, that is the one used by linux, but
lilo-installer only checks if the serial is defined -- not if it is the
default.  There seems to be an easy patch for this, which I will send in a
bug report against lilo-installer.

6) Also, if we are going under the assumption that there is a serial
console, why isn't a login prompt generated on the serial port after
base-config finishes?  As it worked out, no getty was run on the serial
port, instead vc0 got a login prompt and console messages were still sent
to the serial port!  Should I file a bug against base-config or does some
other package handle setting up /etc/inittab (dpkg -S couldn't tell me)?

7) Another thing, after reboot the network was unavailable since the
proper module (e100) for eth0 wasn't loaded.  Perhaps the reboot step
should get the output of lsmod and append it to /target/etc/modules,
before rebooting.  Note hw-detect-full cannot do this (as would be
logical) since /target isn't created/mounted at that point.  File a bug?
Against which package?

8) I don't know if this is d-i related, but after I did a modprobe e100 to
correct the above (#7), ifup eth0 (?) wasn't run properly and failed to
properly configure the network.  I ended up doing ifdown eth0; ifup eth0;
which fixed it.  Any ideas what caused this?  Where should I file a bug?

Overall, I'd say d-i seems to be inching towards what I would consider
beta status.  Then again, I'm only using it on i386; I'm sure the other
ports are in worse shape (unfortunately, all I have is i386 to test on).

Anyways, I hope all this helps.  Thanks again for all your efforts!

Joe Nahmias, DD wannabe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sJXmKl23+OYWEqURAncYAJ9Vim6WUjGISiE4HFQMNm7GvtZ34QCgqwvb
V396Em1kirZfPYv2lw8b/14=
=xDVn
-----END PGP SIGNATURE-----



Reply to: