The directories /var/db and /var/empty on the PPC livecd are symlinks to ../var/iso/db and ../var/iso/empty, respectively. This causes a problem if you boot from the livecd and attempt to start sshd to perform the installation remotely. Shouldn't these be normal directories and not symlinks? It looks as if the livecd developer was using them for testing and they were included accidentally. Reproducible: Always Steps to Reproduce: 1. boot ppc livecd (allstages) 2. try /etc/init.d/sshd (or start sshd by hand) 3. get error about not being able to create files in /var/empty Expected Results: /var/db and /var/empty should be normal directories.
imho this bug is invalid; I took the latest 1.4_final livecd (which still has /var/db and /var/empty linked to /mnt/iso/var/db and /mnt/iso/var/empty. A livecd consists of a read-only part and a writeable part. It works like this: - a bootloader loads the kernel on the cd - the kernel loads the initrd (small linux environment) - the initrd contains a script that gets started by default (/linuxrc) - the linuxrc creates a ramdisk, mounts the live environment (a compressed loop filesystem) - the linuxrc copies the parts that need to be writeable to the ramdisk, the other things get symlinked - the linuxrc starts chroots and pivot_roots to the ramdisk and starts its INIT - the live environment on the ramdisk gets booted /mnt/iso on the ramdisk is the compressed loop environment (read-only). So symlinks to /mnt/iso cannot be bad unless /mnt/iso isn't mounted. It is possible for a directory to be writeable, but only be readable. I tried reproducing the ssh problem you described by starting the ssh daemon on the 1.4_final cd. I saw no complaints. It is possible that you might get an error on the first kde or gnome livecds because those are build using the 'testing' tree. So it could be possible that openssh (from testing) on rc7 was broken at the time I build this livecd. Again, on the newest 1.4_final kde/gnomecd (against stable now) this problem doesn't exist. The 1.4_final cd will be available on the mirrors today or early tomorrow and can be ordered from the gentoo store. I investigated if my choice to make /var/empty and /var/db read-only were correct. According to the openssh manual /var/empty is a directory that needs to remain empty on purpose. The directory is used as a homedirectory for system accounts (typically the ones that have prefered prompt set to /dev/zero). So unless you want to give system accounts access to some file (I don't see a reason for that), or unless I'm missing something obvious (like mounting filesystems over ssh needs to put files in /var/empty or so) the directory will stay symlinked to /mnt/iso. If you insist on making this directory writeable, I can do so, but right now I see no obvious reason (esp. since on 1.4_final everything works as expected) /var/db is a directory in which file-based db's get stored. The only obvious application I know that has to write to /var/db is portage itself. But since trying to emerge something on the livecd would fail because there is no portage tree and some crucial parts of the filesystem are symlinked from a read-only loop mounted compressed filesystem. Again I see no obvious reason why this directory needs to be writeable, but if you can give me such a reason (I might be missing something) I can make it writeable in no time. (Note: I'm writing this bug report logged in to the 1.4_final livecd via ssh) Since you have root acces to the livecd, making the /var/empty and /var/db directories writeable is a piece of cake: rm -rf /var/db rm -rf /var/empty mkdir -p /var/db mkdir -p /var/empty chmod 755 /var/empty chmod 755 /var/db That should solve the problem for now. Please reopen this bug if you want me to make them writeable by default for the next livecd series. Pieter
