Re: Updates to ash and busybox
Massimo Dal Zotto <dz@cs.unitn.it> writes:
> > > > you how many times I've wish chroot was on the recue disk... You know,
> > > > chroot could even be used for a reboot-free install -- just chroot to
> > > > the newly installed partition...
> > >
> > > Amazing convergance! We were recently talking about having init have
> > > the ability to exec/chroot? If we had this, we could conceivably have
> > > a "bootless installation" -- once you've installed the base system,
> > > you could just chroot your init over to the target system, and keep
> > > chugging...
> >
> > This sounds like a good idea in principle, but it leads to a nasty problem.
> > If you do this, you might use the newly installed system for days,
> > configuring it, puttling lots of effort into it, and getting attached to it.
> >
> > And then you eventually reboot. And discover the install actually failed
> > somehow and you can't boot of the hard disk at all. When I was looking at
> > the Caldera install (which does this), I ran into this exact problem, and
> > it's the kind of thing that would give a user (especially a new user who
> > doesn't know how to correct it) a _very_ bad impression of debian.
> >
> > It's great as an option. It's horrid as a default.
Even as an option I think its worth implementing. Its realy usefull
for a rescue system and for installation the user can be told that he
should do a full reboot to test the lilo or bootdisk.
Also if the reboot fails later, he can allways boot with the rescue
disk and the continue booting the real system. No need to type
"root=xxx" on a US keyboard layout, where = and / are somewhere in the
mist. Any non US newby will have a hard time typing those.
One could lable the option "boot real system/demo system" or similar
without making it the default and tell the advanced used that they can
boot their freshly installed system with this ithout reboot.
Another point to mention is that normal new users will eigther turn of
their compuert frequently or know how to get a broken lilo working
since they are admins. A newby will not install a production maschine
and let it run for a year on his first linux installation.
> I've been using this trick from more than one year and it works very well.
> I have also illustrated the chroot solution in my proposal of Jul 10 1999
> to this list about the debian automatic installation, but apparently nobody
> noticed it.
chroot works differently and has noticeable effects on the chroot
running system:
Just an example:
$ mount root.bin.ungziped /floppy -oloop
$ chroot /floppy /bn/ash
$ mount -t proc proc /mnt
$ cat /mnt/mounts
/dev/root / ext2 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/hda8 /var ext2 rw 0 0
/dev/hda9 /home ext2 rw 0 0
/dev/hda10 /usr ext2 rw 0 0
/dev/hda11 /usr/local ext2 rw 0 0
/dev/loop0 /floppy/ ext2 rw 0 0
proc /mnt proc rw 0 0
Huh? Where do they all come from? Lets unmount those during shutdown.
You will have a nice time when /etc/mtab links to /proc/mounts and in
the reverse if it doesn´t you also will have a nice time.
Also in another xterm (outside the chroot) at the same time:
# cat /proc/mounts
/dev/root / ext2 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/hda8 /var ext2 rw 0 0
/dev/hda9 /home ext2 rw 0 0
/dev/hda10 /usr ext2 rw 0 0
/dev/hda11 /usr/local ext2 rw 0 0
/dev/loop0 /floppy/ ext2 rw 0 0
proc /mnt proc rw 0 0
So if anything in the chroot mounts something and forgets to unmount
it you have big trouble coming along.
Maybe the proc fs should be chroot aware.
Also last time I run the bootdisks in a chroot I think they didn´t
work but I have to test that with a working current version and maybe
write fixes so it runs in chroot.
May the Source be with you.
Goswin
Reply to: