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

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



Joseph Carter 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?)

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

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 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 :)

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.)

> 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 :)

Richard Braakman


Reply to: