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

Re: List of bugs that *must* be fixed before releasing Slink

On Wed, Feb 17, 1999 at 12:47:20PM +0100, Richard Braakman wrote:
> > Not a bad idea, not bad at all.  I would say it has some issues you have
> > left unresolved (like sysvinit) but I bet I think there are probably ways
> > around that too.
> Hmm... what about sysvinit?  (Is it possible for init to be broken in a
> way that can be fixed?)

static init would not break in the first place.

> > Seems to me we already have a method for building a similar purpose
> > system already, the base*.tgz is pretty much what you're suggesting.
> Yeah, I've used that a couple of times to create a ready-made chroot
> environment.
> The boot floppies also come with a rescue disk that might be useful.

Mostly what I would find most useful from resc1440.bin is the way it
boots the initrd which is not extremely well-documented elsewhere.  I'm
working on figuring out how to make an initrd find the appropriate rescue
filesystem for things like zip disks and the like.  Still working on

> You might want to look at "yard" as well (I think it's packaged in
> potato).  It's designed to create working boot floppies, given a list
> of programs you want on them.

I'll have a look in a day or two.  I'm learning how to do some stuff with
epic4 now that I just haven't tried before, the result should be seperate
epic4 and epic4-dbg packages, the former being built "normally" and the
latter being built in a debuggable manner, a request from upstream.  I've
never really tried to build a multi-deb package from scratch (or from a
single-deb rules file rather) and certainly not one which has two
seperately configured/built sets of binaries.

This was made easier by the use of autoconf--so I thought.  Turns out
that instructions for doing it with autoconf existed but didn't work with
epic4.  We fixed that and it does work now, but it's got me in a state
approaching insanity...  =>

Then I have a new mikmod to build which is going to require I redo that
package from scratch too so I can accomidate libmikmod.  Fortunately this
should be more straightforward.  I hope.

> > I suppose if done right it could serve as a source for bins/libs
> > that work together should things go wrong and you need to get into
> > single user mode, probably as a chroot environment known stable for
> > testing things,
> Hmm... chroot would be inconvenient if you want to fix your system,
> and it might not be necessary.  You can compile the binaries in 
> such a way that they will look in /any/path/lib/ld.so for their
> dynamic linker, and you can hack the linker and libc to use /any/path
> too.  (Don't ask me how, though :)

I was actually talking about it being chrootable for other purposes.  ie
this same package could serve more than one purpose.  As for playing with
ldso paths and stuff, I don't know how that will work out--I'm just going
to work on building a filesystem which is safe to use for rescue jobs and
a few methods for getting it booted including lilo and hopefully a floppy
with a kernel and initrd that "finds" the proper filesystem and mounts
it.  I'll figure out how to make a useful-to-most-people package out of
it later.

> Given that, the rescue system could be activated by simply running
> its shell; the shell could be hacked to put the rescue system at
> the top of its PATH.  Then you wouldn't need login facilities,
> which makes the whole thing safer.
> However, this might be too difficult to pull off, and if you go
> all the way then you might as well use chroot.  (Should the
> rescue system's name resolver use the rescue system's /etc?)
> (Probably not.)

As I said, chrootable was meant to be a side-effect, not a design goal.

> > probably also as a spare rescue partition (since it would work for
> > chroot) or zip disk for example, or even just a rescue fileset on your /
> > partition with the right parameters to lilo...
> Well if you want to use it to repair systems without rebooting, then
> putting it on the root filesystem would be best.  Utilities like
> mount might be broken :-)
> We already have facilities for base systems and rescue disks.
> Putting them in a package that works at run time is the New Thing :)

Once I have a working way to build a "rescue zip disk" which is more
normal than a rescue floppy disk and can be booted either from the zip
drive if your hardware supports it or piggybacked off a generic floppy
made for the job, I'll see about making the rest work.

Anticipation is the sweetest form of torture...

Reply to: