Re: 5.3-Beta7 diskless boot: it boots but has empty /var (on/dev/md1) !?

From: Rob <spamrefuse_at_yahoo.com>
Date: Mon, 18 Oct 2004 12:28:49 +0900
Rob wrote:
> Ryan Sommers wrote:
> 
>> Rob wrote:
>>
>>> However, on the diskless PC, /var is on a memory
>>> disk, but that directory is completely empty:
>>>
>>>   disklessPC# ls -a /var
>>>   .       ..      .snap
>>>
>>>   disklessPC# mount
>>>   192.168.123.254:/ on / (nfs, read-only)
>>>   devfs on /dev (devfs, local)
>>>   /dev/md0 on /etc (ufs, local, soft-updates)
>>>   procfs on /proc (procfs, local)
>>>   /dev/md1 on /var (ufs, local, soft-updates)
>>>   192.168.123.254:/usr on /usr (nfs, read-only)
>>>   192.168.123.254:/home on /home (nfs)
>>>   /dev/md2 on /tmp (ufs, local, soft-updates)
>>>
>>> This has serious consequences on the diskless PC.
>>> For example, sshd cannot start because /var/empty
>>> is not there. There is no information in /var/run,
>>> /var/log etc.
>>>
>>> Is something missing in the /etc/rc.d/initdiskless script,
>>> or have I forgotten something?
>>>
>>> Thanks,
>>> Rob.
>>
>>
>>
>> The /var memory disk needs to be populated with a base structure. This 
>> is handled in initdiskless by templates (see 
>> /etc/rc.d/initdiskless:285). You can either have them as 
>> subdirectories in your /conf/ or as dir.cpio.gz cpio'gzip archives 
>> that are then extracted.
> 
> 
> Great! Thank you. This works very well.
> 
> What I have done is putting only the directories in the var.cpio.gz,
> as follows:
>     find /var -type d | cpio -o > /conf/base/var.cpio
>     gzip /conf/base/var.cpio
> 
> to regenerate the directory tree for /var on the diskless PC, assuming
> that individual files will be created as the system boots.
> The latter is indeed the case with files like
>    /var/run/dmesg.boot
>    /var/run/sshd.pid
>    /var/run/syslog.pid
>    /var/run/syslogd.sockets
> and so forth.
> 
> However, /var/log/ is empty and remains empty !?!? Any idea why that is?
> I need to inspect files like /var/log/auth.log, /var/log/messages and
> so on. Why are these log files not generated?

Let me answer my own question:
The answer is in the man page of syslogd(8):

      For security reasons, syslogd will not append to log files that do not
      exist; therefore, they must be created manually before running syslogd.

The log files should be there with "chmod 600" owned by root.

Rob.
Received on Mon Oct 18 2004 - 01:28:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC