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
this.
> 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: