On Du, 16 mar 14, 14:04:12, John Magolske wrote:
>
> The issue was that ifupdown was pinned to 0.7.44 :
...
> Taking a look in /etc/apt/preferences I saw this:
>
> Explanation: Pinned by apt-listbugs at Sat Nov 09 17:32:44 -0800 2013
> Explanation: #727073: ifupdown: current version som
* Andrei POPESCU [140316 13:12]:
> On Du, 16 mar 14, 10:16:26, John Magolske wrote:
> > For several weeks now when I do `aptitude dist-upgrade` there is:
> >
> > The following packages have unmet dependencies:
> > initscripts : Breaks: ifupdown (< 0
On Du, 16 mar 14, 10:16:26, John Magolske wrote:
> Hi,
>
> For several weeks now when I do `aptitude dist-upgrade` there is:
>
> The following packages have unmet dependencies:
> initscripts : Breaks: ifupdown (< 0.7.46) but 0.7.44 is installed.
> [...]
>
On Sun 16 Mar 2014 at 10:16:26 -0700, John Magolske wrote:
> For several weeks now when I do `aptitude dist-upgrade` there is:
>
> The following packages have unmet dependencies:
> initscripts : Breaks: ifupdown (< 0.7.46) but 0.7.44 is installed.
> [...]
&
On Sun, 2014-03-16 at 10:16 -0700, John Magolske wrote:
> Hi,
>
> For several weeks now when I do `aptitude dist-upgrade` there is:
>
> The following packages have unmet dependencies:
> initscripts : Breaks: ifupdown (< 0.7.46) but 0.7.44 is installed.
> [
Hi,
For several weeks now when I do `aptitude dist-upgrade` there is:
The following packages have unmet dependencies:
initscripts : Breaks: ifupdown (< 0.7.46) but 0.7.44 is installed.
[...]
The following actions will resolve these dependencies:
Remove the follow
On Mon, Apr 22, 2013 at 07:51:42PM +0100, Jonathan Dowland wrote:
> On Sun, Apr 21, 2013 at 12:31:25AM +0100, Kevin Chadwick wrote:
> > Jonathan Dowland wrote:
> > > If you were a faithful follower of Kernighan UNIX philosophy, you
> > > wouldn't touch those nasty BSDs with a bargepole.
> >
> > R
On Sun, Apr 21, 2013 at 12:31:25AM +0100, Kevin Chadwick wrote:
> > On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> > > And that's a Linux problem where some BSDs put lots of effort into
> > > compliance only to have the standard changed to suit linux due to
> > > pressure.
> >
>
> On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> > And that's a Linux problem where some BSDs put lots of effort into
> > compliance only to have the standard changed to suit linux due to
> > pressure.
>
> Which standard, POSIX?
http://www.itwire.com/business-it-news/open-sourc
Hello Roger,
Excerpt from myself:
-- --
> insserv clearly complains instead that other services are affected by this
> change. Generally to a admin insserv seems to be nicer API over update-rc.d to
> me. Apart from that, by this i found a major bug in rc-update(). Will fix
> that.
i have que
On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> And that's a Linux problem where some BSDs put lots of effort into
> compliance only to have the standard changed to suit linux due to
> pressure.
Which standard, POSIX?
> POSIX is a very good thing. Do you disagree? I could perhap
On Wed, Apr 17, 2013 at 09:52:04PM +0100, Kevin Chadwick wrote:
> And did it boot slower than with init scripts and waste valuable
> memory. Lookup systemd on the buildroot list and you will see. Debian
> may run on even a cheap toaster one day but systemd would causes issues
> when that is possibl
Hello
Excerpt from Roger Leigh:
-- --
> update-rc.d foo disable|enable
>
> is one method.
-- --
i did played further around with this. First have a look at this:
# find /etc/rc[S0-6].d/ -iname '*mountkernfs.sh*'
/etc/rcS.d/S01mountkernfs.sh
# update-rc.d mountkernfs.sh disable
update-rc.
Hello Roger
Excerpt from Roger Leigh:
-- --
>> Yes, the man page says it swaps the S for a K.
>> e.g. say we have the following link:
>> /etc/rc2.d/K10cups
>>
>> Then afaik - and please correct if i am wrong - init will call the stop part
>> of
>> this initscript when ever runlevel 2 is entere
On Wed, Apr 17, 2013 at 08:55:42PM +0200, Thilo Six wrote:
> Hello Roger
>
>
> Excerpt from Roger Leigh:
>
> >>> update-rc.d foo disable|enable
>
> -- --
> >> It might be a nuisance but running the stop part of the initscript isn't
> >> the
> >> same as not touching it all?
> >
> > Sorry, I
people misunderstand the goals and design of the
> POSIX standards. The entire set is largely geared for source
> compatibility between Unix-like systems. I challenge you to find
> anywhere in the POSIX standards that defines anythign about the init
> system or system manager.
>
> > I believe very strongly that it is. universality with Linux supporting
> > smaller and smaller Arm chips is part of what I was touching on in the
> > paragraph you had a hard time deciphering. This is something BSD is
> > having a hard time competing with atleast in my experience of wanting
> >
> Although, I accept there is no real excuse for my rudeness.
No worries, I have a thick actually english skin as I hope those I talk
to do too. If you think that's rude, you are probably a gent.
--
___
'Write programs that do
Joel Roth wrote:
> I suppose the answer is that there is no shortcut to
> administering a system than learning the details.
Nope. No such thing as a free lunch.
And in the free(dom) software community we have the additional free
market burden of many different sources. There are many different
Hello Roger
Excerpt from Roger Leigh:
>>> update-rc.d foo disable|enable
-- --
>> It might be a nuisance but running the stop part of the initscript isn't the
>> same as not touching it all?
>
> Sorry, I don't quite understand the question here. update-rc.d
> never starts or stops anything--
Bob Proulx wrote:
> Joel Roth wrote:
> > Roger Leigh wrote:
> > > Getting rid of all the /etc/default disable options will be a release
> > > goal for jessie.
> >
> > Good. I'd prefer to be rid of /etc/default entirely!
>
> So you would rather that people edit the /ec/init.d/* scripts
> themselve
Joel Roth wrote:
> Roger Leigh wrote:
> > Getting rid of all the /etc/default disable options will be a release
> > goal for jessie.
>
> Good. I'd prefer to be rid of /etc/default entirely!
So you would rather that people edit the /ec/init.d/* scripts
themselves and manage them as conffiles at up
would even recommend SysV-like
capabilities.), because while it itself will function in virtually any
half-way POSIX environment: Initscripts themselves, which SysV cannot do
anything without, are entirely platform-specific. For example: Debian
initscripts will not work at ALL on an LFS system,
On 04/16/2013 11:55 AM, Thilo Six wrote:
Hello Michael,
Excerpt from Michael Biebl:
-- --
+ dropping human readable textfiles in favour of c binary code, which
makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and
Roger Leigh wrote:
> Getting rid of all the /etc/default disable options will be a release
> goal for jessie.
Good. I'd prefer to be rid of /etc/default entirely!
For example, I just learned about /etc/default/keyboard.
Why not /etc/keyboard or /etc/keyboard.default? Having a central
location fo
On Tue, Apr 16, 2013 at 08:30:45PM -0400, staticsafe wrote:
> On 4/16/2013 19:33, Chris Bannister wrote:
> > On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> >> I believe very strongly that it is. universality with Linux supporting
> >
On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> I believe very strongly that it is. universality with Linux supporting
> smaller and smaller Arm chips is part of what I was touching on in the
> paragraph you had a hard time deciphering. This is something BSD is
> having a hard tim
On 4/16/2013 19:33, Chris Bannister wrote:
> On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
Yes and do you know it was designed to do just what it does for a good
reason in 32 kb of code. Hello world is 8kb
>>>
>>> Not relevant to choosing an init system.
>>
>> I believ
On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> > > Yes and do you know it was designed to do just what it does for a good
> > > reason in 32 kb of code. Hello world is 8kb
> >
> > Not relevant to choosing an init system.
>
> I believe very strongly that it is. universality wi
Rick Thomas wrote:
> Bob Proulx wrote:
> >I have been using Debian for many years now. In all of that time I
> >have never wanted to "manage" init scripts. I always wonder. What
> >are people trying to do?
>
> For an example of where one will want to "manage" the init scripts,
> take a look at
On Mon, Apr 15, 2013 at 09:09:15PM +0200, Thilo Six wrote:
> > update-rc.d foo disable|enable
> >
> > is one method.
>
> Thank you for sharing this!
> It might be a nuisance but running the stop part of the initscript isn't the
> same as not touching it all?
Sorry, I don't quite understand the q
; account for how initscripts will work, but I've not seen many
> distributions try and fashion a fully concurrent init system through
> init scripts.
Both Debian and SuSE use insserv to build a dependency graph of the
script relations, and startpar to run the scripts in the correct
order by tr
> > Yes and do you know it was designed to do just what it does for a good
> > reason in 32 kb of code. Hello world is 8kb
>
> Not relevant to choosing an init system.
I believe very strongly that it is. universality with Linux supporting
smaller and smaller Arm chips is part of what I was touc
On Tue, Apr 16, 2013 at 09:06:31PM +0100, Kevin Chadwick wrote:
> Yes and do you know it was designed to do just what it does for a good
> reason in 32 kb of code. Hello world is 8kb
Not relevant to choosing an init system.
> I am saying it is easy for anyone to follow edit and lookup a man page
> On Tue, Apr 16, 2013 at 10:33:47AM +0100, Kevin Chadwick wrote:
> > I think you miss the point which is those unit files depend on C code
>
> So do classic init scripts:
>
> $ file /sbin/init
> /sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses
> > Lets not pollute this useful thread with systemd
>
> It seems a thread about init systems and administration/tweaking of them is
> the
> most appropriate place for systemd to be mentioned. Not least that it can
> solve
> the problem the OP had. It should not be ignored or avoided from bein
Hello Michael,
Excerpt from Michael Biebl:
-- --
+ dropping human readable textfiles in favour of c binary code, which
makes it
needless more complex to debug the whole show.
>>> That's non-sense. systemd unit files are text-files in ini-like format
>>> and much more readable th
On 04/16/2013 04:33 AM, Kevin Chadwick wrote:
+ dropping human readable textfiles in favour of c binary code, which makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more readable then shell scripts with all th
On Mon, Apr 15, 2013 at 09:20:03PM +0100, Kevin Chadwick wrote:
> Lets not pollute this useful thread with systemd
It seems a thread about init systems and administration/tweaking of them is the
most appropriate place for systemd to be mentioned. Not least that it can solve
the problem the OP had.
On Tue, Apr 16, 2013 at 10:33:47AM +0100, Kevin Chadwick wrote:
> I think you miss the point which is those unit files depend on C code
So do classic init scripts:
$ file /sbin/init
/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), fo
> > + dropping human readable textfiles in favour of c binary code, which makes
> > it
> > needless more complex to debug the whole show.
>
> That's non-sense. systemd unit files are text-files in ini-like format
> and much more readable then shell scripts with all their boiler plate.
I think
Am 16.04.2013 04:26, schrieb Yaro Kasear:
> On 04/15/2013 07:13 PM, Michael Biebl wrote:
>> Am 15.04.2013 21:35, schrieb Thilo Six:
>>> + dropping human readable textfiles in favour of c binary code, which
>>> makes it
>>> needless more complex to debug the whole show.
>> That's non-sense. systemd
Am 16.04.2013 04:26, schrieb Yaro Kasear:
> UNLESS, does anyone know if journalctl works fine inside a
> LiveCD/DVD/USB/Ferret/Whatever on another systemd setup? Or, maybe as a
> better way to put it, use a live media's journalctl to use a non-running
> systemd's journal?
Sure, that works: journal
On 04/15/2013 07:13 PM, Michael Biebl wrote:
Am 15.04.2013 21:35, schrieb Thilo Six:
+ dropping human readable textfiles in favour of c binary code, which makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more
On Tue, 16 Apr 2013 02:12:20 +0200
Michael Biebl wrote:
> Am 15.04.2013 20:12, schrieb Celejar:
> > What's wrong with sysv-rc-conf (although it won't work for some of the
> > fancier stuff you have in mind, such as running daemons "on demand")?
>
> It's orphaned and hasn't seen any updates for o
Am 15.04.2013 21:35, schrieb Thilo Six:
> + dropping human readable textfiles in favour of c binary code, which makes it
> needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more readable then shell scripts with all their
Am 15.04.2013 20:12, schrieb Celejar:
> What's wrong with sysv-rc-conf (although it won't work for some of the
> fancier stuff you have in mind, such as running daemons "on demand")?
It's orphaned and hasn't seen any updates for over 6 years.
--
Why is it that all of the instruments seeking inte
On Mon, 15 Apr 2013 08:39:27 -0400
Stefan Monnier wrote:
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
> > What is more complicated than this. If you want it then insta
Hello Yaro,
Excerpt from Yaro Kasear:
-- --
> Systemd has "assimilated" udev,
-- --
> Related to the above two downsides, systemd is not really a crowning
> example of a developer following the UNIX Philosophy of "one simple task
> and do it well."
-- --
> Administrators might not like
>> file-rc "works", but only just. I would not be surprised if it was
>> removed for the next stable release--it's simply incompatible with
>> dependency-based booting.
That's a shame, I would take direct editing of runlevel.conf over
dependency-based booting myself.
>> When you are using dyn
Hello Siard,
Excerpt from Siard:
> Thilo Six wrote:
>> gentoo has a rather nice API for an administrator to handle
>> initscripts s.th. i always missed in debian.
>
> Isn't sysv-rc-conf what you are looking for?
Thank you for your help. I am aware of the existents o
Hello Roger,
Excerpt from Roger Leigh:
-- --
> update-rc.d foo disable|enable
>
> is one method.
Thank you for sharing this!
It might be a nuisance but running the stop part of the initscript isn't the
same as not touching it all?
-- --
> Getting rid of all the /etc/default disable options
Hello Bob,
Excerpt from Bob Proulx:
> Thilo Six wrote:
>> Subject: administration of initscripts
>> ...in debian has been no pleasure for some time now.
>
> Sorry to hear that. Why not?
I was looking for the "offical" way of dealing with initscript for so
Thilo Six wrote:
> gentoo has a rather nice API for an administrator to handle
> initscripts s.th. i always missed in debian.
Isn't sysv-rc-conf what you are looking for?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
Am 15.04.2013 17:26, schrieb Erwan David:
> And disabling them in /etc/default prevent launching them after boot
> (see my need on the other tread).
"update-rc.d disable" is the proper way to disable a service from
starting at boot time.
--
Why is it that all of the instruments seeking intell
On Mon, Apr 15, 2013 at 03:55:33PM +0100, Roger Leigh wrote:
> Getting rid of all the /etc/default disable options will be a release
> goal for jessie.
Very glad to hear that. Services that come shipped with an /etc/default file
that disables the daemon 'by default' really irk me. Not least puppet
*very* quickly by starting independent units at the same time. Standard
SysV init generally cannot do this, though it's hard to account for how
initscripts will work, but I've not seen many distributions try and
fashion a fully concurrent init system through init scripts. OpenRC
allege
On Mon, Apr 15, 2013 at 05:28:02PM +0200, Erwan David wrote:
> Le 15/04/2013 16:55, Roger Leigh a écrit :
> >On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
> >>>I have been using Debian for many years now. In all of that time I
> >>>have never wanted to "manage" init scripts. I
Le 15/04/2013 16:55, Roger Leigh a écrit :
On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
What is more complicated th
Le 15/04/2013 14:39, Stefan Monnier a écrit :
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
What is more complicated than this. If you want it then install it.
If you don't want it
On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
> > What is more complicated than this. If you want it then
> I have been using Debian for many years now. In all of that time I
> have never wanted to "manage" init scripts. I always wonder. What
> are people trying to do?
> What is more complicated than this. If you want it then install it.
> If you don't want it then remove or purge it. With those
On Mon, Apr 15, 2013 at 11:02:19AM +0100, Kevin Chadwick wrote:
> > > I have been using Debian for many years now. In all of that time I
> > > have never wanted to "manage" init scripts. I always wonder. What
> > > are people trying to do?
> >
> > Hi Bob,
> >
> > For an example of where one
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
>
> Hi Bob,
>
> For an example of where one will want to "manage" the init scripts,
> take a look at the thread in debi
On Apr 14, 2013, at 10:10 PM, Bob Proulx wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
Hi Bob,
For an example of where one will want to "manage" the init scripts,
take
Thilo Six wrote:
> Subject: administration of initscripts
> ...in debian has been no pleasure for some time now.
Sorry to hear that. Why not?
> Well the reason i write this, is i found a solution that works for me which i
> would like to share with you.
Thank you for sharing.
for an administrator to handle initscripts s.th. i
always missed in debian. So i modelled this solution somewhat after the gentoo
API.
Here are the unvoidable screenshots:
initial situation:
# find /etc/rc[S0-6].d/ -iname '*cups*'
/etc/rc1.d/K01cups
/etc/rc2.d/S18cups
/etc/rc3.d/S18cups
Unable to migrate to dependency based boot sequencing.
> error: Problems detected: package initscripts left obsolete init.d script
> behind, package initscripts left obsolete init.d script behind, package
> initscripts left obsolete init.d script behind
>
> /etc/init.d/stop-bootl
I am not able to switch to dependency based boot. Here is the relevant
output.
debian:/boot/grub# dpkg-reconfigure sysv-rc
info: Checking if it is safe to convert to dependency based boot.
error: Unable to migrate to dependency based boot sequencing.
error: Problems detected: package initscripts
On Thu, Jan 19, 2012 at 07:53:09PM +0100, Hans-J. Ullrich wrote:
> Hi list,
>
> I am wondering, why the package "initscripts" wants to delete klogd,
> logcheck,
> sysklogd and snort.
>
> Of course, it is because of the dependencies. But I wonder, if this is a
> The world seems to have moved to rsyslogd, install that (it does the
> same thing) and all will be well.
>
> David
Yeah, this did the trick! I wonder, what announcement I have missed.
Thanks for the advice!
Cheers
Hans
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
wit
On 2012-01-19 19:53 +0100, Hans-J. Ullrich wrote:
> I am wondering, why the package "initscripts" wants to delete klogd,
> logcheck,
> sysklogd and snort.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633038.
> Of course, it is because of the dependencies. But
On Thursday 19 Jan 2012, Hans-J. Ullrich wrote:
> Hi list,
>
> I am wondering, why the package "initscripts" wants to delete klogd,
> logcheck, sysklogd and snort.
>
> Of course, it is because of the dependencies. But I wonder, if this is a
> temporarily problem
Hi list,
I am wondering, why the package "initscripts" wants to delete klogd, logcheck,
sysklogd and snort.
Of course, it is because of the dependencies. But I wonder, if this is a
temporarily problem (because the package is too new) or if there is a
successor for klogd and syskl
proc and /sys.
>
>
> But my question is, how to fix it?
>
Thanks to all who replied; I bit the bullet, backed up and purged
initscripts - and some very important packages which depend on it , like
sysvinit, udev and hal - keeping a note of everything I needed to reinstall,
and it all
John O'Hagan wrote:
Hi,
When shutting down my etch laptop of late, it stops just short of power-off
with a message along the lines of "No more processes in this runlevel". I
then have to power-off manually.
I looked in /etc/init.d and noticed that the "halt" script was no longer a
script, b
r this I occasionally notice random file substitutions like
> the above.
>
> But my question is, how to fix it?
>
> So far I've tried reinstalling iniscripts (the package which provides
> the missing scripts) but for some reason this fails to replace them,
> even with
ed reinstalling iniscripts (the package which provides the
missing scripts) but for some reason this fails to replace them, even with
the dodgy ones moved out of the way.
I was going to try purging initscripts before reinstalling, but was scared off
by some heavy warnings from apt-get.
Any in
(the package which provides the
missing scripts) but for some reason this fails to replace them, even with
the dodgy ones moved out of the way.
I was going to try purging initscripts before reinstalling, but was scared off
by some heavy warnings from apt-get.
Any insights or advice?
Thanks,
Jo
ing to overwrite `/etc/default/devpts', which is also in package initscripts
>
>The installed version of initscripts is 2.85-11.
>
>Could someone give me a hint on how to solve this?
You can't, really. It's a bug in libc6. See
http://bugs.debian.org/cgi-bin/pkgreport.c
hello ng,
same problem here with initscripts version 2.85-13. calling apt-get -f
install doesn`t solve the problem. when i try to update to
initcripts_2.85-14 i get an unmet dependency error:
The following packages have unmet dependencies:
libc6-dev: Depends: libc6 (= 2.3.2.ds1-11) but 2.3.2.ds1
On Wednesday 24 March 2004 6:48 pm, Henrique de Moraes Holschuh wrote:
> Todays' will work, as far as I can tell. I verified it the hard way an hour
> ago.
LOL, I like that answer... wanna wee nip of scotch? ya sound like you
could use it
--
The real fun of living wisely is that you get to feel
On Wednesday 24 March 2004 6:46 pm, Brad Sims wrote:
> As I understand it several versions are screaming about not
> actually booting.. what is the last known good Sid version?
It looks like one can pass rw to the kernel at boot to fix this..
is the syntax "linux rw"?
--
The real fun of living w
On Wed, 24 Mar 2004, Brad Sims wrote:
> As I understand it several versions are screaming about not
> actually booting.. what is the last known good Sid version?
Todays' will work, as far as I can tell. I verified it the hard way an hour
ago.
--
"One disk to rule them all, One disk to find th
As I understand it several versions are screaming about not
actually booting.. what is the last known good Sid version?
--
The real fun of living wisely is that you get to feel smug about it
-- Hobbes
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
Hello,
I am trying to upgrade libc6 2.3.2.ds1-10 to libc6_2.3.2.ds1-11 in Sid,
but I get this error:
dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-11_i386.deb
(--unpack):
trying to overwrite `/etc/default/devpts', which is also in package initscripts
The installed versi
, V4.4, when
referring to scheduling.]
On Mon, 28 Jul 2003, Peter Hugosson-Miller wrote:
> Date: Mon, 28 Jul 2003 10:38:14 +0200
> From: Peter Hugosson-Miller <[EMAIL PROTECTED]>
> To: Debian User <[EMAIL PROTECTED]>
> Subject: initscripts
> Resent-Date: M
Wim De Smet wrote:
I can't really help, but if apm is causing you problems, and you have a
fairly new motherboard, you might wanna check out if it supports acpi. I
switched to acpi resently and it works like a charm (much better than
apm ever did).
mvg,
Wim
My guess is it wouldn't work, as my m
out for myself.
>
> I have found the following page that describes, amoung other things,
> the initscripts that are run when changing runlevels:
> http://www.debian.org/doc/debian-policy/ch-opersys.html and I think I
> am in the right area. Trouble is, this seems to be more a
Still no responses to my apm question (
http://lists.debian.org/debian-user/2003/debian-user-200307/msg03355.html
), so I've started investigating a bit, to see if I can figure this out
for myself.
I have found the following page that describes, amoung other things, the
initscripts tha
90 matches
Mail list logo
