Re: new installation disks

[Loic Prylli <Loic.Prylli@ens-lyon.fr>]

Andreas U. Trottmann writes:
 > On Sat, Oct 31, 1998 at 08:33:53PM +0100, Loic Prylli wrote:
 > 
 > > So now there should be  a working installation set on 
 > > http://lhpca.univ-lyon1.fr
 > > (the intermediate one from 18 october was unusable)
 > 
 > I'm just halfway through installing (I stopped because obviously
 > ftp.debian.org is lacking the ncurses3.4-free packages). I got it to
 > work until now, but there were a couple of minor problems

I did something quite misleading, I first put a draft version on the
web server, and finally I got some more time to improve it, so I
updated the files the same day without changing the names. If you
download the files before my announcement on the lists, you propably
got the intermediate version. The first two problems you described are 
corrected in the current version.

 > 
 > * the root disk lacks /dev/ram0, so dinstall exits with "can't find root
 >   device" (or something like this) unless you mknod /dev/ram0 in the 
 >   second vc

Maybe there shoudl be a report against MAKEDEV, it creates /dev/ram1
to /dev/ram8 but not /dev/ram0. Anyway /dev/ram0 is now present on the 
root disk.

 > * the installation program looks for a file called base2_0.tgz, but the
 >   supplied file is called base2_1.tgz. Renaming it made it work.

I also changed it, I was also surprised by this one, because that
probably means, the i386 folks are not yet totally ready for 2.1.

 > * the base filesystem in base2_1.tgz lacks at least /dev/hdc* and
 >   /dev/hdd*. Because my /var is on the third IDE disk, the first real boot
 >   process didn't succeed. mknoding the required device files before 
 >   rebooting made it work.

This one is still present, I will correct it in the next version.

 > and finally (but perhaps not that important)
 > 
 > * the "year 2018 problem" is still present :)
 > 
 >   the rtc driver in the kernel detects the right epoch, and /proc/rtc is
 >   right, but during install, the kernel clock thinks it's 2018, and the
 >   /sbin/hwclock contained in base2_1.tgz is one of the "old" ones that
 >   access the hardware directly (and fail on certain architectures) rather
 >   than one of the "new" ones that uses /proc/rtc.

I cannot reproduce here, the date is correct when booting with SRM.
I guess, we need to forward the right hwclock to the util-linux
maintainer.

 >   When I'll get a functional Debian system again, I'll try to resolve this
 >   problem.
 > 


Thanks for these precisions,

Loic