Bug#673942: SOme help
hi, I am using linux mint 13, and i am also being affected by this libreoffice bug. I hope this can be some help, here is a log from my kernel log. Jun 2 22:36:08 john-K53E kernel: [ 947.278850] soffice.bin[2135]: segfault at 7f5913bfeef0 ip 7f5913bfeef0 sp 7fff50101228 error 14 Jun 2 22:36:46 john-K53E kernel: [ 985.238492] soffice.bin[3253]: segfault at 646959b0 ip 7f54933898d3 sp 7f547338e960 error 4 in libc-2.15.so[7f549334e000+1b3000]
Bug#369321: mondo: Tape catalog limited to 4096 entries
Hi Andree, I've done some additional testing with the suggested change to my-stuff.h, changing the value for: #define MAX_TAPECATALOG_ENTRIES 4096/// The maximum number of entries in the tape catalog ...to 8192. For my purposes, the issue I've reported is resolved between the two parameter changes. Thanks for your guidance in dealing with this issue. John Nelson --- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi John, Great stuff, thanks a lot for your testing and your feedback! So, it looks like we can work around the issues by changing some of the hardcoded parameters. Hopefully, this keep us going until we can make this all dynmic. Obviously, I'll be most interest in any further test results you obtain. Keep it up best regards, Andree PS: I'm away for the week and will thus only respond sporadically. John Nelson [EMAIL PROTECTED] wrote: Hi Andree, This past weekend has been my first opportunity to work on a new build. I did a new package build with the following change to libmondo-tools.c: (IS_THIS_A_STREAMING_BACKUP(bkpinfo-backup_media_type) ? 16 : 16) * 1024; With that change only, I was able to run a complete backup, boot from the CD created by Mindi, and successfully run a full verify in disaster recovery mode. I didn't note the exact number, but Mondo created ~1700 afio archives containing 41794099k of data. I'm planning on trying some of the other changes that were discussed, but it will take time. Thanks, John Nelson --- Andree Leidenfrost [EMAIL PROTECTED] wrote: Hi Bruno, Thanks a lot for your feedback! On Sat, 2006-06-24 at 18:44 +0200, Bruno Cornec wrote: Andree Leidenfrost said on Tue, Jun 13, 2006 at 01:04:58AM +1000: [Bruno: Would be great if you could comment on this one. Looks to me like we may only have to bump up a number, but maybe there are implications that I'm not aware off...] Ok. Thanks a lot for your bug report and your analysis of the problem. I don;t have any experience with tapes and Mondo Rescue, but I can confirm that the following is still even in the latest SVN in mondo/common/my-stuff.h: #define MAX_TAPECATALOG_ENTRIES 4096 /// The maximum number of entries in the tape catalog. So, the question would be what a reasonable value for this couldlook like. Would 65536 be ok? The problem I see is that mondo will then create an array of 65k structuresi ./mondo/mondo/common/mondostructures.h: struct mountlist_line el[MAX_TAPECATALOG_ENTRIES]; ./mondo/mondo/common/mondostructures.h: struct s_tapecat_entry el[MAX_TAPECATALOG_ENTRIES]; Hm, I see what you mean, mountlist_line is 640 bytes + 1 long long int, that's certainly too big to go to 65k entries. (s_tapecat_entry is much smaller.) that's where my new work on dynamic memory allocation will definitively help. I know, but it's not ready for prime time yet :-( Yeah, no worries. I suppose we just need to figure out whether we can find an interim solution for now. I fear that by increasing that way we consume a lot of memory which wwill be most of the time useless, creating other types of bugs. Agreed. Do we need to go from 4096 to 65k directly. Isn't there a middle point which could solve the issue as well as limit the memeory consumed ? Maybe we double it to 8192 for starters? In that context, did you see my other message to this bug about the maximum filesize? Would increasing the filesize make it so that less entries in the tape catalog would be used because we'd have fewer archive files in the first place? Maybe doubling the filesize AND doubling MAX_TAPECATALOG_ENTRIES would be the way to go? What do you reckon? ;-) Bruno. Cheers, Andree -- Andree Leidenfrost Sydney - Australia __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369321: mondo: Tape catalog limited to 4096 entries
Hi Andree, This past weekend has been my first opportunity to work on a new build. I did a new package build with the following change to libmondo-tools.c: (IS_THIS_A_STREAMING_BACKUP(bkpinfo-backup_media_type) ? 16 : 16) * 1024; With that change only, I was able to run a complete backup, boot from the CD created by Mindi, and successfully run a full verify in disaster recovery mode. I didn't note the exact number, but Mondo created ~1700 afio archives containing 41794099k of data. I'm planning on trying some of the other changes that were discussed, but it will take time. Thanks, John Nelson --- Andree Leidenfrost [EMAIL PROTECTED] wrote: Hi Bruno, Thanks a lot for your feedback! On Sat, 2006-06-24 at 18:44 +0200, Bruno Cornec wrote: Andree Leidenfrost said on Tue, Jun 13, 2006 at 01:04:58AM +1000: [Bruno: Would be great if you could comment on this one. Looks to me like we may only have to bump up a number, but maybe there are implications that I'm not aware off...] Ok. Thanks a lot for your bug report and your analysis of the problem. I don;t have any experience with tapes and Mondo Rescue, but I can confirm that the following is still even in the latest SVN in mondo/common/my-stuff.h: #define MAX_TAPECATALOG_ENTRIES 4096 /// The maximum number of entries in the tape catalog. So, the question would be what a reasonable value for this couldlook like. Would 65536 be ok? The problem I see is that mondo will then create an array of 65k structuresi ./mondo/mondo/common/mondostructures.h: struct mountlist_line el[MAX_TAPECATALOG_ENTRIES]; ./mondo/mondo/common/mondostructures.h: struct s_tapecat_entry el[MAX_TAPECATALOG_ENTRIES]; Hm, I see what you mean, mountlist_line is 640 bytes + 1 long long int, that's certainly too big to go to 65k entries. (s_tapecat_entry is much smaller.) that's where my new work on dynamic memory allocation will definitively help. I know, but it's not ready for prime time yet :-( Yeah, no worries. I suppose we just need to figure out whether we can find an interim solution for now. I fear that by increasing that way we consume a lot of memory which wwill be most of the time useless, creating other types of bugs. Agreed. Do we need to go from 4096 to 65k directly. Isn't there a middle point which could solve the issue as well as limit the memeory consumed ? Maybe we double it to 8192 for starters? In that context, did you see my other message to this bug about the maximum filesize? Would increasing the filesize make it so that less entries in the tape catalog would be used because we'd have fewer archive files in the first place? Maybe doubling the filesize AND doubling MAX_TAPECATALOG_ENTRIES would be the way to go? What do you reckon? ;-) Bruno. Cheers, Andree -- Andree Leidenfrost Sydney - Australia __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369321: mondo: Tape catalog limited to 4096 entries
Hi Andree, Thanks very much for getting back to me on this. 64k sounds like a reasonable number, with caveats, of course. 4096 was sufficient while using a DDS-2 tape drive but not once I upgraded to a DDS-3 drive. What would happen with a high-capacity drive, such as a DLT-S4? If I could expand a little on the observed behavior, you might find the additional info useful. I also have some questions, as I'm not a programmer/developer of any sort, and I'm still quite a newbie WRT Linux. When Mondo fails on me, I believe it's backing up my MP3 collection, as the file sizes are about what would be expected for those files. It appears to be putting, 1 or perhaps 2 MP3 files per afio archive, and since my collection is in excess of 5900, it runs out of catalog entries. Also, this was my first attempt at a multi-tape backup after upgrading to a DDS-3 tape drive. I never had trouble while using a DDS-2 drive, but I was not trying to backup as much data either. Is there a limitation on the size of the afio archives? I've noticed that the afio archives are staged in /tmp/shm before being written to the backup media, so perhaps there's a limitation to accommodate systems that don't have much resources? Does Mondo use a single pool of catalog entries, or is it 'per media'? I've never had to restore from a multi-tape backup set with Mondo, so I don't know how it behaves under that circumstance. I would also have to ask where Mondo allocates space to store the catalog while it's running? I would surmise that increasing the size of the catalog may significantly change the resource requirements of the package. If I may be of any further assistance, please don't hesitate to contact me. Thanks, John Nelson --- Andree Leidenfrost [EMAIL PROTECTED] wrote: [Bruno: Would be great if you could comment on this one. Looks to me like we may only have to bump up a number, but maybe there are implications that I'm not aware off...] Hi John, Thanks a lot for your bug report and your analysis of the problem. I don;t have any experience with tapes and Mondo Rescue, but I can confirm that the following is still even in the latest SVN in mondo/common/my-stuff.h: #define MAX_TAPECATALOG_ENTRIES 4096 /// The maximum number of entries in the tape catalog. So, the question would be what a reasonable value for this couldlook like. Would 65536 be ok? Cheers, Andree On Sun, 2006-05-28 at 20:26 -0700, John Nelson wrote: Package: mondo Version: 2.04-4 Severity: important Mondo fails due to a 4096 entry limitation in the tape catalog. This causes /dev/shm to fill up and the task hangs when afio reports Ready for volume 2. -- Package-specific info: /var/log/mindi.log and /var/log/mondo-archive.log provided in attachment. = Fileystem information: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda3 36869072 2663656 32332552 8% / tmpfs 518260 0518260 0% /dev/shm /dev/hda150233 6715 40924 15% /boot /dev/hdb1118729904 33986324 78712380 31% /home tmpfs10240 804 9436 8% /dev /dev/shm256000256000 0 100% /tmp/tmp.mondo.29578/tmp.mondo.29937/tmpfs -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mondo depends on: ii afio 2.5-3 archive file manipulation program ii binutils 2.15-6 The GNU assembler, linker and bina ii buffer1.19-7 Buffering/reblocking program for t ii cdrecord 4:2.01+01a01-2 command line CD writing tool ii dosfstools2.11-2 Utilities to create and check MS-D ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libnewt0.51 0.51.6-20 Not Erik's Windowing Toolkit - tex ii lzop 1.01-3 fast compression program ii mindi 1.04-4 creates boot/root disks based on y Versions of packages mindi depends on: ii bzip2 1.0.2-7high-quality block-sorting file co ii file 4.12-1 Determines file type using magic ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii mindi-busybox 1.00-4 Collection of shell utilities in a ii mindi-kernel 2.4.27-2sarge1 failsafe Linux kernel for Mindi/Mo ii mindi-partimagehack 0.6.2-4disk partition imaging utility for ii mkisofs
Bug#314214: Package: debian-installer
Package: installation-reports INSTALL REPORT Debian-installer-version: Debian GNU/Linux 3.1 r0a Sarge - Official i386 Binary-1 CD uname -a: Linux maaslx 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux Date: Mon 13 Jun 2005/Tue 14 Jun 2005 (Multiple Attempts Required) Method: How did you install?From CDs built from ISO Images downloaded from various mirrors. What did you boot off? IDE CD-ROM (hdc) Machine: GigaByte GA7NF-RZ nVidia nForce 2 chipset based system (user-assembled) Processor: AMD Duron 950 Memory: 1024MB DDR Dual-Channel Root Device: IDE hda1 Root Size/partition table: cfdisk 2.12p Disk Drive: /dev/hda Size: 20519411200 bytes, 20.5 GB Heads: 255 Sectors per Track: 63 Cylinders: 2494 NameFlags Part Type FS Type [Label]Size (MB) -- hda1BootPrimary Linux ext3 [/] 5568.52 hda5Logical Linux swap / Solaris 674.48 hda6Logical Linux ext3 [/home] 14270.87 Output of lspci and lspci -n: maaslx:/# lspci :00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev a2) :00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2):00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2):00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2):00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2):00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2):00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4) :00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) :00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) :00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) :00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) :00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1) :00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3):00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) :00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2) :01:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) :02:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) :02:00.1 Display controller: ATI Technologies Inc: Unknown device 5940 (rev 01) maaslx:/# lspci -n :00:00.0 0600: 10de:01e0 (rev a2) :00:00.1 0500: 10de:01eb (rev a2) :00:00.2 0500: 10de:01ee (rev a2) :00:00.3 0500: 10de:01ed (rev a2) :00:00.4 0500: 10de:01ec (rev a2) :00:00.5 0500: 10de:01ef (rev a2) :00:01.0 0601: 10de:0060 (rev a4) :00:01.1 0c05: 10de:0064 (rev a2) :00:02.0 0c03: 10de:0067 (rev a4) :00:02.1 0c03: 10de:0067 (rev a4) :00:02.2 0c03: 10de:0068 (rev a4) :00:06.0 0401: 10de:006a (rev a1) :00:08.0 0604: 10de:006c (rev a3) :00:09.0 0101: 10de:0065 (rev a2) :00:1e.0 0604: 10de:01e8 (rev a2) :01:0a.0 0200: 10b7:9200 (rev 74) :02:00.0 0300: 1002:5960 (rev 01) :02:00.1 0380: 1002:5940 (rev 01) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[E] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [E] Comments/Problems: Preface: I'm a WIntel Idiot who's trying to reform, so have patience. Initial boot from ISO/Install CD would hang at various places. Required noapic nolapic arguments to get installer to run with reasonable stability. Boot menu help WAS helpful. Reboot semi-worked, but system was unable to start GDM. I have a GigaByte-branded ATI Radeon 9250 display adapter (GigaByte p/n: GV-R925128T), and selecting ati as my video adapter type broke X11. Being Linux ignorant, I wiped the hard drive and started again. Repeat 2x. After 3rd install and failure, ran Apt from cmdline, uninstalled X11 and re-installed X11. Re-install forced selection of Generic Video Card, and X11 started successfully and GDM started successfully. 800x600 desktop resolution was intolerable, so search began for info on how to correct, which culminated with manually editing /etc/X11/XF86Config-4. Since it may help others, I'm including relevant sections of my /etc/X11/XF86Config-4. The necessary information to resolve this was not obviously located and required a fair amount of searching with
