[SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

productninja · 2012-06-29 05:21:31

Greetings all,
I'm glad to say that this is my first post because previous installations (approaching 50 or more) have always gone slick as butter on various hardware configs. In particular, I've run a pure openbox config on this particular Dell E6400 for several months and decided rather than converting my MBR setup to a GPT scheme outright, I'd just fresh install and reconfigure - maybe dropping some hidden bloat along the way.

When things went sideways, I started over, and I've now stopped where I believe the problem manifests to make things clear.

500GB Sata Drive, clean
Arch NetInstall booted from USB

ip link set eth0 up
dhcpcd

pacman -Syy
pacman -S gptfdisk
gdisk /dev/sda

assigned new device guid and set up the partitions as follows:

sda1 = +2mb starting at block 2048 // intended for grub2-bios support
sda2 = +100mb // intended for boot
sda3 = +30gb // intended for root
sda4 = +150gb // intended for source code
sda5 = +50gb // intended for builds
sda7 = +8gb // intended for swap
sda8 = remaining // intended for home

I then completed a basic arch setup with base only, adding hostname and locale to rc.conf and uncommenting en_US.UTF-8 in locale.gen. Essentially following the vanilla steps outlined in the latest installation guide. I skipped the bootloader step per the grub2 wiki, and proceeded with grub2 install/configure/etc.

mount -o bind /dev /mnt/dev
mount -t proc /proc /mnt/proc/
moutn -t sysfs /sys /mnt/sys/
chroot to /mnt

ip link set eth0 up
dhcpcd

pacman-db-upgrade
pacman-key --init
pacman-key --populate archlinux
pacman-key --refresh

pacman -Syy
pacman -Syu

pacman -S grub2-bios

grub-install --directory=/usr/lib/grub/i386-pc --target=i386-pc --boot-directory=/boot --recheck --debug /dev/sda

grub-mkconfig -o /boot/grub/grub.cfg

Receiving no errors, I rebooted and observed no indication of anything amiss.

I created a local user with all the normal group assignments, /bin/bash as shell and modified the password.

I installed sudo and configured visudo per the norm, again with no issue.

I installed alsa-utils and configured and tested and stored settings without issue as well.

pacman -S xorg-server xorg-xinit xorg-server-utils xf86-video-nouveau xf86-input-evdev xf86-input-synaptics xorg-twm xorg-xclock xterm

pacman -S dbus
rc.d start dbus

#su - to local user
startx

Everything is still working as expected with no indication of any issue.

I added dbus as the first daemon, and added alsa as the last daemon in rc.conf and rebooted. I logged in as the local user, and I can't stress enough that all of the output to this point is congruent with past experience.

sudo pacman -S openbox nitrogen tint2 volwheel networkmanager network-manager-applet consolekit lxterminal

I edited the daemon's in rc.conf again to be: (dbus hwclock syslog-ng networkmanager !network crond alsa)

sudo touch ~/.xinitrc
chmod +x ~/.xinitrc

I edited the ~/.xinitrc to read (very simple):

 
#!/bin/sh
 # ~/.xinitrc
 exec ck-launch-session dbus-launch openbox-session

Then I created a basic openbox layout:

mkdir -p ~/.config/openbox/
cp /etc/xdg/openbox/* ~/.config/openbox/

nano ~/.config/openbox/autostart

The final file read:

  
nitrogen --restore &
if which tint2 >/dev/null 2>&1; then
  (sleep 2 && xcompmgr -Cc) &
  (sleep 2 && tint2) &
fi
volwheel &

rebooted, logged in as normal user and ran startx

.xinitrc ran successfully and the openbox autostart ran correctly. Tint2 was displayed, the volwheel applet was loaded, transparency was working, and after assigning a wallpaper via nitrogen, a reboot would reload the wallpaper.

HOWEVER:
1. no nm-applet (in the past, it was not necessary to specify this in autostart, but I also tried with nm-applet added to the openbox/autostart file)
2. from terminal ck-list-sessions shows nothing at all (not even an inactive session)
3. top doesn't show dbus-daemon, though a sudo rc.d restart dbus shows dbus stopping and restarting

In the previous attempt, I tried the various edits to polkit files with no observable change, and I tried full lxde, xfce4, gnome and awesome environments - always with the consolekit issue learing.

Long post, I know, but am I losing my mind here?

Odd things abound... In an even simpler test, I installed Terminus-font, verified the ter* fonts were in /usr/share/kbd/consolefonts, edited rc.conf to use consolefont="ter-116n" and consolemap="8859-1", added consolefont to the udev hooks in mkinitcpio.conf, ran mkinitcpio -p linux, rebooted (all showing no error) to find that the terminus font was substituded until the nouveau driver kicked in - at which point it fell back to the system default font.

I'm at a loss... any help, criticism, off-the-cuff-suggestions or pointing out some obvious step I've missed is appreciated at this point. This is as simple of a system as I can think of to "test" whether the session is launching correctly.

Great thanks -- MB

(edited for readability - logs and dot files can be posted to pastebin if they will help.)

Last edited by productninja (2012-07-04 05:31:10)

ngoonee · 2012-06-29 05:23:54

productninja wrote:

I'm at a loss... any help, criticism....

Please, use code blocks, that is unreadable.

productninja · 2012-06-29 05:28:50

I should have mentioned...
/dev/sda1 (2mb) is ef02 to support grub2-bios on GPT
/dev/sda2 (100mb /boot) is ext2 for the boot partition
/dev/sda3 (30gb /) is ext4 for the root partition
/dev/sda6 (remaining) is ext4 for the home partition
/dev/sda7 (8gb swap) is swap for the system swap
/dev/sda4 & /dev/sda5 are mapped to /usr/local/sandbox and /usr/local/builds and are both ext4 as well

There is really nothing special about this setup at the point it seems to break. I've scoured the wiki and forums for these specific issues and in all cases, ck-sessions-list seems to list a session but state it is inactive. I didn't find anything that resembled this particular behavior. I apologize in advance if I missed something obvious.

productninja · 2012-06-29 05:31:01

ngoonee wrote:

productninja wrote:
I'm at a loss... any help, criticism....
Please, use code blocks, that is unreadable.

I apologize. I wasn't putting it in the post as "code" and didn't think of what it would look like run together. I'll edit.

DSpider · 2012-06-29 10:12:39

2. from terminal ck-list-sessions shows nothing at all (not even an inactive session)

Do you have the consolekit package installed? And do you use a login manager or just plain startx?

Post your rc.conf.

Last edited by DSpider (2012-06-29 10:13:31)

productninja · 2012-06-29 13:50:21

Per my initial message:
I added dbus as the first daemon, and added alsa as the last daemon in rc.conf and rebooted. I logged in as the local user, and I can't stress enough that all of the output to this point is congruent with past experience.

sudo pacman -S openbox nitrogen tint2 volwheel networkmanager network-manager-applet consolekit lxterminal

I will post my rc.conf when I get to work this morning, but I literally tried to make as few customizations as possible. Beyond replacing network with networkmanager, adding dbus as the first item in the daemons list, adding alsa as the last item in the daemons list, and setting my locale/hostname, I did not change the rc.conf. This was also stated in my post.

productninja · 2012-06-29 19:00:32

(NOTE: Updated to include all configs from the working install. 3-Jul-2012)

Here are the configs that I changed or might be relevant:

/etc...
/etc/inittab
/etc/locale.gen
/etc/mkinitcpio.conf
/etc/slim.conf
/etc/rc.conf

$HOME
~/.xinitrc

Last edited by productninja (2012-07-04 05:30:00)

cfr · 2012-06-29 22:09:50

I notice that you are telling the system to use $LOCALE for daemon startup but that you are setting this to nothing. Maybe that is upsetting something?

Note: I realise it should work anyway by falling back to defaults but...

Is there a spurious new line in ~/.xinitrc? (Line 11 looks as if it should be the end of line 10?)

Last edited by cfr (2012-06-29 22:19:07)

jjacky · 2012-06-29 22:14:39

productninja wrote:

I edited the ~/.xinitrc to read (very simple):
 
#!/bin/sh
 # ~/.xinitrc
 exec ck-launch-session dbus-launch openbox-session

You know that's not what your .xinitrc looks like here: http://pastebin.com/v4RwR6k2 There you just have:

exec openbox-session

productninja · 2012-07-04 05:02:36

First off, apologies for not paying attention to the files as I put them on pastebin...

jjacky - I was actively trying to debug and went through several permutations of using display manager (LXDM/SLiM) and not, also setting Locale and not. I knew the reason for all my troubles boiled down to consolekit, and (being an app developer yet still amazed at both scripting-voodoo and lower-level system magic after all these years) I was quite literally trying everything I could think of to get a session going. Unfortunately, all my efforts were in vain - save getting an intimate look at some internals I hadn't bothered to really understand previously. That part was invaluable.

cfr - this was a similar oversight. I turned the daemon on, turned it off, set locale, didn't set locale... I just pasted at the wrong point in time.

I created and reviewed the .xinitrc in vi, and I did check for "gotchas" such as cfr mentioned. That wasn't it, unfortunately. Ego aside, I always like a good *doh* moment when I'm down the rabbit hole as far as I was.

I'm going to mark the thread as solved, since after repeating the install process everything seemed to work right away. I'm still quite befuddled (yes, not a word) at how three to four consecutive attempts yielded the same disastrous result and this final one did not, but I'm going to have to let this one go.

I will update the pastebin urls with the current, working configs in case anyone stumbles upon this thread with the same issue.

I know this one came out of left field, and I appreciate all the suggestions. Arch remains the best system and best community around in my opinion, and I'll do my best to start participating more to answer questions I DO know the answer to.

Thanks again guys.

Arch Linux

#1 2012-06-29 05:21:31

[SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#2 2012-06-29 05:23:54

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#3 2012-06-29 05:28:50

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#4 2012-06-29 05:31:01

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#5 2012-06-29 10:12:39

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#6 2012-06-29 13:50:21

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#7 2012-06-29 19:00:32

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#8 2012-06-29 22:09:50

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#9 2012-06-29 22:14:39

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

#10 2012-07-04 05:02:36

Re: [SOLVED] Befuddled - New Install, Reliable Old Method, Virtual Failure

Board footer