You'll need to install the kernel headers pkg (# pacman -S linux-headers)
The modules support multiple kernels - thats why the headers pkg is not a hard dependency.
The following command should install the headers and then re-install, then build, the modules via dkms
pacman -S linux-headers virtualbox-guest-dkms
a tricks :
[[ -z $DISPLAY && $XDG_VTNR -le 3 ]] && exec startx
with this, you can log on from the first 3 tty. if you change the number 3 by 10, you can log on from the ten first tty and so on
Nice - much better. Thanks!
rearden - I'm not sure if mrgreen is doing some magic behind the scenes but it's probably being automatically logged in via /etc/inittab
Edit that file (as root) and look for the TERMINALS section. One entry will be modified (with the original hashed out) - you'll need to flip that (so the line with the username gets hashed out and the original line that matches the others is restored)
Once you've edited (and if you're unsure, make a copy) reboot. The bash profile entries might already be there depending on how you set the account up. It should at least stop the automatic login.
Technically, you don't need to reboot, you could just drop to runlevel2 and then back up to runlevel3 but you probably want to test it properly.
Word of warning - messing up inittab can render the O/S unusable without an alternate way to boot up and mount the hard drive... nothing that can't be recovered but bear it in mind.
Easiest way, IMO, is to remove any kind of login manager so you're presented with a regular text based login when booting up. Then add the following to your .bashrc
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx
You may have to adjust the VTNR number if OpenRC doesn't default to tty1 (but I think it does)
Obviously, X will only work with your login (but you could add it to /etc/profile.d/whatever.sh and I don't see why it wouldn't work for all)
In reading the bug report, it seems that it's a problem with the order in which pacman installs the pkgs.... so it upgrades readline (which breaks lvm) then upgrades the kernel and finally upgrades lvm but the kernel hooks in mkinicpio were built against the older lvm.
I think all Arch installations that use lvm would be affected regardless of init system.
Would such a terminal need something like compton to work? Certainly know what you mean, might be worth looking at....
You're right, it would - didn't think of that... I'm using compton-git because the regular compton in the repo took up about 20% CPU all the time (compton-git is negligible)
Xcompmgr is also available but only seems to get an update every 3 years.
I just ran the script and it gives output like:
meaning 3 emails in total, 2 of which are unread
If you just want to see the number of new you can change line 25 to be
print(total - seen, 'new')
New output is
For what it's worth, I'd say it's worth changing lines 16 and 28 too
Might be better as
print('failed to login')
Line 28 might be better as
print('failed to get new count')
Just makes it a bit more obvious where the script fails if/when google change something
It might mess up your conky display if you have specific widths set so it's purely a cosmetic issue but it's nice to know what part of the script is bombing out
I don't know what is going on but:
$ grep ^depends kio/PKGBUILD depends=('solid' 'kjobwidgets' 'kbookmarks' 'libxslt' 'kwallet' 'desktop-file-utils' 'kinit') $ grep ^depends kinit/PKGBUILD depends=('kio')
So, kio depends on kinit and kinit depends on kio hence your dependency cycle.
I think you've got to wait for a version bump in the Arch repo
"[root@archbang ukki]# packer -Ss 7610
bash: packer: command not found
[root@archbang ukki]# pacman -S packer
error: target not found: packer
This is the classic Arch catch 22.
To easily install something from AUR, you need an AUR helper which is only found in the AUR.
You can find an easy way to install packer here
But you might have to adjust it for dates. It's really worth understanding what is going on in the background here too. Essentially, you're grabbing source code, compiling it and then installing.
There's also a packer install script somewhere in the ISO and it's always a good idea to read it to see what's going on
I don't have an answer but this question looks very much like what someone on the Arch forum reported
https://bbs.archlinux.org/viewtopic.php … 0#p1634420
May be worth keeping an eye on that thread or downgrading anything network related from the previous upgrade
One thing to remember is that linux (and unix) go by UID and the name associated with it (clive or ABLive) is based on the mapping in /etc/passwd
I'd verify your entries in /etc/passwd
$ grep live /etc/passwd
Make sure your home dir as set there matches what you think it should be
I love Archbang the way it is
Now that you've installed, you just need to continue to update regularly and you'll be fine. The only problem you'll have is if you try to re-install from the last systemd based Archbang ISO in the future. This is because the first update you do will *probably* find a few conflicts and so on and it gets to the point where re-installing is quicker than fixing.
$ sudo pacman -Syu
This will update your repositories and upgrade any existing installed packages
$ sudo pacman -Ss brasero
This will search for brasero in the repo
$ sudo pacman -S brasero
This will install brasero
This page, while it's really a comparison of pacman to other package managers, has all the commands you'd ever need until you're at developer level
pacman -S --needed base-devel git --noconfirm
:: There are 26 members in group base-devel:
:: Repository core
1) autoconf 2) automake 3) binutils 4) bison 5) fakeroot 6) file
7) findutils 8) flex 9) gawk 10) gcc 11) gettext 12) grep 13) groff
14) gzip 15) libtool 16) m4 17) make 18) pacman 19) patch
20) pkg-config 21) sed 22) sudo 23) texinfo 24) util-linux 25) which
:: Repository openrc-eudev
Enter a selection (default=all):
Looks like you hit <return> for all here but you have I think you need to select everything *but* #24 (which is provided by #26)
that will run ./script if ./script is on the remote server. I guess if you want to leave it running something like this would work
ssh user@remote "nohup ./script" &
If ./script is local you'll need something like:
ssh user@remote 'bash -s' < ./script &
All thoroughly untested of course
Depending on the situation you might find something like tmux a better fit
ssh to remote... run tmux... detach session... exit. The script will keep running and you can re-attach at a later date (assuming the remote box doesn't reboot)
If you're not sure then you're almost certainly not using it.
A quick search of other sites suggests that it might be a BIOS issue... look for settings like 'always on USB' or 'wake up LAN' and try toggling them. Sorry, but you might have to search for your motherboard and 'can't shutdown' on google
I would guess that the HDMI card is the default and that's (probably) not what you want.
It's been a while but I think you need to create a file called /etc/asound.conf with the following
defaults.pcm.card 1 defaults.pcm.device 0
If it doesn't work after a reboot, look for 'alsa default hdmi ALC892' or variations thereof in google (or try toggling the device 0 for device 1 - basically look at the output from aplay -l and work accordingly)
I've always wondered if it was the developer who asked to implement this policy or if it was the moderators who farts a lead
I understand that with that many users they need structure and rules but it seems like new users are treated with suspicion rather than embraced. I should add that not all the mods/admins are like this though and most are friendly and helpful - you just tend to remember the harsh ones.
Sometimes when reading through there I feel like this:
"NON PURE-ARCH USER!"
The 512MB FAT32 partition makes me think you have a UEFI/GPT setup. If so (and /dev/sda1 is / ) you could possibly try something like this (but there are assumptions so don't take it as a precise guide)
boot off a live image live$ sudo bash # mount /dev/sda1 /mnt # mount /dev/sda3 /mnt/boot # arch-chroot /mnt /bin/bash
At this point you'll be 'in' your installation and you should be seeing the usual /usr, /var /etc structure and you can pick up the Arch install guide at https://wiki.archlinux.org/index.php/Be … oot_loader
When done, exit out from the chroot with 'exit' and reboot
I don't have UEFI/GPT so it's a little bit of guesswork on my part. Hopefully someone else can offer a more conclusive solution
Mr Green wrote:
Start archbang via USB live then try mounting your internal hard drive, then check if system files are present. Missing operating system sounds like you have either mounted the wrong device or installed to USB drive.
If a bootloader was present you would at the very least get a prompt or a different error.
Thats where im having an issue, im only able to mount singular partitions of my drive not the entire drive itself. When i try to mount /dev/sda i get "mount: wrong fs type, bad option, bad superblock on /dev/sda missing codepage or helper program, or other error."
That's not an issue :-) It's to be expected that you cannot mount the whole disk and only the individual partitions.
I agree with Mr Green - it sounds like a bootloader didn't get installed for whatever reason or possibly that you said to install to a partition and didn't set the partition as bootable in fdisk
What was your partition layout (fdisk -l /dev/sdX)?
What bootloader did you want to install?
Did you install it to the MBR or a partition?
Possible problem might be order of plugins...
You can number them like:
and so on.
If you iterate through [0-99]* you can let the numbering scheme define the order. (Basically the old sysV init method of starting scripts)
Basically I'm using a dark theme so one would think that when i open it normally from openbox menu, xfce4-panel, or even terminal it would be dark themed but it is not. the only way i can get it to show up dark themed is opening it through the octopi-notifier.
I just installed octopi and when I run it from the notifier, it launches it with a -style flag
octopi -style gtk
Maybe try launching it via the notifier, then run a ps to see what flags are called - then adjust the openbox menu item to match
Just a guess because I don't use octopi but I would assume it needs root permissions somehow. I would assume it's calling sudo but, TBH, I would have said the problem would be the other way around where it looks correct from the menu and not the notifier.
Try running it from the notifier and then issuing a ps and see if you can see exactly how it's called. Then do the same from the OB menu.
Here's some useful flags for ps so you can see the full output
ps aux | less -+S
edit - what I'm getting at is I suspect one method is not getting your environment settings
I've never had any luck with 'make live' programs. The only thing that works for me 100% of the time is dd (and do double-check the output file destination (the of= part) - it *will* happily destroy whatever you already have there with no confirmation)
# dd if=/path/to/your/iso of=/dev/sdb bs=1024k
This may not help if you're in a catch-22 situation of needing linux to run dd
Can you boot from optical disk?
There was just one thing: My computer could not handle both watching/listening to youtube video's and playing webgames, while simultaneously program on eclipse. :-(. Eclipse was especially slow with scrolling.
Your questions are beyond my skill set but I would start here. What was the constraint? CPU, RAM, disk I/O?
Could so it as a script but I think the person wanting to compile from AUR probably shouldn't have it obfuscated. One compromise which may be overkill would be to do something like this:
echo 'Creating a temporary directory in /tmp using "cd $(mktemp -d)"' cd $(mktemp -d) sleep 3 echo 'Installing any missing packages needed for compilation using 'pacman -S --needed base-devel git --noconfirm'" pacman -S --needed base-devel git --noconfirm
And so on... just so people know what's happening and can understand the procedure
$ cd $ sudo pacman -S --needed base-devel git $ git clone https://aur.archlinux.org/packer.git $ cd packer $ makepkg -is
The steps mean:
1) Go to your home directory
2) Install any missing pkgs that might be required in order to compile apps from AUR
3) Clone the packer code
4) Change to the newly created packer directory
5) Create a packer pkg, install any dependencies (from the repo) and install the packer pkg
$ cd $ rm -rf ./packer.git
6) back to your home dir
7) remove the source
Be aware that AUR packages will not be placed in /var/cache/pacman/pkg so you will be removing the actual "pkg" file by running step 7 (but this does not mean uninstalling it)
Both firefox and orage are GTK3 apps so that *may* be the common denominator. Not sure why they would cause tint2 to crash though.
Could you try killing tint2, then starting from the command line, then launching FF. When it crashes hopefully something would be written to the terminal
Another option is to move the tint2rc file to tint2rc.backup and launching with just a vanilla config. This would eliminate something in the conf file causing an issue
You *might* be running into an issue with the latest version of dhcpcd
If you recently upgraded to 6.10 try a downgrade and then look here for more info
https://gentoo.org/support/news-items/2 … mples.html for more info
@ i don't care lol, i say what i have to say, they either agree or not, it was my last post on their forum, people will make their own opinion. Say " AUR is arch but package in AUR is not the responsability of arch" is completely contradictory but it describe the arch philosophy clearly lol.
It is a bit of a contradiction but I see the gains in doing it that way. They have the analytical advantage of seeing what non-repo apps are being used and promote them to real repos (via download stats or votes)
This will look for installed packages containing 'virtualbox'
$ pacman -Q|grep -i virtual
This will search the repo for packages containing 'virtual' regardless of whether they're installed or not
$ pacman -Ss virtual
This means you can build commands to do more complex transactions (the extra 'q' in the Qq flags means to drop the version number from the output):
pacman -Rns $(pacman -Qq|grep -i virtualbox)
This looks like the version of glibc that compiled the server.lin binary doesn't match or is incompatible with what you have installed.
If you step through the output, it's all good until this:
olicenseserver.lin: loadlocale.c:131: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE))' failed. ++ pidof olicenseserver.lin
"pidof <whatever>" should be returning the PID but since nothing comes back I'm assuming the spckssq86 binary is the thing complaining about the missing argument. The locale/glibc thing is the root cause though and it's not something you can easily fix on Arch (and it would defeat the object of Arch to get it running)
TBH though, some of the output still doesn't make total sense to me
What if you just run "sudo /etc/init.d/OLicenseServer.sh start"
You're doing the installation part manually by creating the /etc/init.d and creating the service file so the 'install' script shouldn't have to be run. However, you're also trying to launch a binary that might have requirements not met.
This it going to make things a little more complicated since you need to set environmental variables and the appropriate way is to use /etc/sysconfig/*
It's probably easier to adjust your systemd service file to be something like this
$ cat /etc/systemd/system/etcinitd.service [Unit] Description=startup scripts [Service] ExecStart=/etc/init.d/main.script [Install] WantedBy=multi-user.target
Then create a script called /etc/init.d/main.script
$ cat /etc/init.d/main.script #!/usr/bin/bash for script in /etc/init.d/*.sh do $script start done exit 0
And finally put the OLicenseServer in /etc/init.d but make sure it has a .sh suffix
Basically, anything you put in /etc/init.d/*sh will get run at boot, not just this one
It's not the usual type of startup script (with a case statement for stop|start|restart and so on) but I'd go with something like this:
1) Create a file called /etc/systemd/system/OLicenseServer (the actual name is your choice)
2) The file should, at it's most simple, look like this
[Unit] Description=OLicenseServer control [Service] ExecStart=/path/to/OLicenseServer start #ExecStop=/path/to/OLicenseServer stop # if this is implemented in the script [Install] WantedBy=multi-user.target
3) # systemctl enable OLicenseServer
There are many more options but this should get you started