On Thu, Feb 09, 2012 at 10:25:45AM -0500, Dave Anderson wrote: > On Wed, 8 Feb 2012, Dave Anderson wrote: > >On Tue, 7 Feb 2012, Kenneth R Westerback wrote: > >>On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote: > >>> I've got a system running amd64/mp -current (latest source update on > >>> February 1st) and have noticed (for quite a while, actually) that the > >>> nightly backup of / to /altroot wasn't working. I finally got around to > >>> looking into this and discovered that the /etc/daily script was > >>> explicitly checking for /dev/whatever in the /altroot fstab entry -- but > >>> I've been using DUIDs (as set up by the installer). > >>> > >>> Shouldn't the daily script be updated to handle DUIDs as well as > >>> explicit devices in /etc/fstab? > >>> > >>> Dave > >> > >>Does this diff work for you? Test with duid and without would be > >>nice. :-) > >> > >>And don't be bashful. Anybody can test! > >> > >>.... Ken > > > >That works for me, both ways. > > > >Thanks, > > > > Dave > > Aaargh! Not quite, it turns out. This superficially appears to work, > and does seem to work in the non-DUID case, but I evidently didn't look > at the results carefully enough. In the DUID case, rather than copying > / to the altroot partition it copies it to /dev/r<duid>.<partition>! > > My bad. Apologies to all. > > I remember seeing a commit which sounds like it might tweak some > low-level functions to translate DUIDs into devices; I'll upgrade to a > current -current and see if this problem goes away.
I tried latest -current (from sources), and the same problem is there as well. I think this change should be reverted, because having a copy of root partition sitting as world readable in /dev is not cool: 08:35 je@iso:~$ ls -l /dev/rec6572ba6b33d733.a -rw-r--r-- 1 root wheel 143M Feb 10 08:23 /dev/rec6572ba6b33d733.a Juha
