On Wed, 2003-09-24 at 16:35, Jeremy Katz wrote:
> The updates.img is just an ext2 filesystem. I tend to keep mine floppy
> sized, but that's just out of habit. Basically 'dd if=/dev/zero
> of=/my/updates.img bs=1k count=1440 ; mke2fs -f /my/updates.img'. As
> far as directory structure, it's a flat directory of python files.
>
> Yep, just 'mount -o loop /my/updates.img /mnt/mntpt' and you can then
> write to the loopback image.
Yeah, I went on IRC at irc.freenode.net#fedora-devel and asked for
suggestions since I really wanted to try it out. Their answer was
pretty close to the same, but they were a little unsure. So I tried it
out and was just about to report that it was working--just to notice
that you had responded. *sigh* Well, I almost was able to save you
from emailing.
> If you're using the ISO images, just drop the updates.img in the same
> directory parallel to the ISO images. You drop them in RedHat/base/ of
> an exploded tree.
Ah, cool. I actually created a RedHat/base directory underneath the
directory with the iso images and dropped the updates.img file there (so
that my directory looks like:
1069 newren@amr:~$ ls iso/redhat-severn/
MD5SUM severn-i386-disc1.iso severn-i386-disc3.iso
RedHat/ severn-i386-disc2.iso
). But it'll be nice to not have to have the directories, just to keep
things compact.
> > Will do...that is, so long as I can verify that any patches I create
> > actually work--at least for me. :)
>
> Sounds good. Out of curiosity, what are you actually looking at? :)
Some other math grad students (and a prof.) have showed interest in
linux and thus I've been helping them install it on their laptops.
Walking them through the installation process pointed out to me a couple
quirks that caused newbies problems (or were just annoying) that really
ought to be fixed so that more people could comfortably complete a linux
installation. Here's those problems, or at least those that I remember
or wrote down (warning: I'm fairly verbose here):
When changing CDs, upon putting in the new CD and clicking the OK
button, nothing on the display (even the mouse pointer) changes for
about 15-20 seconds. This has caused each and every person to
think that the machine froze. I'm betting that if I hadn't been
there, they probably would have waited a minute or two anyway, and
then found that the installation was proceeding, but they still
would have been panicking for those 15-20 seconds. Since I was
there and could explain that it was no big deal, they only panicked
for about 3 seconds, but it still wasn't something that's nice to
put them through. This really ought to be a fairly easy fix too...
During installation of packages, several will show 100% installed and
yet nothing changes visually for several seconds. I know that this
is because the visual feedback is coming from rpm, and rpm only
gives feedback on the size of the installation and neglects pre-
and post-install scripts. While those times probably can't be
estimated, a simple change such as showing the package as being 98%
installed instead of 100% would be very helpful in providing the
cue to the user that the package really isn't quite done yet.
One or two other no/slow visual feedback cases similar to the above
ones
1024 cylinder warning. I'm not completely sure what to do about
this, since I know why it's there and don't know whether you want to
get rid of it. But this warning really is superfluous and
potentially de-railing for what I believe will be the vast majority
of installations. As it is, Red Hat doesn't install very
comfortably on machines with less than 128 MB RAM. So, are people
with hardware that still has the BIOS can't boot past the 1024th
cylinder problem really going to be installing the most recent
version of Red Hat? Perhaps a good compromise (if needed) would be
to include something in the warning about the fact that this only
applies to ancient machines (so that all those with reasonably
recent machines can simply ignore the problem without fretting).
Estimation of package installation time. As is well known, the Red
Hat installer is pretty awful at estimating time. Granted, it's
pretty hard if not impossible to get a decent estimator--however, I
think a fairly simple change will provide a reasonable
improvement. In fact, I just tested it out (my first change) and
while it's still far from perfect, I'm pretty satisfied that it's a
nice improvement over the old method. Since this email is already
long enough as it is, I'll send the info about it in a separate
email so that people can respond to it separately. And yes, I'll
be sure to file a bug in bugzilla with my patch too. :)
Elijah
