Dave Miner wrote: > Jan Damborsky wrote: >> David.Comay at Sun.COM wrote: >>>> 8427 AI doesn't set dump device to ZVOL on installed system >>>> >>>> webrev: >>>> http://cr.opensolaris.org/~dambi/bug-8427 >>> Jan, is there a reason you're directly writing /etc/dumpadm.conf (a >>> project private implementation, I believe) rather using dumpadm(1M)? >> >> >> Hi David, >> >> I agree with you that if possible we should avoid this. I have tried to >> manipulate /a/etc/dumpadm.conf on just installed system (before reboot) >> using dumpadm(1M), but it doesn't seem to work, since /a/dev/dump is not >> available at this point: >> >> # dumpadm -r /a -d /dev/zvol/dsk/rpool/dump >> dumpadm: failed to open /dev/dump: No such file or directory >> >> # ls -lL /a/dev/dump >> ls: cannot access /a/dev/dump: No such file or directory >> >> I am not sure if access to /a/dev/dump is really needed for setting >> options in /a/etc/dumpadm.conf - should I file bug against dumpadm(1M), >> so that we could switch to using dumpadm(1M) in future ? >> > > The problem with dumpadm -r was noted in the comments in that function > already; I thought we had filed a bug but perhaps not since we didn't > note that we were working around a specific number (which is the one > case where using a bug number in a comment is a good idea). Please > file one if it hasn't been done.
Hi Dave, I have gone through existing Bugster bugs in solaris/utility/kernel category and haven't found one related to this issue, so I have filed 6835106 'dumpadm(1M) -r' doesn't work for the installer for customizing /etc/dumpadm.conf on target system I have also modified comment in ict.py to reference bug CR (the webrev has been updated accordingly). Going through that bug list, it seems that following are perhaps related to the installer, not dumpadm(1M) itself: 6495575 /var/crash/`uname -n` not helpful default in some cases 6755559 OpenSolaris snv_98 does not create /var/crash/$NODENAME$ I would like to ask in general what we should do with the issues we realize are related to the installer, but currently reported against different bug category ? Should we contact people who are currently in charge and work on moving those issues to the appropriate installer category ? Thanks a lot for the comments ! Jan
