Bug#605784: nagios-statd: diff for NMU version 3.12-1.1
Hi Jonathan, I've looked over the changes and they are okay with me, what you have done is fine. Thank you. On Mon, Dec 27, 2010 at 3:37 AM, Jonathan Wiltshire j...@debian.org wrote: tags 605784 + patch tags 605784 + pending thanks Dear maintainer, I've prepared an NMU for nagios-statd (versioned as 3.12-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmwhttp://people.debian.org/%7Ejmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJNF28+AAoJEFOUR53TUkxRY3kP/j/Y7atQ2h2oAc/S7hSdQR/N 0mGBqzeZ+E1avNLu2EPStMNehxNj1LcgdZ8FhUo2wTsmfDWMUhobsXbwkC3GF7KW jPue0Zoncmj0+WSi1rHEh8nt4gQO3CbQfza3F2CnG769yhhj6h3Pw4dHt5opwE5u jjVoRS6R8kG47gpvqioSies7Cs1N/6bgr1EONM+IQy9fsRdlYbB36h3zCIb0iCI7 U8CIVCKDCZ0pCXGuwbOkdx4W4qG9FOePjl7vaeF7favrxAl9TYZFOhxoEp0TF8Ss oaF0efGkUA0dAmWv4lUaCF24FIJ1h78gZeCx7RLgn4gGr949CeBYhnU8Ealh5nPv YPrXLF446ZcgJhbL8bgjxMhBZYJlVTJPxpIpwHyRaLzaM6lI0XJqjtDP9oHRlDTT EKwBaP9Pv4MUK5rd5dsXG6OPwflIRBBJVw4ryNj/KL6Ud74KjtLkY5NdG8O6Bgw9 J/8Pbr92hfBXWo66zr09dx4iEZL7R0xXp0zvbruXHm1oJqsIXFYR76EPsi8Yd+yp kD7UszdcIG+3aOS48sxGEW6hFRTbWfDy6/uVYks+2/2Vmv6vGelRXzPQ8S3EKpwx uWVHTCx7SSMsDvKDt7lmOvxR8u/5Gs3E4y7Eg21yX9pLSBEuh+OijNuVT9o9JXJU UKarbJcBdMD/SgENqVyz =uyHq -END PGP SIGNATURE-
Bug#605784: nagios-statd-server: test with python2.5 sucessful
Hi Vladislav, Thanks for your debugging work. I'll upload a new package soon, with your recommendations. Jason On Sat, Dec 11, 2010 at 3:13 AM, Vladislav Kurz vladislav.k...@webstep.netwrote: Package: nagios-statd-server Version: 3.12-1 Followup-For: Bug #605784 Hello, i have tested nagios-statd witch python2.4 and python2.5. With both of them it works fine, for couple of days without problem. When running with python2.6, problems arise cca 1 hour after start. Suggested fix: Change the first line of /usr/sbin/nagios-statd to: #!/usr/bin/python2.5 and change dependency to pyhton2.5 regards Vladislav Kurz -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages nagios-statd-server depends on: ii python 2.6.6-3+squeeze1 interactive high-level object-orie nagios-statd-server recommends no packages. nagios-statd-server suggests no packages. -- no debconf information
Bug#521862: backtrace with more info
Hi,
Here is a backtrace with hopefully more useful information.
Thanks.
Starting program: /usr/bin/evolution
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib/libicudata.so.40 is .hash at 00b4
[New Thread 0xb522b9a0 (LWP 17425)]
[New Thread 0xb4dfbb90 (LWP 18893)]
[Thread 0xb4dfbb90 (LWP 18893) exited]
[New Thread 0xb4dfbb90 (LWP 19355)]
[Thread 0xb4dfbb90 (LWP 19355) exited]
[New Thread 0xb4dfbb90 (LWP 19539)]
[New Thread 0xb4197b90 (LWP 19599)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4dfbb90 (LWP 19539)]
0xb7b20ffa in unixCheckReservedLock (id=0xb4201d98, pResOut=0x0)
at sqlite3.c:23253
23253 sqlite3.c: No such file or directory.
in sqlite3.c
#0 0xb7b20ffa in unixCheckReservedLock (id=0xb4201d98, pResOut=0x0)
at sqlite3.c:23253
#1 0xb7b4a332 in camel_sqlite3_file_xCheckReservedLock (pFile=0xb4202290)
at camel-db.c:283
#2 0xb7ad7685 in sqlite3PagerAcquire (pPager=0xb42021b8, pgno=1,
ppPage=0xb4dfa87c, noContent=0) at sqlite3.c:12943
#3 0xb7ad79b4 in sqlite3BtreeGetPage (pBt=0xb4201d40, pgno=1,
ppPage=0xb4dfa8e8, noContent=0) at sqlite3.c:38534
#4 0xb7adfd33 in sqlite3BtreeBeginTrans (p=0xb4201d10, wrflag=0)
at sqlite3.c:39190
#5 0xb7ae0175 in sqlite3BtreeCursor (p=0xb4201d10, iTable=1, wrFlag=0,
pKeyInfo=0x0, pCur=0xb4210140) at sqlite3.c:39293
#6 0xb7af40f5 in sqlite3InitOne (db=0xb4201900, iDb=0, pzErrMsg=0xb4dfadf4)
at sqlite3.c:73438
#7 0xb7af453d in sqlite3Init (db=0xb4201900, pzErrMsg=0xb4dfadf4)
at sqlite3.c:73617
#8 0xb7af491a in sqlite3ReadSchema (pParse=0xb4dfadec) at sqlite3.c:73653
#9 0xb7af6212 in sqlite3Pragma (pParse=0xb4dfadec,
pId1=value optimized out, pId2=0xb420fa38, pValue=0xb420fa58,
minusFlag=0) at sqlite3.c:72427
#10 0xb7afff9d in sqlite3Parser (yyp=0xb420f9e8,
yymajor=value optimized out, yyminor=
{z = 0xb420f9d2 100, dyn = 0, n = 3}, pParse=0xb4dfadec)
at sqlite3.c:87350
#11 0xb7b048d6 in sqlite3RunParser (pParse=0xb4dfadec,
zSql=0xb420f9c0 PRAGMA cache_size=100, pzErrMsg=0xb4dfafa8)
at sqlite3.c:88489
#12 0xb7b08963 in sqlite3Prepare (db=0xb4201900,
zSql=0xb420f9c0 PRAGMA cache_size=100, nBytes=-1, saveSqlFlag=0,
ppStmt=0xb4dfb034, pzTail=0xb4dfb038) at sqlite3.c:73794
#13 0xb7b0900e in sqlite3LockAndPrepare (db=0xb4201900,
zSql=0xb420f9c0 PRAGMA cache_size=100, nBytes=-1, saveSqlFlag=0,
ppStmt=0xb4dfb034, pzTail=0xb4dfb038) at sqlite3.c:73875
#14 0xb7b0d74e in sqlite3_exec (db=0xb4201900,
zSql=0xb420f9c0 PRAGMA cache_size=100, xCallback=0, pArg=0x0,
pzErrMsg=0xb4dfb078) at sqlite3.c:70703
#15 0xb7b489e0 in cdb_sql_exec (db=0xb4201900,
stmt=0xb420f9c0 PRAGMA cache_size=100, ex=0x0) at camel-db.c:432
#16 0xb7b491af in camel_db_command (cdb=0xb4201840,
stmt=0xb420f9c0 PRAGMA cache_size=100, ex=0x0) at camel-db.c:555
#17 0xb7b4a90d in camel_db_open (
path=0xb42018b0
/home/billy/.evolution/mail/exchange/bi...@rob/folders.db, ex=0xb4dfb204) at
camel-db.c:496
#18 0xb7db34cd in construct (service=0xb4200828, session=0x994eaf8,
provider=0xb4431900, url=0x99b2f80, ex=0xb4dfb204) at camel-store.c:238
#19 0xb7d9fd8a in offline_store_construct (service=0xb4200828,
session=0x994eaf8, provider=0xb4431900, url=0x99b2f80, ex=0xb4dfb204)
at camel-offline-store.c:97
#20 0xb442cd76 in construct (service=0xb4200828, session=0x994eaf8,
provider=0xb4431900, url=0x99b2f80, ex=0xb4dfb204)
at camel-exchange-store.c:283
#21 0xb7dab3d5 in camel_service_construct (service=0xb4200828,
session=0x994eaf8, provider=0xb4431900, url=0x99b2f80, ex=0xb4dfb204)
at camel-service.c:315
#22 0xb7dacfcf in get_service (session=0x994eaf8,
url_string=0x99b2590
exchange://billy;auth=n...@rob/;use_ssl=always;filter;check_all;owa_url=https://rob/exchange;save-passwd=true;mailbox=billy;owa_path=/exchange;,
type=CAMEL_PROVIDER_STORE, ex=0x99ae534) at camel-session.c:198
#23 0xb7dac724 in camel_session_get_service (session=0x994eaf8,
url_string=0x99b2590
exchange://billy;auth=n...@rob/;use_ssl=always;filter;check_all;owa_url=https://rob/exchange;save-passwd=true;mailbox=billy;owa_path=/exchange;,
type=CAMEL_PROVIDER_STORE, ex=0x99ae534) at camel-session.c:243
#24 0xb5009380 in get_store_exec (m=0x99ae520) at mail-ops.c:1350
#25 0xb5008219 in mail_msg_proxy (msg=0x99ae520) at mail-mt.c:520
#26 0xb6b2c496 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x099ae520 in ?? ()
#28 0x in ?? ()
The program is running. Exit anyway? (y or n)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508281: update-grub: dramatically fails at reporting errors
You could try the following: # sh -x update-grub On Tue, 2008-12-09 at 16:16 +0100, Cyril Brulebois wrote: So be it. Let's debug: ,-- | [EMAIL PROTECTED]:~$ /sbin/update-grub -h | Searching for GRUB installation directory ... found: /boot/grub | [EMAIL PROTECTED]:~$ /sbin/update-grub --help | Searching for GRUB installation directory ... found: /boot/grub | [EMAIL PROTECTED]:~$ sudo /sbin/update-grub -v | Searching for GRUB installation directory ... found: /boot/grub | [EMAIL PROTECTED]:~$ sudo /sbin/update-grub --verbose | Searching for GRUB installation directory ... found: /boot/grub `-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: (no subject)
I'm not sure, but i would say the php extension needs recompiling. so that would be the logical place to file the bug. On Tue, 2008-02-05 at 00:52 +0100, Markus Fischer wrote: I think this sounds very reasonable. I don't know why the debian PHP5 package version crashes, because when I compile 5.2.4 and 5.2.5 from clean php.net from source, the tidy extension works. The PHP package tidy version exhibits this problem reproduceable on different machines for me. Should this file against PHP instead? -- Jason Thomas Network Operations Manager Link Innovations - 02 9634 0400 http://www.linkinnovations.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: libtidy-0.99-0: Exceeds allowed memory size when used with php5-tidy 5.2.4-2+b1
Why don't you just increase your max memory in php. libtidy is now 2
years newer. most likely its going to use more memory.
On Sun, 2008-02-03 at 22:54 +0100, Markus Fischer wrote:
Package: libtidy-0.99-0
Version: 20080116cvs-2
Severity: grave
Justification: renders package unusable
When used within PHP, the allowed memory size from PHP is exceeded:
[EMAIL PROTECTED]:~/src$ cat debian-5.2.4-tidy-crash.php
?php
$sHtml = HTML
html
body
h1test/h1
/body
/html
HTML;
$oTidy = tidy_parse_string($sHtml);
[EMAIL PROTECTED]:~/src$ /usr/bin/php debian-5.2.4-tidy-crash.php
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 141265660 bytes) in /home/mfischer/src/debian-5.2.4-tidy-crash.php
on line 9
Call Stack:
0.0003 51896 1. {main}()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:0
0.0003 52048 2. tidy_parse_string()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:9
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'unknown')
The reason I'm filing this against the libtidy-0.99-0 package is that this
does
not happen with libtidy-0.99-0=20051018-1 .
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libtidy-0.99-0 depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
libtidy-0.99-0 recommends no packages.
-- no debconf information
--
Jason Thomas
Network Operations Manager
Link Innovations - 02 9634 0400
http://www.linkinnovations.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460177: update-grub updates menu.lst with incorrect boot device
The lines between the automagic markers are auto generated and subject to change. You need to edit the default options between those markers to suit your needs. Then when you run update-grub the generated content will be correct. On Thu, 2008-01-10 at 23:12 -0500, Thomas Bushnell BSG wrote: Package: grub Version: 0.97-27 Severity: serious update-grub mutates the boot device incorrectly in producing menu.lst. This bug, btw, caused a remote server to fail to reboot automatically and cost me actual expense in remote debugging assistance. Attached is menu.lst-before (which I hand-edited to be correct) and menu.lst-after showing the effect of running update-grub. See the following diff below. update-grub is giving a root argument for hde6 when sda6 is correct. mount and df report the correct information: # mount /dev/sda6 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda7 on /var/cache/openafs type ext3 (rw) /dev/sda8 on /vicepa type ext3 (rw) /dev/sdb2 on /vicepb type ext3 (rw) /dev/sdb3 on /vicepc type ext3 (rw) AFS on /afs type afs (rw) # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda6123039704 10407332 106382292 9% / tmpfs 517768 0517768 0% /lib/init/rw udev 1024076 10164 1% /dev tmpfs 517768 0517768 0% /dev/shm /dev/sda7 48062440 4276200 41344764 10% /var/cache/openafs /dev/sda8307695928 134587736 157478156 47% /vicepa /dev/sdb2239399140 12608524 214629816 6% /vicepb /dev/sdb3239399168 14599972 212638396 7% /vicepc AFS900 0 900 0% /afs 118c118 kernel /boot/vmlinuz-2.6.18-5-k7 root=/dev/sda6 ro --- kernel /boot/vmlinuz-2.6.18-5-k7 root=/dev/hde6 ro 124c124 kernel /boot/vmlinuz-2.6.18-5-k7 root=/dev/sda6 ro single --- kernel /boot/vmlinuz-2.6.18-5-k7 root=/dev/hde6 ro single 130c130 kernel /boot/vmlinuz-2.6.18-4-k7 root=/dev/sda6 ro --- kernel /boot/vmlinuz-2.6.18-4-k7 root=/dev/hde6 ro 136c136 kernel /boot/vmlinuz-2.6.18-4-k7 root=/dev/sda6 ro single --- kernel /boot/vmlinuz-2.6.18-4-k7 root=/dev/hde6 ro single -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages grub depends on: ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libncurses55.5-5 Shared libraries for terminal hand grub recommends no packages. ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel -- Jason Thomas Network Operations Manager Link Innovations - 02 9634 0400 http://www.linkinnovations.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412021: grub fails to cope with '/boot' on different partition to '/'
Your changing (hd0,?) in the wrong place. Look a little higher up in the menu.lst file. The entries you are changing are regenerated every time update-grub is run. On Thu, Feb 22, 2007 at 09:28:13PM +, Bernard Boudet wrote: Package: grub Version: 0.97-23 Severity: critical Justification: breaks the whole system My /boot partition is on /dev/hda11, so in menu.lst it says: root (hd0,11) update-grub trashes that and resets each case to: root (hd0,0) This happens whenever a new kernel is installed and it leaves the system unbootable. My workaround is to manually edit menu.lst after each time a new kernel is installed and before rebooting. baron:/boot/grub# grep -v -e '^$' -e '^#' menu.lst default 0 timeout 5 color cyan/blue white/blue title Debian GNU/Linux, kernel 2.6.18.baron.20070221.0915 root(hd0,11) kernel /vmlinuz-2.6.18.baron.20070221.0915 root=/dev/hda1 ro initrd /initrd.img-2.6.18.baron.20070221.0915 savedefault title Debian GNU/Linux, kernel 2.6.18.baron.20070221.0915 (single-user mode) root(hd0,11) kernel /vmlinuz-2.6.18.baron.20070221.0915 root=/dev/hda1 ro single initrd /initrd.img-2.6.18.baron.20070221.0915 savedefault title Debian GNU/Linux, kernel 2.6.18-custom.01 root(hd0,11) kernel /vmlinuz-2.6.18-custom.01 root=/dev/hda1 ro initrd /initrd.img-2.6.18-custom.01 savedefault title Debian GNU/Linux, kernel 2.6.18-custom.01 (single-user mode) root(hd0,11) kernel /vmlinuz-2.6.18-custom.01 root=/dev/hda1 ro single initrd /initrd.img-2.6.18-custom.01 savedefault title Debian GNU/Linux, kernel 2.6.18-3-686 root(hd0,11) kernel /vmlinuz-2.6.18-3-686 root=/dev/hda1 ro initrd /initrd.img-2.6.18-3-686 savedefault title Debian GNU/Linux, kernel 2.6.18-3-686 (single-user mode) root(hd0,11) kernel /vmlinuz-2.6.18-3-686 root=/dev/hda1 ro single initrd /initrd.img-2.6.18-3-686 savedefault title Debian GNU/Linux, kernel 2.6.17-2-686 root(hd0,11) kernel /vmlinuz-2.6.17-2-686 root=/dev/hda1 ro initrd /initrd.img-2.6.17-2-686 savedefault title Debian GNU/Linux, kernel 2.6.17-2-686 (single-user mode) root(hd0,11) kernel /vmlinuz-2.6.17-2-686 root=/dev/hda1 ro single initrd /initrd.img-2.6.17-2-686 savedefault baron:/boot/grub# cp menu.lst menu.lst.save baron:/boot/grub# update-grub Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: /vmlinuz-2.6.18.baron.20070221.0915 Found kernel: /vmlinuz-2.6.18-custom.01 Found kernel: /vmlinuz-2.6.18-3-686 Found kernel: /vmlinuz-2.6.17-2-686 Updating /boot/grub/menu.lst ... done baron:/boot/grub# diff menu.lst.save menu.lst 119c119 root (hd0,11) --- root (hd0,0) 125c125 root (hd0,11) --- root (hd0,0) 131c131 root (hd0,11) --- root (hd0,0) 137c137 root (hd0,11) --- root (hd0,0) 143c143 root (hd0,11) --- root (hd0,0) 149c149 root (hd0,11) --- root (hd0,0) 155c155 root (hd0,11) --- root (hd0,0) 161c161 root (hd0,11) --- root (hd0,0) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.baron.20070221.0915 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages grub depends on: ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand grub recommends no packages. -- no debconf information ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345931: If the problem is that the user doesn't know ...
If stage2 and stage1.5 are correct then most likely stage1 is correct as well. So would say just checking there version matches grub-shell would be enough. On Mon, Sep 25, 2006 at 09:01:02AM +0530, Kapil Hari Paranjape wrote: Solution 2: (Since stage1 does not change a lot) we can usually expect that stage1 of an older version will be able to load the current version of stage2 or stage1.5; so we only check the version numbers of the latter. However, this has some future risks built in---when stage1 is actually changed what do we do? ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385391: update-grub still uses /bin/sh as its interpreter, fails with dash
Because the people that wrote it knew of no other way. If you are skilled in bash scripting we would love your input. Patch or Advice are both welcome. Thanks. On Thu, Aug 31, 2006 at 06:41:45PM +0300, R??mi Denis-Courmont wrote: Le jeudi 31 ao?t 2006 02:24, vous avez ?crit : But /usr/sbin/update-grub still has /bin/sh as its interpreter and executing this file with dash fails: [EMAIL PROTECTED]:~# /usr/sbin/update-grub [: 25: ==: unexpected operator exec: 25: -a: not found Is there any serious reason for using the non-standard '-a' option besides pure cosmetic if someone runs top or ps within the short lifespan of update-grub.real anyway ? -- R?mi Denis-Courmont http://www.remlab.net/ ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345931: grub 0.97 doesn't work on several machines
close 345931 thanks Hi, grub-install copies the various stage* files into /boot/grub. grub shell does not. If you do not copy the stage* files then they will be incompatible with the boot sector that is installed. grub-install is the recommeneded method to install. On Mon, Feb 06, 2006 at 02:55:05PM +0100, Frans Pop wrote: retitle 345931 System fails to boot after updating boot sector from grub interactive shell thanks I have managed to reproduce this in vmware using the following procedure: - new Sarge install (has grub 0.95+cvs20040624-17) - change sources list to unstable and upgrade After grub is upgraded (to 0.97-4), but without re-installing its boot sector, the system reboots without problem. Now there are two methods to reinstall the grub boot sector to the new version. 1) Run the grub-install script # grub-install /dev/sda1 Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script 'grub-install'. (hd0) /dev/sda # reboot = system reboots without any problems 2) Run the grub shell interactively as in the original report # grub grub find /boot/grub/menu.lst (hd0,0) grub root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub setup (hd0) Checking if /boot/grub/stage1 exists... no Checking if /grub/stage1 exists... yes Checking if /grub/stage2 exists... yes Checking if /grub/e2fs_stage1_5 exists... yes Running embed /grub/e2fs_stage1_5 (hd0)... 16 sectors are embedded. succeeded Running install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu..lst... succeeded Done. grub quit # reboot = Grub menu is not shown (screen remains blank); system fails to boot Conclusions: - grub-install does the right thing - the setup command in the grub interactive shell checks if the stage files exist, but apparently its setup command fails to check if they are compatible with the current version of grub I will keep the image I created this way in vmware for a while in case additional information is wanted. Cheers, Frans Pop ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345931: grub 0.97 doesn't work on several machines
Hi, Please check your menu.lst for a splashimage line. If one or more exists comment them out and try to boot again. How where the menu.lst files created? You could also try pressing 'c' for the command line interface, when the random garbage is on the screen. But I've no idea if that will work. I have seen this problem occurs when the splashimage directive points to a nonexistant file. On Wed, Jan 04, 2006 at 01:58:23PM +0100, John Hughes wrote: When the system random garbage gets printed on the screen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343260: more info please
Can you please send a copy of: - menu.lst - copy of menu.lst with winxp as the first entry. - fstab - output of `mount` command Do you have any idea why this has happened? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341897: grub: update-grub has stopped finding kernels not in /boot
My theory is, that the debian installer created those entries. or perhaps grubconf. but not update-grub. On Sun, Dec 04, 2005 at 10:34:31AM +, Julian Gilbey wrote: Weird - my old menu.lst didn't have such a line. I've added the new boot options after this line in my new version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328837: very old package, should this be removed?
I no longer use the software either and it is no longer maintained upstream. I agree with removal of the package, What should happen now? On Sat, Sep 17, 2005 at 06:23:07PM +0200, Marc 'HE' Brockschmidt wrote: Package: titrax Version: 1.98.1-6 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has not many users and there are some alternatives (worklog, wmwork) available. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290474: FYI
you will need to add your required modules before you install the kernel or you can run mkinitrd by hand after having added your modules. [EMAIL PROTECTED]:~$ cat /etc/mkinitrd/modules # /etc/mkinitrd/modules: Kernel modules to load for initrd. # # This file should contain the names of kernel modules and their # arguments # (if any) that are needed to mount the root file system, one per line. # Comments begin with a `#', and everything on the line after them are # ignored. # # You must run mkinitrd(8) to effect this change. # # Examples: # # ext2 # wd io=0x300 scsi_mod sd_mod libata sata_sil [EMAIL PROTECTED]:~$ -- Jason I hope you learn speaking English proper I hope speak I me you. -- Branden Robinson, 2001 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
