Re: potato install-items
Kerstin Hoef-Emden <Kerstin.Hoef-Emden@Uni-Koeln.DE> writes:
> does it have any bad effects, if the install procedure "thinks" that it
> is year 2020? Under the freshly installed potato system the year is set
Configuring the network with DHCP won't work ... at least, this is
what I've seen in the case where the system clock gets set to 2048 or
2052 (only two of the countless hwclock failure modes on SRM - someone
really should fix hwclock)
> correctly to 2000, just that already heavily discussed time thing
> strikes: My computer is 2 hours early. Since I "trained" the Debian
> install with slink base first, before installing potato, I´ve seen the
> same phenomenon during install of slink (year 2020).
Yeah. See, the deal is, the three "native" operating systems on the
Alpha (conveniently ignoring the fact that Linux is more or less the
only operating system on some alphas these days :) all have wildly
different ideas about how to store the year in their NVRAM, namely:
OpenVMS (SRM console): year - 1900
Tru64 (SRM console): year - 1952 (or 1956 on some
old revisions of SRM?)
Windows NT (ARC console): year - 1980
Linux tries to accomodate all three (though it prefers to use the ARC
console epoch, and doesn't take well to the OpenVMS one). One might
even consider this a y2k bug, since the buggy hwclock code would still
do the right thing in the 1900s.
> Besides that, I ran into a loop when installing potato (on an LX164,
> AlphaBIOS 5.66). It stayed stuck at the part "installing system and
> kernel modules" (Cannot recall the exact words right now). At first, I
> thought, that it was caused by an error in drivers.tgz, since that
> message showed up. To overcome this I switched to floppies with
> driver1.bin and driver2.bin, this time without error message, but it
> still did not change to the next item of the install procedure. Finally,
Ah. It sounds like you're using an old version of the boot-floppies.
As far as I know both of these bugs are fixed (at least, it works for
me (tm) :)
Specifically the problem with it not changing to the next item of the
install procedure was because the script on the rescue disk that
installs the kernel was installing the kernel uncompressed as
/boot/vmlinux, but the installer program was looking for /boot/vmlinuz
as an indicator that installing the kernel had succeeded.
> Is this behaviour of the install procedure a bug which still needs to be
> fixed or did something go wrong with my specific install on my computer?
I'm hoping for the former.
--
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Reply to: