[Netkit.users] Fwd: Upgrade filesystem

[Massimo Rimondini]

Dear Adrian,

ok, down with some clarifications :-)

Well so far so good. I tried the chroot method but that didn't work. The
> upgrade assumes you are really running all service,etc and dies half way
> because you cannot start of stop certain services (There where some more
> complications but i have no clue what exactly went wrong).


Yes, this is a known issue. If you use chroot, you are only replacing the
root of the filesystem, while processes are still started on the host. This
means that, when upgrading using chroot, every freshly installed package
will attempt to launch its own service on the host, thus even preventing you
from being able to unmount the filesystem image.
When building a filesystem image, we indeed use the chroot method, but also
temporarily install a fake start-stop-daemon command that induces Debian
install scripts in thinking that services have been started while they have
not. Other similar tweaks are applied, so that package installations
forcedly accomplish file operations only.

The upgrade-inside-vm way is of course easier. :-)


> So I booted a vm als mentioned in the FAQ and ran the upgrade again.
> Altought it fails the first time of you run it again the upgrade completes
> nicely.


Mmhh... this may be due to some conflict in Debian packages. Probably it is
not Netkit related.


> Unfortunatly is does break the  netkit filesysem (probably because of the
> new libc/glib library) It does boot but not without a significant amount of
> errors. I added the bootlog of a session to this email, it probably makes
> more sence to you then to me ;)
>

The errors you see are due to two overlapping phenomena:

   - newly installed packages fail to find proper configuration files, which
   can be partly due to defaults from old Netkit files not matching new package
   releases or simply to missing configurations for some packages;
   - virtual machines are attempting to start all the newly installed
   services at boot, which results in a bunch of out-of-memory (oom-killer)
   errors.

Overall, these issues can be overcome by reconfiguring startup time
services. This can be done by chrooting to the new Netkit filesystem and
using update-rcS.d to disable all but the essential services that are
required at boot time (the scripts that start these services are usually
located inside /etc/rc?.d).
You can find a list of the boot time services that we disable when building
the filesystem image in the files
fs-build/netkit-tweaks/disabled-servicesand
fs-build/netkit-tweaks/disabled-system-services
inside the filesystem package.


> I made a backup as adviced so no harm done :)


Good! :-)


> If its something that i can fix myself please let me know, I will try and
> upgrade again.  If I have some spare time I am going to try and  build my
> own filesystem (following the README ofcourse) but based on the new debian
> stable (lenny). Hopefully this gives me some insight on the inner works of
> netkit so I can go and try to debug the errors that popup after the upgrade.


Ok, I'm glad to hear you are willing to try. I should however warn you about
the fact that the procedure is not meant to work flawlessly on every
platform (it is mainly for development purposes), and several actions
requiring root privileges on the host are carried out during the filesystem
build.
This is just to say that it is strongly advised to read the documentation
before proceeding, to have a backup of important data on your host (this is
not a self-destruct procedure, but caution should definitely be applied),
and to be prepared to some debugging sessions (the filesystem build
procedure depends on a lot of tools and settings and it is not unlikely that
some of them are found out-of-place along the way).


>
>
> Regards,
>
> Adrian


Regards,
Massimo.
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090304/5da9a766/attachment.htm