Bug#239810: rng-tools: Fails to start/install when no hardware RNG is present
Damyan Ivanov (at work)
Version: 1.0-3
Severity: normal
Setting up rng-tools (1.0-3) ...
Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device
inode not found)
/etc/init.d/rng-tools: Cannot find a hardware RNG device to use.
invoke-rc.d: initscript rng-tools, action "start" failed.
dpkg: error processing rng-tools (--configure):
subprocess post-installation script returned error exit status 1
I understand that without hardware RNG this package is probably
unusable, but why fail to *install* in such an ugly way?
Should if just warn that rng-tools init.d script fails to start the
daemon whithout further failure of the installation?
Thanks,
dam
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.4-dam.0
Locale: LANG=bg_BG.CP1251, LC_CTYPE=bg_BG.CP1251
Versions of packages rng-tools depends on:
ii devfsd 1.3.25-16 Daemon for the device filesystem
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii makedev 2.3.1-65 Creates device files in /dev
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Henrique de Moraes Holschuh
> Setting up rng-tools (1.0-3) ...
> Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device
> inode not found)
> /etc/init.d/rng-tools: Cannot find a hardware RNG device to use.
> invoke-rc.d: initscript rng-tools, action "start" failed.
> dpkg: error processing rng-tools (--configure):
> subprocess post-installation script returned error exit status 1
>
> I understand that without hardware RNG this package is probably
> unusable, but why fail to *install* in such an ugly way?
Are you using devfs or sysfs ?
> Should if just warn that rng-tools init.d script fails to start the
> daemon whithout further failure of the installation?
Tell that to the debhelper maintainer. The initscript will return a
failure, and that is non-negotiable. The debhelper code for initscripts
will abort the postinst script if that happens.
I could override it, but I consider this to be a debian-wide issue, and I
will go with what is the common behaviour set by debhelper. If it is wrong,
we have to fix it there (and thus fix most packages after they get
recompiled).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Damyan Ivanov
Henrique de Moraes Holschuh wrote:
> > I understand that without hardware RNG this package is probably
> > unusable, but why fail to *install* in such an ugly way?
>
> Are you using devfs or sysfs ?
Both, but I really don't have hardware RNG. I just want the package
installed in case I get some hardware RNG in the future...
> > Should if just warn that rng-tools init.d script fails to start the
> > daemon without further failure of the installation?
>
> Tell that to the debhelper maintainer. The initscript will return a
> failure, and that is non-negotiable.
Hmm. I looked into another hardware-dependant package - sensord. In its
init.d script there is no check whether the daemon starts successfully
at all. And if one has no sensors the init.d script just print whatever
the daemon complains and goes on.
Not that I like this behaviour either :-) I see that failing the
initscript on daemon startup failure is a good thing. But if only this
poses no failure for installing the package...
I am not sure maybe after all this is debhelper's fault. I am not debian
developer so I can't judge. If you consider this to be debhelper bug,
please reassign the bug to debhelper.
Thanks for your time,
dam
--
Damyan Ivanov Creditreform Bulgaria
div...@creditreform.bg http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993 fax: +359(2)920-0994
mobile: +359-88-856-6067 ICQ: 3028500 Y!M: dam3028500
Henrique de Moraes Holschuh
tags 239810 wontfix
retitle 239810 maintainer scripts abort if initscript fails (debhelper)
thanks
On Wed, 24 Mar 2004, Damyan Ivanov wrote:
> On Wed, 24 Mar 2004 12:05:08 -0300
> Henrique de Moraes Holschuh wrote:
>
> > > I understand that without hardware RNG this package is probably
> > > unusable, but why fail to *install* in such an ugly way?
> >
> > Are you using devfs or sysfs ?
>
> Both, but I really don't have hardware RNG. I just want the package
> installed in case I get some hardware RNG in the future...
That's why the package complained. Add a static link from /dev/null to
/dev/hwrandom, and the package will install (and promptly chug a lot of CPU
trying to get useful data out of /dev/null, I suppose). Stop the daemon,
remove the symlinks that activate it, and you will have it installed even if
that won't be useful to you right now.
> > > Should if just warn that rng-tools init.d script fails to start the
> > > daemon without further failure of the installation?
> >
> > Tell that to the debhelper maintainer. The initscript will return a
> > failure, and that is non-negotiable.
>
> Hmm. I looked into another hardware-dependant package - sensord. In its
> init.d script there is no check whether the daemon starts successfully
> at all. And if one has no sensors the init.d script just print whatever
> the daemon complains and goes on.
I hold my packages to a higher standard than that.
> Not that I like this behaviour either :-) I see that failing the
We agree on that, then :-)
> initscript on daemon startup failure is a good thing. But if only this
> poses no failure for installing the package...
>
> I am not sure maybe after all this is debhelper's fault. I am not debian
> developer so I can't judge. If you consider this to be debhelper bug,
> please reassign the bug to debhelper.
It is a general issue, that debhelper follows. If you have the energy to
pursue it, bring the issue up in debian-devel. If one gets consensus there
that maintainer scripts should not bomb because they could not
start/stop/restart a service, the debhelper maintainer will probably change
his packages, and all we will need to do is to recompile all packages using
debhelper and initscripts (ugh), and file bugs to others that use
initscripts but don't have the agreed-upon behaviour.
Until that happens, I will leave this bug open as wishlist+wontfix. I don't
have the energy or time to tack this issue in debian-devel right now.