Bug#652972: grub-pc: Grep complains input file `/boot/grub/grub.cfg.new' is also the output
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 output is redirected to the same file. A
workaround would simply be:"grep -q "^password " <${grub_cfg}.new"
Then grep is unable to recognize this fact. But there is perhaps a
security bug anyway:
If there was no sync after generating grub.cfg.new before this grep,
then there might not be that "password" keyword yet!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#649457: systemd-37 : /lib/udev/udevd not there
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 installed package systemd-sysv which let me to purge sysvinit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589594: close 530395
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
Bug#589577: Provide a trigger update-init-system for Maintainers
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 against it because it not ensure the boot sequence is consistent after upgrades. I believe it is better that a inconsistent boot sequence casues imediate failure instead of trying to clean up the mess after the init.d scripts have been replaced. My guess is the other way round: The mess occures because of that. Quiet sure you have been through this all, what you mention here, during the first time of introduction of insserv to Debian: All the LSB-headers had to be written from scratch. If there were some quick tests available at begin of the trigger? Why did I saw this debootstrap problem: Debootstrap failed because of a service couldn't install without a yet installed Required-Start. Sound like a bug in some package. Only one I remember having such bug recently was util-linux, and that bug was luckily solved after a few days. Is there some new bug around now? At http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581420#5 --- Selecting previously deselected package util-linux. O: dpkg: regarding .../util-linux_2.17.2-1_amd64.deb containing util-linux, pre-dependency problem: O: util-linux pre-depends on libblkid1 (>= 2.17.2) O: libblkid1 is unpacked, but has never been configured. --- Last line sounds to me that a triggered insserv after unpacking all packages during the dbootstrap would have prevented this bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589591: [Pkg-utopia-maintainers] Bug#530395: closed
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 upgrading package dbus And I did find a new bug : param reverse is not even used when stoping all of the dependend services. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589591: reopen 530395
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
Bug#530395: closed
reopen 530395 = --- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589577: Provide a trigger update-init-system for Maintainers
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-header. Users would get caught by less bugs then? This can be triggered using update-rc.d. For example a call like this will cause a reordering based on dependencies: update-rc.d /etc/init.d/bootlogs defaults 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 Why did I saw this debootstrap problem: Debootstrap failed because of a service couldn't install without a yet installed Required-Start. The use of a deferred trigger would have prevented this bug. The solution was of manual kind. Why do I see this many not fitting LSB-header bugs: If every init.d/SCRIPT is NOT a conffile it would possible to remove the script also when upgrading. A deferred trigger would issue insserv to run for a full removal of all remaining confs. Following a fresh install of the new version of the package. This would solve and prevent all bugs where the solution found just was to cleanly purge the package before reinstall of the upgrade version. For example dkms is used like this as a trigger of not standard modules of the kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589561: init.d/Scripts are not considered conffiles
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 for packages not totally purged, if there was installed an alternative conflicting resource. As of the existence of /etc/insserv/overrides there already is the place to modify lsb-headers. Why not accepting the whole script from there if user modification was needed ? And remove all /etc/init.d/Scipts when deinstalling ! Can you provide more explanation? I failed completely to understand what you mean. Note that a recent version of sysv-rc will only refuse to migrate to dependency based boot sequencing when obsolete init.d scripts are present if a problem is detected in the boot sequence. Not sure if that is relevant for your report, but thought it best to mention it. Happy hacking, I looked over the whole list of bugs: - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584082 would not occure... - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584086 updating a changed LSB-header! I don't find all of the bugs today evening, but I have seen many of these the long afternoon I studied the list. For a user removing a package but not purging, it is totally non-intuitive that remaining start scripts may cause some trouble in the future. These scripts are seen as NOT-editable und thus considered to be NO conffiles. How do you handle a not removed init.d/SCRIPT, that is reused by the user for granted to implement something new he _wants_ ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589577: Provide a trigger update-init-system for Maintainers
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 of the whole lot of warnings of not fitting LSB headers when upgrading a system: A user customized start sequence only by provided /etc/insserv/overrides/HEADERS (these should be auto generated by some tool). 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-header. Users would get caught by less bugs then? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589561: init.d/Scripts are not considered conffiles
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 not totally purged, if there was installed an alternative conflicting resource. As of the existence of /etc/insserv/overrides there already is the place to modify lsb-headers. Why not accepting the whole script from there if user modification was needed ? And remove all /etc/init.d/Scipts when deinstalling ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#353248: resolved by new kernel comandline option
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
Bug#572789: what about network.dns.disablePrefetch
> [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 about "network.dns.disablePrefetch" ? I found nothing like that in my old icedove about:config so for security reason I set a new boolean: network.dns.disablePrefetch=true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563204: (no subject)
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 . Not found os-prober 3. Searched for Version 1.98 . Not found os-prober After 2 hours examination I got the most easy solution (for dummies): apt-get install os-prober I would not have os-prober purged if I knew the entry: GRUB_DISABLE_OS_PROBER=true in /etc/default/grub (I wish this for a self explaining commented out entry...) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572789: icedove leaks information to spam servers per dns prefetch
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 YOU just read it! I wish as default a configuration: network.prefetch-next=false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569998: parted should be useful for extended parallel Win7 installations
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 endings of partitions at MB boundaries. What happened to me NOT knowing this: I did as usual: 1. Laptop recovery 12GB 2. Win7 starter 100 MB 3. Win7 ntfs 100GB 4. extended partition /dev/sda5 swap 5GB /dev/sda6 root 30GB /dev/sda7 home 60GB /dev/sda8 vfat 60GB /dev/sda9 vfat 60GB And a grub install into MBR After some time we did using Win7 a format of /dev/sda9. Since then the grub bootloader was not started any more. Even Samsung recovery using F4 just after bios didn't work. After using Ms fixmbr tools the Windows Computer-Partitioning-Tool shows 5 primary disks and three partitions residing in the extended partition! Simple solution would be to install Linux using just a fourth primary partition without any swap etc... To be able to setup some more sophisticated Linux enironments parallel with Win7 is there a way to setup using MB boundaries? Is it a way in fdisk to change chs using some Win7 friendly values for example? Are there different mode of partitioning available? This bug was tagged severe, for the most people don't know of this trap and end up with an unbootable system! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b799716.1040...@gmx.de
Bug#553596: linux-image-2.6.31-1-amd64
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
Bug#543375: considering an kernel configuring issue
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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540866: insserv might not remove all
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540866: insserv might not remove all
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 not understand your functions. Therefore I have made
this script insservtest:
---
#!/bin/bash
s=$1
t=/etc/init.d/$s
o=/etc/insserv/overrides/$s
cd /etc || exit 1
[ -f $t ] || echo "Please provide an init_scriptname: $0 of:"
[ -f $t ] || ls init.d
[ -f $t ] || exit 2
# make default
insserv -r $s >/dev/null || echo "ATTENTION rm_default Error was $? "
[ -f $o ] && mv $o ${o}_sic || echo "ATTENTION mv Error was $? "
insserv -d $s >/dev/null || echo "ATTENTION default Error was $? "
echo " startscripts:"
for i in rc?.d/S*${s} ; do
[ -f $i ] && echo $i
done
for i in rc?.d/K*${s} ; do
[ -f $i ] && echo $i
done
echo " default $s header: "
sed -n '/^# Default-S/p' $t
echo " manipulate override $o"
dmstart='5'
dmstop='0 1 2 3 6'
sed -n '/^### BEGIN INIT INFO/,/^### END INIT INFO/p' $t > $o
sed -i -e 's/^\(# Default-Start:[[:space:]]\+\).*/\1'"${dmstart}"'/' \
-e 's/^\(# Default-Stop:[[:space:]]\+\).*/\1'"${dmstop}"'/' $o
sed -n '/^# Default-S/p' $o
echo " insserv -d $s "
insserv -d $s || echo " insserv Error was $? "
echo " startscripts:"
for i in rc?.d/S*${s} ; do
[ -f $i ] && echo $i
done
for i in rc?.d/K*${s} ; do
[ -f $i ] && echo $i
done
echo " insserv -r $s "
insserv -r $s || echo " insserv Error was $? "
echo " startscripts:"
for i in rc?.d/S*${s} ; do
[ -f $i ] && echo $i
done
for i in rc?.d/K*${s} ; do
[ -f $i ] && echo $i
done
# restore default
insserv -r $s >/dev/null || echo "ATTENTION rm_restore Error was $? "
[ -f ${o} ] && rm ${o}
[ -f ${o}_sic ] && mv ${o}_sic $o
insserv -d $s >/dev/null || echo "ATTENTION restore Error $? "
---
script output of "insservtest apache2" :
startscripts:
rc2.d/S19apache2
rc3.d/S19apache2
rc4.d/S19apache2
rc5.d/S19apache2
rc0.d/K01apache2
rc1.d/K01apache2
rc6.d/K01apache2
default apache2 header:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
manipulate override /etc/insserv/overrides/apache2
# Default-Start: 5
# Default-Stop: 0 1 2 3 6
insserv -d apache2
startscripts:
rc2.d/S19apache2
rc3.d/S19apache2
rc4.d/S19apache2
rc5.d/S19apache2
rc0.d/K01apache2
rc1.d/K01apache2
rc2.d/K01apache2
rc3.d/K01apache2
rc6.d/K01apache2
insserv -r apache2
startscripts:
rc2.d/S19apache2
rc3.d/S19apache2
---
script output of "insservtest microcode.ctl" :
ATTENTION mv Error was 1
startscripts:
rc2.d/S18microcode.ctl
rc3.d/S18microcode.ctl
rc4.d/S18microcode.ctl
rc5.d/S18microcode.ctl
rc0.d/K01microcode.ctl
rc1.d/K01microcode.ctl
rc6.d/K01microcode.ctl
default microcode.ctl header:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
manipulate override /etc/insserv/overrides/microcode.ctl
# Default-Start: 5
# Default-Stop: 0 1 2 3 6
insserv -d microcode.ctl
startscripts:
rc2.d/S18microcode.ctl
rc3.d/S18microcode.ctl
rc4.d/S18microcode.ctl
rc5.d/S18microcode.ctl
rc0.d/K01microcode.ctl
rc1.d/K01microcode.ctl
rc2.d/K01microcode.ctl
rc3.d/K01microcode.ctl
rc6.d/K01microcode.ctl
insserv -r microcode.ctl
startscripts:
rc2.d/S18microcode.ctl
rc3.d/S18microcode.ctl
---
As you can see, if I call "insserv -d" with a fresh overrides
there will be lost startscripts after a final "insserv -r"
Ciao from Hamburg,
Ralph
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540866: insserv might not remove all
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:$local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: console-screen acpid dbus hal # Should-Stop: console-screen # Default-Start: 4 5 # Default-Stop: 0 1 2 3 6 # Short-Description: X display manager for KDE # Description: KDM manages a collection of X servers, which may be on the local host or remote machines. ### END INIT INFO # Managed by the distro-defaults package.
Bug#530395: dbus: startscript does what insserv should do
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 || true
done
---
what is exactly what insserv does! If we want a fast boot we should not
implement the dependency system there in this dbus script!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529753: insserv: at shutdown critics about invoke-rc.d stop
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
Bug#529753: insserv: at shutdown critics about invoke-rc.d stop
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 on LPT/eth1/
Sending on LPT/eth1/
Sending on Socket/fallback
DHCPRELEASE on eth1 on
send_packet: Network is unreachable
send_packet: Please consult README file regarding broadcast ...
invoke-rc.d:
invoke-rc.d: Warning: invoke-rc.d called during shutdown
invoke-rc.d: initscript policy layer fallback to safe mode
invoke-rc.d:
Reloading /etc/samba/smb.conf: smbd onlyNo process is pid
bd.pid found running: none killed
.
Done.
Cleaning up ifupdown
Deactivating swap
---
In the startscripts I found invoce-rc.d only in cups, which is
not called during shutdown and in dbus where this function is called
with a stop parameter:
---
dependent_services()
services=$(grep -s -l "^# Required-Start:.*dbus" /etc/rc${r}.d/S??*
invoke-rc.d $service $action || true
---
I tested by commenting out this invoke-rc.d for a shutdown:
/etc/init.d it is NOT the cause of my scary shutdown messages!
(By the way I find this /etc/init.d/dbus script ugly: It does on every
start/shutdown what insserv alone should do for dependency sake)
As an experimental affine sidux user I installed insserv half a year
earlier than this package reached debian unstable.
Now I guess there was a bad insserv installation long time ago.
Why does my network and samba want to start when shuting down?
What can I do to fix my system ?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529753: insserv: at shutdown critics about invoke-rc.d stop
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: this is not supported by insserv # warning: As only service dbus calls "invoke-rc.d dbus stop" on shutdown. Ralph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529753: insserv: at shutdown critics about invoke-rc.d stop
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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529498: flexible fsck the conservative approach
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 needs:
--- a/boot/grub/menu.lst2009-05-20 18:33:48.0 +0200
+++ a/boot/grub/menu.lst2009-05-20 19:01:53.0 +0200
@@ -135,3 +135,8 @@
### END DEBIAN AUTOMAGIC KERNELS LIST
+
+title forcefsck and forceshutdown Debian - mounts until fsck 26
+root (hd0,5)
+kernel /boot/vmlinuz root=LABEL=debian ro nosplash forcefsck
forceshutdown 2
+initrd /boot/initrd.img
--- a/etc/rc.local 2009-01-14 18:48:25.0 +0100
+++ a/etc/rc.local 2009-05-20 18:25:37.0 +0200
@@ -1,14 +1,25 @@
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
+RDEV=$(mount | grep ' / ' | sed -e 's/ on.*//')
+MAXM=$( /sbin/tune2fs -l $RDEV | grep 'Maximum mount count'|sed -e
's/Maximum mount count:[ ]*//' )
+ACTU=$( /sbin/tune2fs -l $RDEV | grep 'Mount count'|sed -e 's/Mount
count:[ ]*//' )
+DIFF=$(( $MAXM - $ACTU ))
+MENU=/boot/grub/menu.lst
+sed -i -e "sXmounts until fsck.*Xmounts until fsck ${DIFF}X" $MENU
+if grep -wiq "forceshutdown" /proc/cmdline ; then
+if grep -wiq "forcefsck" /proc/cmdline ; then
+ shutdown -h now
+fi
+fi
exit 0
--- a/etc/init.d/checkfs.sh 2008-08-12 14:50:47.0 +0200
+++ a/etc/init.d/checkfs.sh 2009-05-19 20:11:59.0 +0200
@@ -41,6 +41,9 @@
if [ -f /forcefsck ]
then
force="-f"
+ elif grep -wiq "forcefsck" /proc/cmdline
+ then
+ force="-f"
else
force=""
fi
--- a/etc/init.d/checkroot.sh 2008-07-27 16:03:16.0 +0200
+++ a/etc/init.d/checkroot.sh 2009-05-19 20:09:54.0 +0200
@@ -245,6 +245,9 @@
if [ -f /forcefsck ]
then
force="-f"
+ elif grep -wiq "forcefsck" /proc/cmdline
+ then
+ force="-f"
else
force=""
fi
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529498: initscripts: respond to forcefsck on kernel cmdline
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 UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
