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.
Ok.
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:
<URL:http://cvs.debian.org/boot-floppies/utilities/dbootstrap/?only_with_tag=br_exp_karlheg_markv>
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
`screen'.
Reply to: