Re: [Bug 5759] glxgears killed on hardened system with DRI
Recently, Somebody Somewhere wrote these words The enclosed may be of interest to the list, as it seems to have implications for the build of X > > https://bugs.freedesktop.org/show_bug.cgi?id=5759 > > > [EMAIL PROTECTED] changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution||WONTFIX > > > > > --- Additional Comments From [EMAIL PROTECTED] 2006-02-14 19:00 --- > Hardened systems must use the generic 'linux-dri' profile when > building Mesa instead of linux-dri-x86. The asm optimizations > enabled by the -x86 profile are probably prohibited by grsec. > > This has been discussed many times and won't be fixed unless a > patch is provided that is both: > > - hardened-clean (for whatever that means this week) > - an improvement in performance relative to linux-dri > - ideally an improvement in performance relative to linux-dri-x86 AFAICT, enabling all DRI options on an X build gives an x86 box linux-dri-x86 in Mesa. I am not the expert here. I have not got dri to function without rebuilding Mesa after rebuilding X anyhow, although I don't know if it was 100% necessary. paxctl -m /usr/bin/glxgears solved it locally here for me, and glxgears compiled under hlfs works, as the pax flags have been modified on the binary. -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg -configure Duplicate symbol (6.8.2)
Recently, Somebody Somewhere wrote these words > > Just for the fun of it, ...meh, I have recompiled 6.8.2 with a > new buildscript. (the buildscript has been filled with the HLFS > xorg-6.8.2 build commands, copied from the page, so no typos (of > mine) ) Again, Xorg -configure failed, so I tried 6.9. I'm not > sure if I understood your post correctly. I have tried with > either of your gcc specs files in /usr/lib/gcc/2.6.14.6/ and > have built 6.9 with the same 6.8.2 buildscript, except for the > patches. The nonow patch could actually be applied, but I'm not > sure whether I still need to with these spec files. So in total > I have run four compilations of Xorg 6.9 now. With and without > the -nonow patch and with either the specs file or the specs.old > file. > > Unfortunately, the build fails with this error: > > gcc -m32 -o xdm -O2 -fno-strength-reduce > -fno-strict-aliasing -march=i686 -ansi -Wall -Wpointer-arith > -Wundef -L../../exports/lib auth.o daemon.o server.o > dpylist.o dm.o error.o file.onetaddr.o reset.o > resource.o protodpy.o policy.osession.o socket.o > streams.o util.o xdmcp.o mitauth.ogenauth.o > access.o choose.o prngc.oxdmauth.o rpcauth.o > greet.o verify.o Login.o -lXpm -lXmu -lXt -lSM -lICE -lXext > -lX11 -lXt -lSM -lICE -lXext -lX11 -lXau -lXdmcp -lrpcsvc > -lcrypt -lXinerama-Wl,-rpath-link,../../exports/lib > /usr/bin/ld: cannot find -lrpcsvc collect2: ld gaf exit-status 1 > terug make[4]: *** [xdm] Fout 1 make[4]: Leaving directory > `/usr/src/xorg/xcbuild/programs/xdm' make[3]: *** [all] Fout 2 > make[3]: Leaving directory `/usr/src/xorg/xcbuild/programs' > make[2]: *** [all] Fout 2 make[2]: Leaving directory > `/usr/src/xorg/xcbuild' make[1]: *** [World] Fout 2 make[1]: > Leaving directory `/usr/src/xorg/xcbuild' make: *** [World] Fout > 2 > > (I do have /usr/include/rpcsvc/) > > What have I missed? I think it's in ~/xcbuild/programs/xdm/Makefile RPCLIB = -lrpcsvc Just delete it. grepping for RPCLIB sorts you out. The other gotchas: http://www.linuxfromscratch.org/pipermail/hlfs-dev/2006-January/002705.html Instead of Kevin Day's Mesa patch, I ended up with the one from here http://bugs.freedesktop.org/show_bug.cgi?id=4197 And although I may not have made it clear, I followed the Xorg-6.8.2 page from the book pretty completely. You don't actually need any of the 6.8.2 patches for 6.9.0, as the developers have largely adopted them. But the sed commands before, & methodology are all similar. There is a later set of instructions in January which include DRI http://www.linuxfromscratch.org/pipermail/hlfs-dev/2006-January/002745.html and you might even get lucky. I got DRI only to discover the video card I have is useless. -- With Best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg -configure Duplicate symbol (6.8.2)
Recently, Somebody Somewhere wrote these words > I have been playing with this for a while, but there seem to be a few > differences in the HLFS system I have and the one you used to build > Xorg6.9. The mesa patch, for instance, fails. > > package xorg:/usr/src/xorg/xc/extras/Mesa> patch -Np1 -i > /sources/mesa-6.4-pic-notextrel.patch > patching file configs/linux-dri-x86 > patching file src/mesa/x86/glapi_x86.S > Hunk #1 succeeded at 81 (offset -1 lines). > Hunk #2 FAILED at 92. > Hunk #3 succeeded at 92 (offset -12 lines). > Hunk #4 succeeded at 107 (offset -12 lines). > Hunk #5 succeeded at 131 (offset -12 lines). > 1 out of 5 hunks FAILED -- saving rejects to file > src/mesa/x86/glapi_x86.S.rej > patching file src/mesa/x86/mmx_blend.S > patching file src/mesa/x86/mmx_blendtmp.h > patching file src/mesa/x86/read_rgba_span_x86.S > package xorg:/usr/src/xorg/xc/extras/Mesa> > > Not sure whether that matters as I haven't encountered an error with any > opengl stuff (yet). Actually that doesn't matter. One hunk failed on me as well. This battle is in January's archives, blow by blow. > I also do not have the CONFIG_PAX_NOELFRELOCS kernel option. > I checked the required patches for HLFS, but I haven't seen it in > there as well. I guess you got it yourself somehow > (or the name changed). It's in the Pax security patch for the kernel, under non-executable pages. It prevents code from relocating. As executable position is randomised, non pic code (like assembler) can't run, because Pax won't allow the kernel to relocate it. At least that's what I thought it did. > > So I just went ahead with the normal 6.8.2 book page, except for the > patches. > I used the checktextrel script, but didn't find anything with textrel in > it. I guess that is a good thing then. > When running "make World" I'm getting this error: That is the agpgart.h error I may have mentioned. Mail has a very short life here, but this might be the solution http://linuxfromscratch.org/pipermail/hlfs-dev/2006-january/002659.html That link isn't working in lynx. Bah! I'm reading the link off mozilla. Those sed commands give you a level less of interpetation in agpgart.h and the build goes through. That's probably the last error you'll get. But you may not have dri. -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unbootable
Recently, Somebody Somewhere wrote these words > Hi list, > > I'm new to this list (and hence cannot reply to an earlier mail), but I > searched the archive and came across an earlier mailexchange dealing > with the fact that SVN-20060220 appears unbootable. > > I have exactly the same problem: The error message is the same, the > version is the same, the setup is (almost) the same: To get familiar > with the processor, I too started off with VMWare. I've spend a couple > of weeks trying to make that work - to no avail. I then tried it out on > the target machine instead, but with precisely the same, sad result. > Both the machine hosting VMWare and the target machine runs fine with > other systems, so maybe there _is_ a problem somewhere? > > On the other hand, I've had similar problems with a basic kernel > upgrade to 2.6.14.6, so maybe that's the culprit? > > Which brings me to my last question: Where do I get hold of an older > version of HLFS? The previous version appears to be adequate for me. > > Regards, > Lars > The book is apparently behind, but the archives are searchable. I have 20051220 (The book) if you want that. I'd sooner see the error on your box. Most Mail has a life expectance of 2 minutes or so here. The real box error please, not the vmware box. Going backwards at this stage is bad news, because fundamental things like the arc4random patch have been fixed since then. I would suggest taking the gcc version back if you built with 4.1. If you have any other system, I would also try booting HLFS on a different kernel, and vice-versa. -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Glibc & Localedef (was...Chapter 6 coreutils-5.94)
On Sat, 2006-05-27 at 04:31 +0100, Declan Moriarty wrote: > On Fri, 2006-05-26 at 18:40 -0400, Robert Connolly wrote: > > On May 26, 2006 01:35 pm, George Boudreau wrote: > > > If Robert says he has built a > > > hlfs(svn)-> hlfs(svn) then that is the end of the story and I will look > > > at my setup. > > > > I have, but it was quite a while ago. Most of my builds are with uclibc. I > > think I did rebuild hlfs glibc, from hlfs, but I may have rebooted with > > some > > or all of the grsecurity options disabled. I noticed there is a > > glibc-localedef-segfault patch in the patch repository, but I haven't tried > > it. localedef was crashing when I rebuilt glibc on hlfs, which is maybe why > > I > > disabled grsecurity. So many things have changed since then, its hard to > > say > > why you are having difficulties. /Finally thinking here Think about this. No patch will work, unless it's been in the works so long that it part of the accepted build. The reason is, glibc crashes out in building chapter 5, which uses the _host_ system's localedef. If the host system is (security enabled) HLFS-0.1, this stage will fail. HLFS-0.1 did not have a (working) patch for localedef to overcome this problem, so your stated target of building hlfs-0.1(20051220) --> hlfs-0.2 will not work this way. That hlfs book had a few mentions of the problem. It appears in the changelog for May 7th 2005, well before my interest in HLFS. Also on January 27th 2005, where paxctl was added to cope with this issue. The detail is, (AFAIK) that this CONFIG_PAX_EMUTRAMP in the kernel (which I have) provides system wide protection. The workaround for system builders would be not to have this set system wide, but to use paxctl to enforce it on a per binary basis. This does not protect against a foreign binary with no PAX header, which is definitely _NOT_ what hlfs is about. HLFS is about shutting doors, not opening them. But check any advice I give you on Security! Would not the handy way around this be to put up a tarball for download of the Minimum set of locales for the current glibc to pass the tests (in ch 5). Then patch the localedef in /tools, and don't install the one in glibc unless you can tidy up it's behaviour to make locales in a restricted environment. Either that, or change your glibc instruction set significantly. Anyhow uclibc seems the easier ride. BTW, please tidy up the kernel instructions on that CONFIG_PAX_EMUTRAMP -- With Best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Toolchain upgrades
On Mon, 2006-05-29 at 00:18 -0400, Robert Connolly wrote:
> I have attached my preliminary/experimental differences to build HLFS with
> gcc-4.1.1 and glibc-2.4. Comments are welcome.
>
That's a whole pile of good work, and behind that is a lot of
frustrating unseen hours.
I am going to run with that down the uclibc route when I get a minute
(Mebbe Wednesday) and see how far I get.
--
With Best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udev-114 progress with uClibc
On Wed, 2007-08-15 at 10:43 -0500, Kevin Day wrote: > Okay, so I finally found out how to make udev's > 094 boot under a > uClibc system. > > During the boot process prior to loading/starting udev, I have the > following command happening: > echo /sbin/udevtrigger > /proc/sys/kernel/hotplug > This works in udev094, for whatever reason it now causes udev to lock > up and not produce proper devices. The end result is system does not > boot and sits there. > > The solution was to change this to: > echo '' > /proc/sys/kernel/hotplug > > and suddenly the system boots. > I worry that this will cause modules to not be auto-loaded when plugged in. > However, this is a step forward into solving the problem. > > Its quite hard to tell if it will or won't work considering how much > udev changes and how much udev has no documentation whatsoever by the > udev team. I have always distrusted udev and particularly hated hotplug, and abide them with great unease on any system. It seems my guts were correct ;-). -- With Best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
compiler skewed?
I am getting an irritating number of compiles dying in hlfs, and
am beginning to presume the problem is me. I just ran off to
another system and the kernel compiled _no_hassle_ :-(. I did
remember to switch off the grsecurity options as instructed.
Feedback on xorg-7.0.0 is poor - compiling is awkward to put it
mildly, nobody has come up with a Makefile/Imakefile yet, no
instructions are around, and generally the install stage sucks.
READMEs are zero bytes, patches don't fit and if you want to do
something clever you're in for a bit of work.
DRM drivers:
CC [M]
/usr/src/extras/Mesa-6.4.1/radeon-20051220-linux.i386/drm/linux-core/drm_context.o
/usr/src/extras/Mesa-6.4.1/radeon-20051220-linux.i386/drm/linux-core/drm_context.c:
In function `drm_ctxbitmap_next':
include/asm/bitops.h:289: error: can't find a register in class
`BREG' while reloading `asm'
make[3]: ***
[/usr/src/extras/Mesa-6.4.1/radeon-20051220-linux.i386/drm/linux-core/drm_context.o]
Error 1
make[2]: ***
[_module_/usr/src/extras/Mesa-6.4.1/radeon-20051220-linux.i386/drm/linux-core]
Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.14.3'
make[1]: *** [modules] Error 2
~~
Kernel compile (2.6.14.3), SVN-20051221 book instructions.
CHK include/linux/version.h
CC init/main.o
init/main.c: In function `unknown_bootoption':
init/main.c:249: warning: asm operand 1 probably doesn't match
constraints
init/main.c:249: error: impossible constraint in `asm'
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
This bit of init/main.c - Line 249 is 'BUG();'
/* Change NUL term back to "=", to make "param" the whole
* string. */
if (val) {
/* param=val or param="val"? */
if (val == param+strlen(param)+1)
val[-1] = '=';
else if (val == param+strlen(param)+2) {
val[-2] = '=';
memmove(val-1, val, strlen(val)+1);
val--;
} else
BUG();
}
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: compiler skewed?
Recently, Somebody Somewhere wrote these words
> Declan Moriarty wrote these words on 01/09/06 10:17 CST:
>
> > BTW, X11R7 was a _dreadful_ idea as an installation location.
> > You'd be amazed how many things have X11R6 coded in.
>
> ln -s X11R7 /usr/X11R6
>
That was done, I assure you. The best bit of /usr/X11R7 was that
ir facilitated a quick & simple rm -rf instruction when my ardour
cooled over Kevin's scripts.
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Compiling Modular Xorg 7
Recently, Somebody Somewhere wrote these words > > minimal is mostly complete, I am having trouble finding which package > installs the program 't' so the fonts can > use. At the last minute I noticed a couple of > libraries that may fix that. So it may work. > I'm here with the same code tree installed, and there's no program called 't' in /usr/X11R6/bin. I'll sent you a locate output if you really want suffering, and you can read it yourself. If you haven't got past the module loading error (Now bug #5585) it will be academic to install, because of the brokenness of dlloader on hardened systems. If that's beaten, Tell me how! This manifests in that you can't load video modules. Last news, I sent ajax a couple of ways to catch a hardened compiler, namely the lines in host.def and the stuff robert sent. I reckon 6.9 is going to be the easier build, this time. -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: java under hlfs
Recently, Somebody Somewhere wrote these words
> Has anyone tried the precompiled Java I made, or the Java build
> instructions? I really would like to hear some kind of signal that they
> work for someone else than me only.
>
Give us time :-).
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
