You are not logged in.
Pages: 1
I installed a lxinput I think, but off the top of my head I can't think of anything else. To rule out user config problems I created a new user account, but get 'Failed to execute login command' when logging in.
Edit: xinit openbox seems to work (albeit the autostart file isn't executed), but not startx. There isn't an .xinitrc in the skel directory, so I'm assuming it's fine that there wasn't one in my home. Regardless I created one with exec openbox-session and startx now works and launches me my standard desktop. Still not sure why Slim isn't working though...
Crunchbang Waldorf install with systemd and Liquorix 3.8. Went to boot up the system this morning and after login I am greeted with the blank grey Slim background - can't get it to load Openbox. I don't think I installed or updated anything yesterday so I'm not sure what's triggered this.
What I've tried:
Uninstalling systemd and using init. Updating Nvidia drivers with smxi. Starting X manually from a tty (just got a black screen). Commenting out clippit in autostart.
slim.log
xsession-errors
Xorg.0.log
xorg.conf
Any help would be appreciated. Thanks.
I don't think going down the LFS route would be a wise option - low-level stuff is best left to the people who know what they are doing. Which is why the custom distro I had in mind would be better off piggy-backing off an existing minimalistic distro such as Arch or #! where security and feature enhancements are taken care of by proper developers leaving one free to implement and adjust the features needed to make the distro suitable for its intended purpose.
That said, I was rather pleased with myself for getting a partly-functional LFS system working a while back 
That looks like a brilliant place to start - thank you very much for your contribution 
Hello good people of #!, after a small break I'm back to good old Arch and #! (alas only in VM).
Being the overly-ambitious person I am I have always pondered on how it is new distros are created, and before sense gets the better of me, it is something that I would like to have a go at some time in the future. But that is a long way off and I talk solely from a hypothetical point of view.
I can see how a Live CD is made, it is essentially a system image of an existing install of a certain distro tweaked to ensure it will work on generic hardware. But how is it that a distro can be installed locally? Is it just an extremely elaborate shell script which takes a very minimal Linux environment (much like the default Arch linux) and configures everything manually?
I have tried researching this in the past but I fear I am not searching for the correct thing as I could not find any info that was not LFS or SuseStudio.
Any pointers would be greatly appreciated, thank you 
I am hoping to be able to install some of my games again under Wine - something which was working ok on Arch - but I can't get anything to work in Crunchbang.
I've installed Play On Linux from the repos, and tried installing Steam, but it's not having it at all. For some reason it wouldn't output the entire thing to a log file either. So the start is here:
PlayOnLinux v3.7.6
Checking python : [ Ok ]
PlayOnLinux-wine-1.3.19-64b.pol: OK
PlayOnLinux package manager 3.7.6
Opening PlayOnLinux-wine-1.3.19-64b.pol
Extracting PlayOnLinux-wine-1.3.19-64b.pol...
Running ...
Cleaning ...
Overriting DLLs
All done, errors in processing 1 file(s)
Overriting DLLsAnd the rest was grabbed via a screenshot:
I've tried running as root to see if it would resolve any of the permissions errors but no such luck.
Any ideas?
Thanks ceph, I'll try and get that up and running tomorrow. Having problems getting xnoise installed. It's not in the repos so I went and got the source from the Google Code website, unzipped, ./configure, but when I hit MAKE it tells me there is no makefile. Any clues?
[EDIT]
Stupid me, forgot to get build-essential.
[EDIT2]
Forget that, I do have it. Here's my output:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for valac... no
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XNOISE... noI'll be sure to give it a look. Thanks for the suggestion!
Just popping by to say hello to everyone after finishing my #! install. My OCD got the better of me after I got p****d off with the latest Ubuntu upgrade eating up in excess of 900MB, add a buggy Banshee player with a memory leak (apparently the bigger your library the bigger the leak gets, 15,000 songs + Banshee doesn't look like a good combination then!) I wiped my HDD several times (ensuring it was squeaky clean to satisfy my OCD) and set about installing #!. A few minutes and 120MB RAM later, one happy user!
I got quite a negative reception when I joined the Arch forums, and I'm hoping the atmosphere isn't as bigoted here as it is over there (though from what I've seen it looks like there's a great bunch of people here). I'll be using my machine for development work and the occasional bit of gaming. On that subject, what would be the most stable config to use? I had a PlayOnLinux setup configured before, but it was a bit unstable - would straight wine be a better option?
Anywho, I'll cut it there. Thanks for this great distro and hello!
Regards,
Mike
Pages: 1
Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.