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

Re: Recent changes to bootconfig.c

Dear List,

On Sun, Feb 06, 2000 at 12:51:27AM -0700, Randolph Chung wrote:
> Will respond in more detail tomorrow; meanwhile would you mind posting your
> two messages and my earlier reply to the list so others can collaborate and
> know what's going on? thanks!

Attached.

Regards,

Mark.
--- Begin Message --- 
Randolph,

I've looked through your changes for bootconfig.c rev 1.29 -> 1.30.
Unfortunately, I believe you have gone wrong on a few points.

In make_bootable():

1.  It is not safe to assume that the boot device defaults to the root!
    Consider root on hdb and lilo in an extended partition on hda.

2.  The 'problem earlier and user responded "no"' test should come after
    run_lilo(), or else the user won't have a lilo.conf to edit.
    You have also put it ahead of all the prompts at which the user
    might have responded "no"!

3.  Similarly, run_lilo() needs to be run *after* the boot device has
    been chosen, not before.

In run_lilo():

4.  You cannot write the boot= line unless the boot device is known
    (a consequence of 1. above) and ...

5.  Therefore you should generate lilo.conf, but not run lilo if boot
    is NULL.

6.  "Install lilo on master boot record" belongs in make_bootable(),
    where the boot device/partition selection is already handled for
    the case that root is a logical partitions.  Passing installed_mbr
    by address sort-of highlights this.  Probably the entire selection
    of boot device/partition belongs in a new function.

I really don't mean to be rude, but I have been working on this for some
time and it is difficult to get right.  I have several times declared in
debian-boot that I am working on this code and am annoyed that you have
made these changes that (a) break some of the things I did to improve
incorrect code and (b) make it impossible for me to continue in the path
I was going - without communicating with me first.

I hope I am not out of line here.  Unlike you, I am not an official
developer.  Still, I hope we can work together on this.

Regards,

Mark.

--- End Message ---
--- Begin Message --- 
Mark,

Thanks for looking over the code. You are not out of line at all, we need
people to audit each others work to make sure it works right :-)

I'm not sure I understand all your points though, so please bear with me for
a minute to explain this to me.

>     Consider root on hdb and lilo in an extended partition on hda.

I'm not sure what you mean here. How does this happen? i.e. what series of
steps might a user take in dbootstrap to cause this scenario?

> 2.  The 'problem earlier and user responded "no"' test should come after
>     run_lilo(), or else the user won't have a lilo.conf to edit.
>     You have also put it ahead of all the prompts at which the user
>     might have responded "no"!

well, considering i default boot to root->name, this should not happen. But
your point is taken. Please explain to me why #1 is bad so we know if it
needs to be changed back.

> I really don't mean to be rude, but I have been working on this for some
> time and it is difficult to get right.  I have several times declared in
> debian-boot that I am working on this code and am annoyed that you have
> made these changes that (a) break some of the things I did to improve
> incorrect code and (b) make it impossible for me to continue in the path
> I was going - without communicating with me first.

I made these changes in hope of addressing the mbr concerns. If you feel
that they make things worse, please feel free to revert to older cvs
versions and fix things from there. I have no problems with that at all. I
am still not sure about some of the problems you talked about though --
please understand that lilo can be installed many different ways, and the
goal of boot floppies is to let you make sure your system will boot, but not
to necessarily support all the ways you want to boot your machine (that's my
understanding anyway).

I'm glad you're helping us out with this. Let's talk about this some more
and see how we can work this out. We need to do this soon though.

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

--- End Message ---
--- Begin Message --- 
Hi Randolph,
> 
> Thanks for looking over the code. You are not out of line at all, we need
> people to audit each others work to make sure it works right :-)

Great.  Thanks.

> >     Consider root on hdb and lilo in an extended partition on hda.
> 
> I'm not sure what you mean here. How does this happen? i.e. what series of
> steps might a user take in dbootstrap to cause this scenario?

Install root on logical partition hdb5; unmount extended partition hda4.
When installing lilo, dselect complains about the logical partition and
asks the user to select an extended one, offering hda4 in the list.

I have done this several times with Slink.  I thought it odd that root had
to be in a logical partition and lilo on an extended partition, but now I
realise it was probably not an intended feature. I'd like to generalise
the code a little, so that the user has the option of installing lilo
(as well as the MBR) on the first drive when root is on the second.

> > 2.  The 'problem earlier and user responded "no"' test should come after
> >     run_lilo(), or else the user won't have a lilo.conf to edit.
> >     You have also put it ahead of all the prompts at which the user
> >     might have responded "no"!
> 
> well, considering i default boot to root->name, this should not happen. But
> your point is taken. Please explain to me why #1 is bad so we know if it
> needs to be changed back.

Previously, run_lilo() was called from several places in make_bootable(),
with its boot parameter depending on the install configuration and
user responses to problem-boxes.  The parameter was "" whenever the
configuration was likely to fall outside lilo's capabilities (leading to
a couple of BRs where people didn't pay attention to the "Please boot the
system using the rescue boot method and configure lilo manually" warning).

I introduced the 'boot' variable, giving NULL the meaning that the boot
device was unknown or unusable and therefore the boot= line should not
be written in lilo.conf, lilo should not be run and the user should
receive the "Please ... configure lilo manually" warning.

In retrospect, I suppose I should have made this clearer in the code.
A comment would have done wonders ...

I don't think lilo should even attempt to install where it can't possibly
work.  For example, when the root partition is on an non-MSDOS disk, or
perhaps the third or fifth IDE drive.  But I'd still like a reasonable
/etc/lilo.conf generated.  As mentioned above, I frequently install lilo
on a different drive than root and would be irritated by lilo installing
there successfully and then having the MBR on the boot disk unable to find
lilo.

> I made these changes in hope of addressing the mbr concerns. If you feel
> that they make things worse, please feel free to revert to older cvs
> versions and fix things from there. I have no problems with that at all. I
> am still not sure about some of the problems you talked about though --
> please understand that lilo can be installed many different ways, and the
> goal of boot floppies is to let you make sure your system will boot, but not
> to necessarily support all the ways you want to boot your machine (that's my
> understanding anyway).

I understand your mbr changes and agree with the approach.  I don't want
to revert to the previous revision totally, but I would like to reverse
a few of the changes to address the concerns I have already raised (plus
a few others I am still trying to dredge up out of my subconscious ;-).
I'll hack away a little and mail you a patch for your comments.

Certainly a balance between flexibility and complexity is required.
I think we need to be careful that we maintain the booting options from
Slink, though.  Anyone who needs anything too exotic should know enough
to switch to vt3 and run lilo from the command line.  Most of the people
I know who run Linux on their home systems bought a second disk to avoid
fiddling around with their W95 partitions, and it would be nice if boot
floppies could accommodate them.  I think we are still a little way short
of the flexibility/complexity sweet-spot and could gain quite a bit
through a series of small, incremental improvements.

> I'm glad you're helping us out with this. Let's talk about this some more
> and see how we can work this out. We need to do this soon though.

Agreed.  My timezone is 13 hours ahead of GMT.  I typically check my
email several times during morning, afternoon and evening.  I can meet
you on IRC from time to if you wish.  For good or bad, my work style tends
to be:

    Get all my ducks in a line before making a single move.
    Small, safe incremental changes towards an evolutionary goal.
    Decisions must have a rational basis.
    Design and Coding are intuitive processes.

And yes, I do realise they mostly contradict each other.  So perhaps we
could discuss often, work with small sets of localised changes, commit
often (one "topic" per commit).  Obviously, we must not hold each other
up too much.  

Regards,

Mark.

--- End Message ---
Reply to: