Re: 2.2.8 release?
I'm mailing the draft... tired of editting. Need a break. Said enough.
>>>>> "David" == David Huggins-Daines <dhuggins@linuxcare.com> writes:
David> karlheg@bittersweet.inetarena.com (Karl M. Hegbloom) writes:
>> >>>>> "David" == David Huggins-Daines <dhuggins@linuxcare.com> writes:
David> I have a couple of minor things to fix for Alpha (i386-isms introduced
David> by the merge of the karlheg_br_markv_whatever branch, some
>>
>> What did I break, just out of curiosity?
David> The dbootstrap Makefile had some problems, which cost me lots of time
David> since it led to root.bin being unnecessarily rebuilt every time I ran
David> "make" in the toplevel directory. Also your 'unmount' target was
David> broken (only one $ on a shell variable - the scourge of Makefile
David> writing :), as was the dbootstrap/po Makefile. And the libfdisk
David> Makefile's dependency checking was slightly broken (it made rules of
David> the form 'testing: testing.c' instead of '.depend/testing: testing.c')
Hmmm, Ok, Thanks. Live and learn. I'll try and remember to double
the dollars and will be more carefull to double check the contents of
the dependancy files. What was causing root.bin to be rebuilt? I
must have dropped a dependancy or something that was in the original
makefile? Or is it just that there's a separate `root.bin' for each
kernel flavor due to the fact that it must contain some modules?
(unix.o, af_packet.o for the standard i386 kernel image)
David> The .translation/ stuff in the dbootstrap makefile is pretty nice
David> though, much better than the old '.tmp.foo.c' cruft. Good work (even
David> if I think your Makefiles are somewhat needlessly complex :)
I don't think they're all that complex... I like to use target local
variables and to add dependancies in more than one place, to "fold"
as much as possible into common blocks of `make' code and eliminate
the use of recursive make. I'm just learning to write Makefiles.
<URL:http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html>
GNU Make is really neat. I've begun a rewrite of the `boot-floppies'
build on `br_woody_exp'... (which I need to put down and just dig
into kludging the release.sh script into putting things where the
Makefile ought to have put them to begin with... for Potato, along
with the changes to `dbootstrap' &c that make it look in the right
place for things now that the archive is going to be rearranged
some.... and I need to do that by early this week... I have just
enough money right now to pay part of my bills (less than half, and
none for the student loan that I just got out of default <sigh> I
think I'll just rip it up and "self" educate. So much for the CS
degree I wanted to try and get.) and all of my rent this month (that
is first priority. I'm tired of backpacking.). I HAVE to look for
part time work SOON. I have to start no later than Tuesday... I
need at least another $200 this month to cover all of my obligations.
(Anybody gets the urge to mail me a check or some parts, I won't stop
you. Wish I was on someone's payroll... I'm inexpensive. $300 more
a month would cover me right now.) I'd rather work on this Debian
stuff than go flip hamburgers or wait tables part time. 5 chickens
in the freezer though... found it at $.59/Lb. I won't go hungry.)
David> There was only one i386-ism I spotted actually - the message about
David> LILO and the 1024 cylinder limit. There is no LILO on any other
David> architecture nor is there a 1024-cylinder limit (in fact, CHS disk
David> geometry in general, which we all know is fake anyway these days, is
David> irrelevant to machines without DOS-brain-damaged firmware)
Will you guard it with #if #cpu(...) please? If you want any message
there for your arch, just do it. I have no idea what anything but
i386 is like.
I had some trouble with the computer I just installed... I configured
the drive via the BIOS to use LBA. Linux installed fine, ran fine,
and rebooted several times, then all of a sudden quit working... I
had one kernel installed, LILO in the MBR, and had the `optional'
keyword in the second image's block in lilo.conf (the new default
lilo.conf that dbootstrap writes). I made a symlink (don't know what
made me do it.) /boot/vmlinuz.old -> /boot/vmlinuz-2.2.14 that is
normally not there, and ran `lilo'. (I don't know if this is what
caused it... or where the error occurs... is it Lilo, or a Linux
kernel bug???? This is an important question.) When I rebooted, it
failed to find a superblock on the root partition after booting the
kernel... It was looking in the wrong place on the disk for the
start of a filesystem.
I futzed around for an hour, and finally tried `gpart'. It guessed
the second partition as the first one, and the third partition as the
second one, with the last two blank. I don't know if the numbers it
gave for start and end cylinder of the partitions it guessed where
the same as what cfdisk wrote when I first partitioned the drive.
They looked credible enough though... but the first partition was not
listed, and the second partition was listed by `gpart' as being the
first. Why? (I'd made a 10Mb hda1 "/boot", a 64Mb hda2 "swap", and
the rest hda3 "/".)
I think there's something wrong with LBA translation... the `grub'
manual says something about how there is more than one way to
calculate CHS translations, &c. I think there's a discrepancy
between the way that Lilo/Linux(?) calculated and the way this '94
(?) bios calculated it.
I wanted to use `gpart' to fix the partition table, since I'd already
installed and done a few hours of setup work... for a client. It
didn't guess right though, and I don't know if `gpart' is broken or
if the disk was scrogged, or what.
I ran `cfdisk' finally, and chose the same sizes as before, then
wrote the partition table. On vt2, I was able to mount /dev/hda1,
and read the directory on it. It looked like all the files where
still intact. This is the partition that `gpart' didn't divine the
existance of. I was ecstatic, thinking I'd recovered my work... so
I rebooted. It didn't work, of course... (in retrospect I see that
I could have also seenq whether files in /boot could be read, not
just the dir `ls'... though if I could `ls' I could probably `cat'.)
The lilo MBR found the kernel fine and booted it, of course. That
kernel could not find a valid superblock where it expected one for
it's "/", on /dev/hda3. The partition table did not point to
someplace where `mke2fs' had been run. I'd reconfigured the BIOS
prior to repartitioning so that it used CHS (Normal)... so it could
find the first partition, at the start of the disk, but the
calculations for where the boundaries between partitions are was not
the same as the first time I partitioned it, under LBA geometry.
I wound up reinstalling everything. Wish I'd have saved a `dpkg
--get-selections' and a tarball of /etc and /root. The warning about
creating a backup before continuing with the installation is no joke.
I am very concerned that there may be major problems for people who
are using LBA translation. When you buy a new harddrive anymore, it
says to "choose LBA" on the drive packageing. Most (?) windows users
who will want to dual-boot will have things set for LBA.
Does anyone else have much experience installing machines and have
any experience with / knowledge of LBA vs CHS translation (Large) and
CHS normal?
I did not have time to experiment with the box very long, or I would
have tried a few things to see if I can reproduce this. As I said
earlier, I'm some EDO RAM and a Pentium CPU away from having another
machine to build for testing.
David> <gripe>
David> Actually it looks like that message may have already been
David> there, just only in the "verbose" mode. For the record, this whole
David> verbose/non-verbose flag thing is pretty confusing, I don't want
David> dbootstrap to hide anything from me or have to specify special
David> undocumented (please don't say they're documented in the syslinux boot
David> screen - this is only on i386) boot parameters to get it to do what I
David> want. But maybe I didn't follow the rationale behind it. IMHO
David> dbootstrap fails to be sufficiently self-documenting and this is one
David> of the reasons people have trouble installing Debian.
David> </gripe>
Why don't we rip out the `verbose' cruftaroni then? And in the
process, perhaps make the `debug' thing work a little better. Not
everything supports it. `modconf' ought to have `debug' support in
it, perhaps. It could be in the envrironment easily enough.
One thing at a time. We ought to get it squared away and ready for a
useable release this week or so --- Isn't that the when of it?
Reply to: