This bug is very confusing for advanced users, because normally there is
a very bad bug with such an error message. But it is more like a
security flaw, see later:
Turns out in /usr/sbin/grub-mkconfig:
if [ x${grub_cfg} != x ] ! grep -q ^password ${grub_cfg}.new
grep internally recognizes
Package: systemd
Version: 37
Package: udev
Version: 175
Severity: simple
Justification: udev target will not work?
In /lib/systemd/system/udev.service there is a reference to
/lib/udev/udevd
For this is to activate the udev daemon I did
ln -s /sbin/udevd /lib/udev/udevd
Just to mention: I have
Resolved by new kernel boot option forcefsck? See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529498#15
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: sysv-rc
Version: 2.88dsf-11
Severity: minor
Although
#grep '^/etc/init.d/' /var/lib/dpkg/info/*.conffiles
shows all packages do consider init.d/scripts as conffiles.
This might be non-intuitive for Debian users! In fact it will provide,
and has, endless new bug reportings for packages
Package: sysv-rc
Version: 2.88dsf-11
Severity: minor
Provide an update-init-system trigger for Maintainers.
Every now and then there are bugs the kind of a maintainer not
understanding the Debian init system. Or it is debootstrap when
something should be started but not yet installed.
I think
Am 18.07.2010 20:19, schrieb Petter Reinholdtsen:
[Ralph Ulrich]
Although #grep '^/etc/init.d/' /var/lib/dpkg/info/*.conffiles shows
all packages do consider init.d/scripts as conffiles. This might be
non-intuitive for Debian users! In fact it will provide, and has,
endless new bug reportings
Am 18.07.2010 22:25, schrieb Petter Reinholdtsen:
[Ralph Ulrich]
A trigger (like update-initramfs) could have alternative
implementations for all different init systems also. This way poor
Debian maintainers soul should be bothered less to handle init
scripts: only need to provide a valid LSB
reopen 530395 =
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: dbus
reopen 530395
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Am 19.07.2010 00:28, schrieb Michael Biebl:
On 19.07.2010 00:18, Ralph Ulrich wrote:
reopen 530395 =
wtf?
Care to explain what you are trying to do here?
Nothing was changed. Why did you close in the first place. OK, this
reimplementation of an init system is not uses any more when
Am 19.07.2010 00:20, schrieb Petter Reinholdtsen:
[Ralph Ulrich]
Is update-rc.d really usable as a trigger like kernel related
update-initramfs is used:
- deferrable
- all of the previous configuration obsoleted and removed
I considered using triggers to update the boot sequence, but decided
Package: dbus
---
I did look at Version: 1.2.24-1 not Version: 1.2.24-2
Excuse me, never will happen again
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=544745
[2] http://kb.mozillazine.org/Network.prefetch-next
Thank you for the links. Regarding:
network.prefetch-next is only in use when APP_TYPE_MAIL is NOT being set
If network.prefetch-next is not used, why not setting it to false?
Waht
Package: icedove
Version: 3.0.2
Severity: wishlist
Pre thunderbird-3.0.3 builds have an advanced configuration entry:
network.prefetch-next TRUE
This seemingly is also an icedove issue too! This means:
Every spammer can send a special hacked email to you, where he gets info
from dns-queries if
I had purged os-prober some time ago but forgotten about. Now I wanted
to reenable os-probing. I saw the file
/etc/grub.d/30_os-prober
despite having purged os-prober (it is a grub-common config file).
1. Now I searched for a package grub-os-prober. Nothing found.
2. Searched for all names grub .
Package: parted
Architecture: i386
Version: 1.8.8.git.2009.07.19-5
Severity: severe
Situation:
Since Vista there is no more a compatible way to partition your
harddisk. Win7 needs 1MB free space before first primary partition and 1
MB free space before every first logical disk. And it needs
I saw a bug related on launchpad.net about karmic kernels don't like noapic
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Does play this kernel .config a role:
CONFIG_RTC_HCTOSYS
as only some homebrew kernel systems affected by this bug
But:
if you : CONFIG_RTC_LIB=m
you won't: CONFIG_RTC_HCTOSYS
I saw this mentioned in some other bug report about hwclockfirst - fsck
--
To UNSUBSCRIBE, email to
Package: insserv
Version: 1.12.0-10
Severity: medium
if placed a /etc/insserv/overrides/kdm to disable start in runlevel3
and then making: insserv -d kdm
or making a: insserv -r kdm
startscipts of runlevel3 are not removed.
### BEGIN INIT INFO
# Provides: kdm
# Required-Start:
Am 10.08.2009 20:55, schrieb Petter Reinholdtsen:
Hm. I am trying to reproduce this in a test case, but am unable to
replicate your problem. This is the test case I wrote. Any idea
where I fail to understand the problem you are experiencing?
test_override_remove() {
...
Excuse me, I do
If upstream development is openSUSE:
openSUSE does a stopLink in whatever runlevel a script is started,
doesn't matter what Default-stop says there.
So perhaps an upstream developer from openSUSE thinks to only search for
startscripts to remove where the is a stopscript.
--
To UNSUBSCRIBE,
Package: dbus
Version: 1.2.14-2
Severity: minor
This is ugly:
Every start of /etc/init.d/dbus does:
---
services=$(grep -s -l ^# Required-Start:.*dbus /etc/rc${r}.d/S??*
.
.
.
for i in $services ; do
service=$(basename $i)
service=${service#S??}
invoke-rc.d $service $action ||
Kel Modderman wrote:
# warning:
# warning: stop script call of invoke-rc.d
# warning: this is not supported by insserv
# warning:
I am not aware of any message generated by the insserv program which is
similar to it.
I made a photo of the shutdown messages scrolling away:
---
Listening
I meant:
/etc/init.d/DBUS it is NOT the cause
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: insserv
Version: 1.12.0-4
Severity: minor
At shutdown the scripts /etc/init.d/dbus makes a call
invoke-rc.d service stop
which insserv does not seem to like: There comes a warning message. Why?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Kel Modderman wrote:
which insserv does not seem to like: There comes a warning message. Why?
What warning message? What does insserv have to do with it?
I see this on every shutdown, something like it (it is scrolling fast):
# warning:
# warning: stop script call of invoke-rc.d
# warning:
Here is a patch to flexible fsck in a conservative manner in the sense
of doing fsck at boot time as ever.
- You will see free mounts until automatic fsck.
- You can force fsck at boot time in which case Mountcount is reseted.
Edit the root entries of resulting /boot/grub/menu.lst to your
Package: initscripts
Version: 2.86.ds1-61
Severity: wishlist
File: /etc/init.d/checkrootfs.sh
When starting openSUSE with a parameter FORCEFSCK it behaves like it was
touched a file /forcefsck.
Debian ignores such a parameter. Why?
This would make me flexible with fsck.
Ralph
--
To
28 matches
Mail list logo