UPX, lzma stream, xz-devel
The alloc function in the LZMA SDK allows you to pass it a pointer to your own allocater function. (I don't know whether or not the xz library works like that. [Ed: Yes, it does.]) Would that be enough for UPX? Maybe. Some changes would be required to UPX, on both the compression and decompression sides. Decompression is highly machine-dependent: machine-language instructions, bare stack, no libraries. Ten architectures are supported today. For decompression, current UPX [pre-]allocates all space (input, output, and temporary) because that results in smaller code size, which is important. Tens of bytes can make a difference. An allocator function also requires effectively-static storage for the 'next' pointer, which can be cumbersome depending on architecture (such as -fPIE, x86_64, ARM) and interference from SELinux (exec_mod, etc.) -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking for pointers how to set up lzma stream using xz-devel
On 01/04/2010 10:18 AM, Bruno Wolff III wrote: On Mon, Jan 04, 2010 at 07:57:54 -0600, Jon Cieslal...@jcomserv.net wrote: I've actually come across this WRT UPX as well. https://bugzilla.redhat.com/show_bug.cgi?id=501636 It seemed odd that the debian bug for this claimed that source from the SDK was needed. Presumably an appropriate library would work. ... https://bugzilla.redhat.com/show_bug.cgi?id=501636#c6 UPX cannot use a library, UPX must use source. UPX requires total control during decompression (no malloc() allowed, etc.) and so far the library writers have not catered to such a restricted environment, AFAICT. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Electric Fence - still reliable?
On 12/18/2009 08:19 AM, Michael Schwendt wrote: On Fri, 18 Dec 2009 15:57:31 +, Bastien wrote: I'm not sure even trying to use ElectricFence is such a good idea anyway, when we have valgrind available. Yeah, likely. Both can be useful. The speed overhead of ElectricFence is a couple percent, whereas valgrind(memcheck) slows execution by a *factor* of 10 to 20. [ElectricFence] triggering ABRT activity, whereas [Valgrind] requires increased effort to make sense of undetailed traces such as the following (which is bug 548711): ==13516== Invalid read of size 1 ==13516==at 0x400730E: strcmp (mc_replace_strmem.c:426) ==13516==by 0x8D63A6: _nl_find_locale (findlocale.c:94) ==13516==by 0x8D597B: setlocale (setlocale.c:409) ==13516==by 0xA348D1: loadavg (in /lib/libproc-3.2.8.so) ==13516==by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) ==13516==by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) ==13516==by 0x80497E4: ??? (in /usr/bin/w) ==13516==by 0x8CBBB5: (below main) (libc-start.c:226) ==13516== Address 0x4053528 is 0 bytes inside a block of size 12 free'd ==13516==at 0x40057F6: free (vg_replace_malloc.c:325) ==13516==by 0x8D5A1B: setlocale (setlocale.c:203) ==13516==by 0xA3488E: loadavg (in /lib/libproc-3.2.8.so) ==13516==by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) ==13516==by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) ==13516==by 0x80497E4: ??? (in /usr/bin/w) ==13516==by 0x8CBBB5: (below main) (libc-start.c:226) ==13516== I'm sure I could install lots of missing -debuginfo packages manually and tweak valgrind options. It just reported way too much here. This complaint is way off base. It complains undetailed and reported way too much for the same case, which is contradictory. The report gives traceback both for the immediate error and for the cause which happened long ago. Some file and line numbers have been omitted, but those are not needed to pinpoint the error: setlocale() called free() but afterwards setlocale() still used the block which was freed. The bug is in setlocale or in the parameters passed to it by loadavg(). If the problem is in loadavg(), then the tracebacks provide clues to the environment in which loadavg() erred. This report from memcheck is close to ideal. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/09/2009 07:14 AM, James Antill wrote: ... The minimum RAM size on any of these 5 boxes is 2GB. I'd be surprised to find that anyone working as a full time developer has any (non-virt) boxes that are spec'd less than that. Surprise! I have 4 boxes that are 1GB or less (as low as 320MB), and several that are 2GB or more. And yes, shockingly, developers will test on the machines they have easy access to. Sometimes I doubt even that, particularly when shipped software has python syntax errors (type mismatch, wrong number of arguments, no such member, ...) -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On 11/25/2009 02:03 PM, Dave Jones wrote:
On Wed, Nov 25, 2009 at 01:58:38PM -0500, Jakub Jelinek wrote:
glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way
would be just grep through all packages' build.log files (preferrably on
the
box where they are stored to avoid downloading it all).
Can we make it fail the build instead of warning ?
A zero sized memset is always a bug.
No, memset(,,0) is not always a bug. A null region is not automatically a bug.
Here is one example:
struct Foo {
long x;
char hole[8 - sizeof(long)];
} foo;
memset(foo.hole, 0, sizeof(foo.hole));
On a LP64-bit machine such as x86_64, this is memset(foo.hole, 0, 0),
which is *NOT* a bug.
Perhaps the best that can be expected is for the compiler to warn
if _builtin_memset has a third argument which is known to be a compile-time
constant zero. But such a warning must be optional, for there are
legitimate use cases. Also, if the second argument to _builtin_memset
is a compile-time constant which cannot be represented in one byte
(considering both signed and unsigned cases) then another optional warning
may be appropriate.
--
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/24/2009 01:38 PM, Peter Jones wrote: On 11/24/2009 04:25 PM, Adam Williamson wrote: Mandriva Flash - Mandriva's commercial system-on-a-USB-stick thingy - does exactly what you confidently proclaim to be impossible. It comes with a CD ISO you can burn onto a CD (or mini-CD) that allows you to 'chain-boot' the Flash on systems with crappy BIOSes that can't boot from a USB stick (yes, they exist, but are getting progressively rarer, obviously). I don't suppose you can easily fish out a url for the source to this? I'd like to see what they're actually doing. I've done it using Fedora 12, on an old Dell i686 laptop whose BIOS cannot boot USB. A typical GRUB stanza has a line such as: kernel /vmlinuz ro root=live:label='Feodra 12 i386 DVD' rootfstype=auto ... where /vmlinuz is the kernel on the CD, and root=live:label='...' designates the label of the device for the root (and init, and ...), which can be USB, DVD, another CD, any block device that the Linux kernel /vmlinuz can enumerate and understand. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? *IF* netinst.iso works the first time (no hardware failure, no user error, no user misunderstanding, no power failure, no ISP failure, no phoneline failure, no installer bug, no kernel bug, no X11 bug, ...), and *IF* the netinst.iso is used only once (only one machine, user doesn't change his mind, ...), then the 200MB netinst.iso (plus needed packages) does involve less downloading than a 700MB LiveCD. However, not so long ago my network connection was 150KB/s DSL, and I much preferred to download an entire 700MB CD (1.5 hrs) before installation instead of using netinst.iso. By experience, waiting for the entire CD was faster on average. Something would go wrong during the first install attempt, and I would have to start over. Or, I would install again on a different partition in order to compare two setups. Or, I would give the CD to a friend. The 700MB CD was a cache of time, and paid for itself after only *two* uses. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCO ticket#270 - preupgrade and F-12
F12 kernel: 18MB (10mb larger than F11!) Is part of the reason the F-12 kernel is so much larger that the debugging switch is still flipped on? F12 initrd (initramfs) is about 15.5MB (x86_64) or 11.3MB (i686). F11 initrd (initramfs) is about 3.5MB (x86_64) or 3.0MB (i686). F12 initramfs has *all* the drivers; F11 has a subset. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Booting Fedora live USB on MacBookPro
pre-Santa Rosa mac will only boot 32-bit EFI images, and post-Santa Rosa macs will only boot 64-bit EFI images. Also, it is only recently that a Mac might boot from USB2.0 at all; Firewire (IEEE 1394) was required for most of Apple history. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
mmap_low_allowed is the name of the boolean moving forward.
This access has proven to be a critical security feature,
and several kernel/root vulnerabilities will be prevented
by turning this boolean off, with the only down side,
preventing old windows applications from running by default in wine.
(If vbetool is fixed).
It is a mistake to believe the only down side is preventing
old [W]indows applications from running by default in wine.
The claim is not true.
I have three applications that fundamentally fail to work
if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing
memory at address 0 is fundamental to the way that they work.
Using any other page would totally prevent two of the apps
from working at all, and would severely cripple the third.
They are not old [W]indows apps. They are every-day utilities
and development tools written for Linux, and I object to them
being broken.
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces slow path for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
--
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
You're saying you have apps that rely on being able to dereference the zero page, and _not_ because the processor mode requires it? I thought the vax died long ago. The apps were written intentionally to exploit being able to use page 0. It's significantly faster (a factor of 10 or more) and simpler (thousands of lines of code that aren't needed) and easier to use (x==y versus x==(y + k).) With an identity map the hardware already understands the app's abstraction. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before main starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? It does, but it doesn't seem to be terribly useful in debugging, as it keeps hitting that breakpoint over and over and over. (gdb) set stop-on-solib-events 1 (gdb) run args... Stopped due to shared library event (gdb) info shared FromTo Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out (gdb) c Continuing. Stopped due to shared library event (gdb) info shared FromTo Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out 0x00e5a840 0x00f68c78 Yes /lib/libc.so.6 etc. You might run afoul of this years-old bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179072 Post the build, or a pointer to it, plus the needed environment? -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel using LZMA compression
Thanks. But don't understand. What has LZMA todo with Xen? https://bugzilla.redhat.com/show_bug.cgi?id=515831 The executive summary is: Xen does not let a kernel boot itself, because mimicking bare hardware is too tedious (and pointless.) Instead, Xen instantiates an instance of a kernel into the Xen environment. To do this instantiation, Xen does its own decom- pression, so Xen must know everything about the compression. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
I'm not sure I understand. How can LLVM-C be ABI-incompatible with plain GCC-C? See /lib/libgcc_s.so.1 and its symbols, such as stack unwinding, uncommon or messy conversions between data formats, expensive operations on 'long long', etc. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
The title says it all. How about that? We really need it for old intel h/w such as an i855 for example. Enumerate the reasons, please. Which _specific_ bugs or features have been improved elsewhere but not in F11? Why are they important to you and others? -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
Is it possible to do the rebuilds in parallel? I noticed that only one of my four cores was used. And that on smolt 63% of people have a dual-core or greater, so it could lead to massive speed-ups as well. The speedup would be noticeably less than the number of cores. xz uses a history+search table that is significantly larger than dcache. There is competition for memory bandwidth, not just CPU+cache cycles. Would it be possible to have a diff on the filelist db? It seems like a very large download for something that would change very little. Agreed, this would be a 99% savings. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: creating a updated DVD with fedora install
it's possible to create a updated DVD with fedora install ? yum install pungi man pungi VERSION=12 DESTDIR=/my_destination_directory/Fedora$VERSION ARCH=i386 # These are for re-using the destination directory(ies) # such as when using the destination by more than one $ARCH. rm -rf $DESTDIR/work/$ARCH rm -rf $DESTDIR/$VERSION/$ARCH mkdir -p $DESTDIR/work/$ARCH/tmp export TMPDIR=$DESTDIR/work/$ARCH/tmp /usr/sbin/setenforce 0 pungi -c /usr/share/pungi/rawhide-fedora.ks --destdir=$DESTDIR --name Fedora --ver $VERSION --nosource It will download and cache all the packages (about 2000 or more.) It requires about three times as much disk space as the final DVD, plus about an hour after download. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
I tried doing this with the Live CDs for F10 and F11: Parallel unsquashfs: Using 1 processor FATAL ERROR aborting: failed to read fragment table What am I doing wrong? (I'm using the i686 live CDs. What versions are involved? [unsquashfs -v -ll foo.img] unsquashfs version 4.0 works for me on F12-Snap2-i686-Live.iso/LiveOS/squashfs.img when run on either Fedora 11 or rawhide for Fedora 12. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On 09/15/2009 10:29 AM, Andre Robatino wrote: I'm using the latest F11 version of squashfs-tools on a fully updated x86_64 F11 box. Just discovered that it works on Fedora-11-i686-Live.iso, but fails with F10-i686-Live.iso. So the new question is, why doesn't it work with the F10 image? That's a bug, please file in bugzilla, with *specific* version info. Include the checksum of each *.iso, just to be sure. Also, after expanding squashfs.img for F11, it gives me another single huge (over 3 GB) file ext3fs.img. ext3fs.img is a complete, mountable filesystem. mount -o loop ext3fs.img /mnt/foo All the files are there with their actual names, actual contents, etc. So rsync will work on the tree /mnt/foo just as well as rsync works on any actual file system tree. The downside is each rsync session requires processor cycles on both ends. The drawing card of the new zsync tool is that the rsync CPU time on the master side need be done only once; the results are cached as a companion file to each existing file. The companion file contains the checksums for chunks of the [new] file. The master side http server just serves the companion file like any other file. The zsync tool retrieves the whole companion file, does the rsync checksum computations for the local old file, then asks the master for the appropriate partial content (HTTP code 206) of the chunks that the local side does not have already. The gain is that the companion file is smaller. The risk is that anybody who can manufacture collisions for the checksum can pollute the result. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian. Not having looked at the algorithm... *why*? Is it really that big of a difference? rz/sz is a very old application. In the days of 6MHz CPUs it mattered. After that, backwards compatibility took precedence over portability. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On 09/11/2009 12:03 PM, Alexandre Oliva wrote: On Sep 11, 2009, John Reiserjrei...@bitwagon.com wrote: snip https://bugzilla.redhat.com/show_bug.cgi?id=521322 This bug was opened before the new GCC. Exactly *one* kernel build failed because of the new GCC feature. I can't find any evidence that this bug is in any way related with VTA or with the new GCC. Even though there is no known technical connection between 521322 and the hiccup with the new GCC, the hiccup got in the way of communicating and disseminating the work on 521322, by interfering with the normal process of daily rawhide. So how do you get from “GCC debug info was fixed, with one kernel build and a few hours as casualty” to “two-day slip in rawhide kernels”? Yes, 521322 was opened before the new GCC. But fully fixing 521322 (making the software work for my card) has been delayed because the new GCC disrupted the process despite not being an immediate impediment. The first part of 521322 was essentially the same as 520766, and it was marked as duplicate in https://bugzilla.redhat.com/show_bug.cgi?id=521322#c7 with the fix https://bugzilla.redhat.com/show_bug.cgi?id=520766#c4. So I tried to test the fix immediately, by retrieving it directly from Koji late Wednesday afternoon (PDT). That build kernel-2.6.31-0.218.rc9.git2.fc12 failed. The build of the next kernel-2.6.31-0.219.rc9.git2.fc12 succeeded. Yes it did fix the 520766-like problem for me, but it revealed the next bug https://bugzilla.redhat.com/show_bug.cgi?id=521322#c8. That was early evening PDT on Wednesday. There had been no Rawhide report that day, and there was no Rawhide report on Thursday, either, until 2100 PDT, which is 12 to 16 hours later than expected. Today's rawhide still does not fix it: https://bugzilla.redhat.com/show_bug.cgi?id=521322#c13. The no external progress [still broken even though the internal cause has advanced] from the fix for 520766 on Wednesday until today (Friday) overlaps closely with two-day slip in rawhide kernels from Tuesday morning until Thursday evening. To the extent that the GCC hiccup contributed to the lack of a Rawhide report kernel in that interval, then GCC is a direct cause. If I had relied solely on Rawhide report, then there would have been no progress from Tuesday morning to Thursday evening. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Graphics Test Week (ATI, NVIDIA and Intel graphics Test Days)
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1). Just in case there is a lull with nothing to do, please look at this existing crash-and-burn with an RV710: https://bugzilla.redhat.com/show_bug.cgi?id=521322 -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bugzilla Desktop Client
On 09/06/2009 07:52 AM, Fabian Deutsch wrote: Using smolt to generate and link to a HW-spec-summery would also be a nice and relevant option. Think hard about the implications for [non-]privacy, legal complications, etc. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On 09/03/2009 11:30 PM, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. ... The software does not understand Fedora gcc/g++ well. Just to get started, I had to add these to the command line: -I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1 \ -I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/x86_64-redhat-linux Then I got several dozen false positives (complaints that were incorrect) from my first file. How new is this software? -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
They do not claim to handle C++. They failed to generate the obvious error message upon finding C++ syntax. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora on NSLU2/Synology/etc.
I'm wondering if anyone tried to run Fedora on a small home NAS, in the class of NSLU2 or Synology 108j. I'm hacking on software that permits easy management of storage clouds and I'm thinking about creating a testbed populated with something cheap ($100 or so). Various embedded derivatives of Linux, and even full Debian, have been there for some years. It runs, slowly; fast enough for 1.5Mbit/s DSL, not fast enough for 12Mbit/s cable modem. Systems like WRT54GL (similar CPU speed as NSLU2) manage because the switch is in hardware. Don't even think of strenuous native software development on NSLU2. The NSLU2 is cramped and very slow, and is near end-of-life. Look into the SheevaPlug ($100; 4X as fast, 16X the RAM of NSLU2) http://www.globalscaletechnologies.com/c-2-globalscale-technologies-products.aspx or the TS-109 Pro II http://www.qnap.com/Products.asp Also http://www.gumstix.net/ for truly a truly timy system. For software start at http://www.cyrius.com/debian/ -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build requirements for threaded code?
On 08/19/2009 07:57 PM, Roland McGrath wrote: -pthread means -D_REENTRANT and -lpthread. -D_REENTRANT is basically useless and you should use standard feature test macros or _GNU_SOURCE for what you want. So just linking with -lpthread is what I would call the normal and recommended practice. On current Fedora with gcc+glibc(NativePosixThreadLibrary) this works today and has for some years. On some predecessor systems gxx -pthread was required for both compiling and linking. [gxx means gcc or g++.] On non-NPTL or non-Linux systems it may still be required today. Perhaps it may be required on future Fedora. Using gxx -pthread always is safe. At least, making it safe is a well- known part of the job of the maintainer of gxx. Using just -lpthread means that the user _assumes_ that compilation is independent of threading, or already has taken threading into account. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anaconda install askmethod
On 08/11/2009 05:35 PM, David Cantrell wrote: I just recently fixed a problem with askmethod not doing anything. If you booted from a CD or DVD but wanted to do a network install, the askmethod parameter was not working. That fix is in anaconda-12.12-1. It's still broken in anaconda-12.13 (rawhide of Tuesday, August 11.) https://bugzilla.redhat.com/show_bug.cgi?id=516973 -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: creating minimal boot image for network installations
Yanko Kaneti wrote: On Thu, 2009-07-16 at 10:05 -0400, Jeremy Katz wrote: Note that while kernel + initrd is all you need, not having the stage2 means we have to ask where to find it rather than being able to automate the use of the mirror list for everything Anything in particular that prevents the loader from using the mirror list to find a suitable location for stage2 ? ..other than no patches for it yet Especially for testing rawhide, I find that using the mirror list is problematic. Some mirrors sync quickly (a couple hours), others take significantly longer (*many* hours). I would rather specify the mirror explicitly. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
[benefit of prelink:] - almost all relocations a program has to perform are avoided. These can be very expensive when many dependencies and/or large symbol tables are involved. The latter is somewhat mitigated by the new symbol table hashing we implemented some time back but still. About 10% to 50% of the time on i686, this benefit of prelink is trashed by the randomization of the placement of [vdso], also known as linux-gate.so. If the page that the kernel chooses for [vdso] overlaps any pre-linked needed shared library, then ld-linux cannot avoid processing the relocations for that library. Often the cost snowballs as libraries that do not get their pre-linked pages are moved so that they interfere with subsequent libraries. [On x86_64 the vdso is at a special fixed address that cannot conflict.] Try this example from https://bugzilla.redhat.com/show_bug.cgi?id=162797 - for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do for k in 0 1 2 3 4 5 6 7 8 9; do ldd /bin/cat done done done | grep libc | sort | uniq -c - For current Fedora 11 on i686, I see a conflict about 10% of the time, involving only ld-linux, libc, and [vdso]. This means that glibc must be dynamically relocated about 10% of the time anyway, even though glibc has been pre-linked, and even though /bin/cat is near minimal in its use of shared libraries. When a GNOME app uses 50 or more pre-linked shared libs, as claimed in another thread on this subject, then runtime conflict and expense are even more likely. If time performance matters a lot, then the kernel must co-operate when placing the vdso. A patch to FC5 was submitted and adopted some years ago to offer the choice of: no vdso, random vdso, vdso just below STACKTOP, vdso just below PT_INTERP (namely, ld-linux.so.2), vdso just below main. Maintenance suffered because exec_shield was not in the kernel mainline. None of the choices is available today. Even the remaining comment in Fedora's kernel/sysctl.c [just after int exec_shield = (10);] is incorrect. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 anaconda incompatible with current F10 yum - WTF
Xavier Toth wrote: So I do a yum update, pickup a yum that isn't compatible with the original anaconda and then can no longer make installable DVD's. Depending on your exact requirements, the re-spins by the Fedora Unity project may be able to help you: http://spins.fedoraunity.org/spins The most recent one for Fedora 10 was on April 14. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
Jeremy Katz wrote: I need to sit down and figure out where [grub2] is in the realm of capability vs our grub[1] these days, but just haven't had enough round 'tuits. Next year (2010) is the year for new harddrives with a hardware sector size of 4096 bytes instead of 512. All boot loaders will have a fun time! -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
anaconda loses six versions from fc11 to fc12 ?
rawhide report: 20090605 changes Compose started at Fri Jun 5 06:15:04 UTC 2009 anaconda-11.5.0.53-1.fc12 rawhide report: 20090603 changes Compose started at Wed Jun 3 06:15:03 UTC 2009 anaconda-11.5.0.59-1.fc11 It looks like the versions from .54 through .59 were dropped in the changeover from fc11 to fc12. Version .54 was in: rawhide report: 20090520 changes Compose started at Wed May 20 06:15:04 UTC 2009 anaconda-11.5.0.54-1.fc11 so I hope that the work of two weeks can be recovered soon. (The changes were not in Monday's [20090608] rawhide report for fc12, either.) -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unbootable machine
H. Peter Anvin wrote:
Bernie Innocenti wrote:
On 06/02/09 03:43, H. Peter Anvin wrote:
Bernie Innocenti wrote:
Disk /dev/sdb: 2055 MB, 2055208960 bytes
221 heads, 2 sectors/track, 9081 cylinders
I don't know where fdisk, the Linux kernel, or whatever come up with
these kinds of geometries. They're almost universally non-bootable.
Ok, I wiped mbr and made fdisk create a new one:
Disk /dev/sdb: 2055 MB, 2055208960 bytes
64 heads, 62 sectors/track, 1011 cylinders
^^
Equally weird. The only standard ones are 64 heads, 32 sectors and
255 heads, 63 sectors.
Depends on your definition of standard. Anything with {1 = heads = 255,
1 = sectors = 63, 1 = cylinders = 1023} meets the requirements of many
BIOS that I have encountered. In particular, I have seen sectors/track of
2, 4, 28, 31, 32, 33, 47, 48, 60, 61, 62, 63, 128, 255 on booting drives
within the last two years. Picking one of my USB 2.0 flash drives, I find
a Fujifilm 256 MB instance with
128 heads, 4 sectors/track, 975 cylinders
--
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kernel module options for cpufreq
Richard Hughes wrote: In an ideal world we would: * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really want to be running this on all systems that support it * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed to something else by cpuspeed. You really don't want to be using USERSPACE at all. How can an administrator set a known constant frequency, so that the CPU might be able to deliver the same amount of work per unit time, over a span of half an hour? Some performance measurement and tuning is much simpler when this is so. -- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
speed up Firefox start by a factor of 3 on x86
The Firefox browser often takes 15 seconds to start because random placement of the vDSO page disrupts the pre-linking of the 133 shared libraries involved. (Fedora Core 5 Test 3, kernel-2.6.15-1.2054_FC5, updated by yum to today, 1.1GHz Athlon Plain, 768MB RAM, ext3 UDMA100 local disk.) Similar delays are encountered by any application that uses many or large shared libraries. In contrast, Firefox always starts in 5 seconds or less on a kernel which places the vDSO intelligently: just below the .text of ld-linux or the main executable. This preserves the benefits of exec-shield (including randomization, when prelink randomizes) without destroying performance. Want to experience the difference for yourself? These two kernels have only my patch applied on top of what will be released Monday as Fedora Core 5: (14MB) http://bitwagon.com/ftp/kernel-2.6.15-1.2054_FC5.jreiser.i686.rpm (14MB) http://bitwagon.com/ftp/kernel-smp-2.6.15-1.2054_FC5.jreiser.i686.rpm The source is (48MB) http://bitwagon.com/ftp/kernel-2.6.15-1.2054_FC5.jreiser.src.rpm (7KB) http://bitwagon.com/ftp/linux-2.6-x86-vdso-stacktop.patch While running, you can revert to FC5 standard behavior by using echo 1 /proc/sys/kernel/exec-shield See the .patch for documentation. This issue appears as part of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162797 --
