On 08/28/2012 01:56 AM, Alkis Georgopoulos wrote: > For the LTSP use case, another possible workaround for post-12.10 releases: > * In the last stages of installation, copy the whole /target system to > /target/opt/ltsp/i386, > * Chroot to /target/opt/ltsp/i386 and install ltsp-client and ldm, > * Run /target/opt/ltsp/i386/usr/share/ltsp/cleanup to remove the user > account that was created, regenerate dbus machine id etc, > * Install ltsp-server to /target, > * And run /target/ltsp-update-image to generate a squashfs image in > /target/opt/ltsp/images/i386.img out of the fat chroot in > /target/opt/ltsp/i386.
You seem to be assuming that the Ubuntu desktop media will be containing LTSP which it won't. Even then, that wouldn't solve the RAID question as no media letting you setup RAID will contain LTSP if alternate is removed. Being able to re-use the squashfs/target as a bootable LTSP system is indeed quite nice and in some cases (Edubuntu i386) will help save a lot of space on the media, however it won't be helping with the RAID problem. > This changes the default LTSP chroot to one that supports fat+thin > clients (instead of only thins), but with the current trends that > require 3d acceleration on desktops, that's probably a good thing. > > And it only requires minimal network connectivity to generate the > chroot, or a couple of MB of packages in the installation media > (ltsp-server, ltsp-client, ldm). > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
