Hi! Christoph Egger wrote: > I've just created a jessie-kfreebsd VM image (qemu)[1] [...] Nice work! It's a nice, minimal, mostly clean image with everything needed to install more. I wonder if I can put this on a USB stick and use it like a live/rescue system!? > ( [...] after a grub-install > the ufsid of the root device seems changed (after reboot)). I'll try > and see if I can fix that. That's interesting; it might also be an issue for d-i, if we had tried to use ufsid there too. > Also if you can tell me what to not do wrong I can have a VBox / > VMWare image soon. The freebsd-utils initscript error is something already fixed in p-u, IIRC. GRUB2 is configured to use a serial console by default, which is really nice. Kernel messages don't go to the serial console, yet, but they should with the newer grub2 in p-u. /etc/default/grub has: GRUB_TERMINAL="serial gfxterm" although I forgot to implement gfxterm when I changed grub2. I'll need to fix that right away (or it'll be serial-only). In any case, the gfxterm is reportedly very slow in virtual machines, so I'd recommend using textmode for this image: GRUB_TERMINAL="serial console" And then, sysvinit complains of getty 'spawning too fast' on S0. vmdebootstrap has tried to enable a serial console but used the wrong device name in /etc/inittab -- ttyS0 should rather be cuau0. It also sets 115200 baud whereas GRUB2 and the local terminals use 38400? Should we try to enable networking by default? It is difficult to know what the interface will be called, but em0 is the default in Qemu, and likely vtnet0 on KVM, xn0 on Xen, not sure about VirtualBox. In /etc/network/interfaces could we perhaps add stanzas for each? e.g. # e1000 auto em0 iface em0 inet dhcp # KVM VirtIO auto vtnet0 iface vtnet0 inet dhcp # Xen PV auto xn0 iface xn0 inet dhcp (assuming ifupdown continues without error if they don't exist). I thought for a moment it would be nice to have sshd by default - but it wouldn't be possible to log in unless an administrator sets a password or sets up authorized_keys - so it's probably not worth it. We'd also have to make sure host keys are generated on boot, not hardcoded into the image. Should the root partition be a little bigger, so that there is free space already to do things? The xz-compressed raw image decompresses as a sparse file, so that wouldn't take up any more space on disk. Other VM images are likely compressed. So maybe 4GB, 8GB or more? I wonder why libboost-iostreams1.55.0 was installed? That library is over 2MB but nothing seems to depend on it. Maybe we should `find /var/lib/apt/lists -type f -delete`, since the Release file signature is only valid for 7 days, and those files take up 30MB in the image. There are some files in /var/log from image creation time, but only take up <300K, and might actually be useful to look it, so I would probably keep them. /etc/apt/sources.list should perhaps use a more generic mirror than fau.de. httpredir.debian.org should be best, though it does sometimes redirect to a mirror not having jessie-kfreebsd suite... (forgot all about this, we should talk to Raphael about it). p.s. not exactly relevant here, but the fau.de mirror supports HTTPS. Regards, -- Steven Chamberlain steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature