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

Re: Recent changes to bootconfig.c

>>>>> "Mark" == Mark van Walraven <markv@wave.co.nz> writes:

    Mark> On Sun, Feb 06, 2000 at 10:24:36PM -0800, Karl M. Hegbloom wrote:
    >> I created a new variable, Boot, that shadows Root unless you create a
    >> small partition and mount it as /boot, in which case that becomes
    >> Boot.  I think now that this might not always be the way folks will
    >> want to set it up...  Ideas?

    Mark> I think this is very good idea, if Adam allows it this close to release.
    Mark> In this case you would make set LILO's ROOT to the /boot partition and
    Mark> create a symlink /boot/vmlinuz -> ./vmlinuz-x.y.z?

 I will make a test branch in `dbootstrap'...

 I am not done with what I started yet.  (I'm supposed to be out
 looking for part time work all week, and might work a few days doing
 temp agency drudgery for grocery money... I wish I could get a paying
 Linux job.  I really hate going to work even part time for little
 more than minimum wage.  I'm sick of working as restaurant labor.
 Sick enough of it to go flat broke before I'll go do it.  So I won't
 have full time for boot-floppies...  unless I'm irresponsible and
 just work on this anyway.  I might.  I'll eat at the mission.)

    >> I've reorganized this stuff some, but not as much as perhaps it ought
    >> to be.

    Mark> Do please let us in on the details.  It would be wasteful to be working
    Mark> in different directions.

 It's still in transition.  I've laid off the trying to make changes
 for a while to study the code more thoroughly.  I need a better
 overview of it all.  I spent about 3 hours today on it...  (would have
 been 6 or 8 but I ran into some hassles today. Grrr.)

    >> Do you have patches to show us?  Do you have writes on CVS?

    Mark> I had some patches that won't work because libfdisk doesn't always do
    Mark> what I thought with disk names, so I abandoned them.  I have some ideas
    Mark> on how to fix libfdisk, but after spending a lot of time on several dead
    Mark> ends, I'm not sure I can guarantee it will work well enough in time for
    Mark> release, so ...

 I'm reading some of libfdisk right now... so far just where I've
 followed it from `dbootstrap' "main.c" and "main_menu.c" I'll also
 (like you are) try and see what it's doing and why the name slot is
 not set where the `it crashes here' marker is in `dbootstrap' that
 Joey H. wrote in.  Perhaps all we need is a guard against a NULL
 there or to initialize a variable someplace.

    Mark> I also have changes to bring Randolph's mbr work back into line with
    Mark> my boot selection stuff.  This is what I am working on currently - I
    Mark> will mail my current (unfinished) set tonight when I get home.


    Mark> It sounds like I am going too slowly for you.  If you can help me with
    Mark> some testing, I could go much faster (I spend far too much time making
    Mark> floppies on a slow machine and booting a even slower test system).
    Mark> I'm reluctant to commit anything without a lot of real testing after
    Mark> my recent Part->disk->name blunder, so perhaps you can help by trying
    Mark> patches for me.

 I'm not going very fast either.  I'm a turtle.  Perhaps the simplest
 thing for us to do would be to make a branch in CVS and work there
 for a while, so we can stay in sync.  We'll join that to the trunk
 when it's all squared away and running again.  Hopefully I won't
 starve before we get `potato' out the door. {8-{)>>

 I've created the branch.  Run `cvs update -r br_exp_karlheg_markv'
 after you `cd' to your dbootstrap directory to switch your working
 checkout over to it.  (It won't destroy your changes; it will only
 switch to the new branch tag.)  We should look over each other's
 changes as `cvs diff -u' patches before we make any commits, to avoid
 major conflicts and whatnot.  We'll have to decide what to do after
 we read each others patch.  Let's deal with that on the list, in case
 others have useful input.

 The `cvsweb' URL is:

 Hope the choice of branch tag is acceptable...  I've got something
 named after me now. :-)

 What kind of computer are you using, Mark?  I'm using `vmware' for
 testing.  It's running pretty well on an AMD-K6 233Mhz 128Mb RAM.  It
 is a little sluggish, but it works.  It's the neatest thing since

Reply to: