Hi again,
I was thinking, since Mozilla browsers are no longer maintained for ARM systems and RPi (can't figure out why is that), is Chrome a viable solution. Has anyone managed to get it work on Slackware ARM? If I'm not wrong, in Slackware, the "building" of the chrome package is based on transforming a prebuilt deb package. So that is not usable on ARM.

UPDATE: OK, i ve found the answer, I was just forgotten to check the Slackbuilds.org :)

UPDATE 2 : Still the question remains, why is Mozilla no longer supported? Where is the difference?

So I tried to build chromium, from slackbuilds on RPi, and unfortunately it fails. If someone has got different results, please just let me know, though I guess it is also not supporting ARM. This is sad because it definitely needs a good browser to be available for RPi. I have tried Midori a little but I don't know if it is so powerful tool like chromium or even firefox. I have heard that Eric is making a new ARM port of Slackware, so I just hope that maybe sometime in the future it'll be available and maybe get a different result.

http://ftp.arm.slackware.com/slackwa.../ChangeLog.txt

Sun Jan 13 16:06:46 UTC 2013

I have built the latest Mozilla packages for -current only, and placed them out of
the main tree here:

ftp://ftp.armedslack.org/slackwarear...rrent/packages

These are built for minimum target of 'armv6j'. I can only build these because
my '-current' build host is an ARMv7 machine with a hardware FPU. The build hosts
for the stable releases of Slackware ARM are ARMv5 machines, upon which these
packages cannot be built, thus cannot be maintained. Therefore, I will maintain
the Mozilla packages *only* for users who follow -current closely, but will no
longer provide any new Mozilla packages for any stable releases (apart from 13.37
which uses Firefox v3). The reason for moving the new versions of the packages
out of the main tree is because anything in -current ordinarily implies that it
will be present in the next stable release, which of course cannot happen if they
can't be built on the hardware used to maintain stable releases.
+--------------------------+

Thank you a lot.

Hey guys quick question about running slack-arm on the pi. Say I want to set one up to run as a headless ssh server how would I go about setting it to auto-login a user after reboot?

if it is running headless, why the auto-login?. If you want to run a program on startup refer to it in /etc/rc.d/rc.local is the usual way.

if it is running ssh server (which it does by default for slackware anyway) then it is the client (on another device) that would have to be logging in, not the server. perhaps you could clarify what you want to do.

There is an article here http://littlesvr.ca/linux-stuff/arti...ginconsole.php which may help for autologin, but some more info might help for your actual problem.

I don't actually have anything set up yet, looks like I have some reading to do before I start trying to set this up.

So basically if I were to plug in a monitor it would show the login screen, but ssh and any cron jobs would be running already?

short answer: yes.

long answer: By the time the system has got to the login prompt all that and more are already running. In slackware, you'll find the "services" running as executable scripts in /etc/rc.d , or in some instances, being run by inetd ( config file is /etc/inetd.conf in the case of pop3, imap, telnet and rsyncd if enabled)

so, once the system is installed, and you've checked the network is ok, you can disconnect keyboard, mouse and screen, and ssh in remotely using putty from windows, or ssh from linux/mac
you can then do anything you want remotely.

Of course if the pi is going to be connected to some other hardware controlled by a program for example /bin/myrobotprogram
then add /bin/myrobotprogram to /etc/rc.d/rc.local and it will run when the system starts up before the login prompt.

Hi,
I have been trying to setup my Pi to boot from NFS, I have followed the instructions in several forums, but I always get the message "Cannot open device nfs" when setting root=/dev/nfs.
I installed the system following the instructions from http://www.daves-collective.co.uk/ra...stalling.shtml (starting from the barebones SlackwareARM image, and then installing ponce's kernel packages)

Is this because of lack of kernel support? If so, how can I add what I need? I hope it is just a matter of touching the initrd image.


Regards

you can check for kernel support with something like
zcat /proc/config.gz|grep "CONFIG_NFS"

I would say the config file is this one: https://github.com/Ponce/raspi-slack...i/config-raspi
and it seems it is activated. But I will check on the real machine :)

Hi all,

Following Alien Bob's ARMv7 port, I've ported Slackware for ARMv6 with hard float support. You can download packages and sources from my site, here: http://ahau.porteus.org/slackwarearmv6.html

Note: you can't mix these packages with the armv5te packages from slackwarearm, you have to do a full install. I've not rebuilt the kernel so you'll have to use one from somewhere else (the kernel doesn't need to be rebuilt for hard float support). KDE is not included as of yet, and I don't have an installer prepared so you'll have to do everything manually.

Please consider this a testing release for now; I've compiled it all on my tegra 2 tablet and it's up and running here but I've not done thorough testing on every application.

Enjoy!

Cool stuff -- are you planning on making an installable system, releasing it and maintaining it? Whilst there has been some good work done by the community to get Slackware ARM on to the Raspberry Pi, I'm also aware that the support is somewhat fragmented and users have experienced problems.
If you're planning on supporting your work and have a long term interest in it, I'd like to recommend that users choose it over Slackware ARM on the Rpi- as it makes sense to have an optimised distribution + a dedicated focus on it.

Thanks, Stuart! I am planning on making an installer, kernel, etc., and maintaining it in line with Eric's port. I do plan to keep it current and support it as best I can. I'm hindered now by the fact that I don't have a Pi myself yet, so while I can ensure the userland is working on my armv7 device, I can't very well troubleshoot the kernel and installer for the Pi specifically. I will be picking one up soon. I also have obligations as the documentation team lead and the xfce/lxde maintainer for Porteus Linux so I may be spreading my free time a little thin, but I have a real interest in ARM devices and intend to stick with it.

For the time being, I'd definetly recommend that users looking for a tested and stable system should stick with slackwarearm until we get some more testing done; at the same time, I'm hopeful there are some folks out there with an adventurous streak, who'd like to help me with some early testing.

Checked. The settings are as shown in the link above, and the device /dev/nfs does not exist.
I also checked my other Slackware system, and /dev/nfs does not exists. By searching on the web, I found that one just needs to create it, but that is not a solution in this case. maybe I'll have to tinker with the initrd image :)

Regards

Edit: No, the initrd image won't be enough. What is missing is the CONFIG_ROOT_NFS setting in the kernel. The kernel needs to be rebuilt. "Make it so", as Capt. Picard used to say :D

there's no such option available in the kernel config, you can check in you local config with

That does not mean it is not an available option. Some kernel configuration parameters are not mentioned in the .config and are invisible in the kernel configuration menu, until you enable a dependent option first.

Try "Networking Support > Networking Options" and enable "IP: kernel level autoconfiguration". That makes a few other options visible right below it where you can check "IP: DHCP Support" and "IP: BOOTP Support". Then go back to the kernel main menu and select "File Systems > Network File Systems" where you will find the (invisible until now) new option "Root file system on NFS" which you must enable.

Eric

thanks Eric, I forgot about that: I'll have a look and enable it in the next kernel.

I'm trying an install using my installer and using nfs, and ATM seems to work: I just noticed that during the rsync I got a permission issue on CHANGELOG.txt and that the bzip2 package is somehow corrupted.
The installation is still going on...

EDIT: installation finished and running! I used this as installer
http://ponce.cc/testing/raspi-extras/

EDIT2: I had to manually install the kernel-headers package later, really minor glitch. :)

EDIT3: I got an underlinking error when trying a "make menuconfig" in the kernel sources
and when I try to build tmux
I'm thinking about a problem with ncurses and I'm trying a rebuild of it without --with-termlib=tinfo

That's great, thanks Ponce!

You'll need to add a line to scripts/kconfig/Makefile, around line 212:
HOSTLOADLIBES_mconf += -ltinfo

Per this post:
permalink.gmane.org/gmane.linux.kbuild.devel/8955

So that LD will pick up libtinfo, which has been split from libncurses.

EDIT: rebuilding ncurses would also work, but if you do upgradepkg on the install it will delete libtinfo which will break *a lot* of stuff -- either install over the top or. Replace libtinfo with a symlink to libncurses.

Hi guys,
I have it working now. I had to rebuild the kernel with the CONFIG_ROOT_NFS option enabled, and in order to do that I had to enable CONFIG_IP_PNP as well (IP kernel level autoconfiguration). The Pi took around 12 hours to compile everything. Now I have a 3.6.11 kernel running from an NFS root :)

Extra tips to have everything working:
* Remove the / line in /etc/fstab, as there is no need for it.
* change "ro" to "rw" at the end of cmdline.txt (the boot process fails when trying to remount the FS). Doing this will enable a warning in rc.S, I just commented out the corresponding block in the script (I know it is not the best solution, but it works and nothing gets broken)

So far I have noticed that the disk access is slower than my previous setup (an external HD via USB), but mounting via NFS gives me some other advantages related to my home equipment.

How fast is NFS versus your SD card? The reason why I ask, is because I tried sshfs-fuse on my raspi, and well, my class 4 SD card was faster. I might try having NFS myself for the first time. I'm sure the external HD via USB was plenty fast.

I've followed a different way: as it's an underlinking problem of libncurses, I tried to link libtinfo in it
and that allowed me to use make menuconfig and build tmux too.

but I'm still having some problems with the second build in the ncurses.SlackBuild, so I'm giving it another look.

I can't compare both situations, I ran from SD only a few weeks (until I got my first FS corruption due to my brothers disconnecting the USB power cable ...) Immediately after that I went for a USB HD, and that happened almost a year ago. I remember the SD card being faster than what NFS is now, since it was a good Class 10 card. When I moved to the external drive, I started using a cheap 2GB card that I believe is class 2, but as it is only used for /boot, that is not an issue.

I haven't started tweaking the NFS parameters to see if I get better performance, but I can *hear* the drive working more (my NFS server is the same media player I was using as USB disk, and also as power source), and the boot/shutdown process is now 2-3 times slower than before.

One quirk I found is that using ip=dhcp doesn't work, so I had to convert to a static IP setup. The Pi is able to get an IP, but the rootserver and bootserver parameters get set to my router, instead of the NFS server. This means that it never finds the NFS export, because it is looking for it in the wrong IP.

Still, I prefer this setup because I can use samba and other processes in the media player itself (while working as an external disk, the OS part on it doesn't work), and also the player has some issues with USB that caused the disk to disconnect when loaded (e.g. copying a folder from my windows laptop to the samba share in the Pi, or downloading a torrent while trying to watch a movie), so it was getting annoying. I could use another USB HD, but that would mean using another wall plug on an already crowded space :D

in the end I solved linking against libncurses with a trick from debian.
I'll post the patch for ncurses.SlackBuild as I get home.

here it is: I think this can be useful also for Eric's sources (I generated it over his git tree)...

Hi Ponce

I noticed that trick, it is used in Fedora's ncurses package too. But I do not understand what it does, and I do not apply stuff I can not rationally explain ;-) Is there documentation about the idea behind writing INPUT in a shared object file?

Eric

Yes, thank you very much Ponce, this is very interesting stuff! I also wonder if it will defeat the purpose of splitting off libtinfo in the first place (i.e. producing smaller binaries). I'll look into this some more in the morning. Thanks for all your work on this!

Do you have a script or anything that produces the installer you built for slackwarearm? I might take a look at it and see if the size of the installer can be trimmed down a bit while still being functional :)

Yeah, it looks like debian and fedora are both using these ld scripts as workarounds for ltinfo failing to link, and fedora is using "AS_NEEDED" -- I'm assuming to avoid overlinking ltinfo. This approach appears to break linking against ncurses with ld.gold, though I'm not aware of any packages in Slackware that are using the gold linker. The folks at Gentoo feel this is a hack and linking against ltinfo should be fixed in all of the packages individually. Based on what I've gleaned from some opensuse threads, they have patched ncurses (but I haven't find the specific patch yet) and have fixes for other packages on a case-by-case basis.

links:
https://patchwork.kernel.org/patch/2179341/
http://lists.opensuse.org/opensuse-p.../msg00106.html

some more info on rationale behind the libtinfo split-out:
https://enc.com.au/2011/09/30/ncurses-library-split/

Using ld scripts does feel a bit like an ad hoc solution rather than a permanent fix. My gut instinct is to retreat to the safety of upstream Slackware, and put libtinfo back in libncurses for the time being. That said, it sounds like the ncurses developers are heading more in the direction of splitting it out.

OpenSuse uses the same INPUT AS_NEEDED approach: https://build.opensuse.org/package/v...penSUSE%3A12.3

I agree that I may have to revert my decision to split out libtinfo. However that will not happen in my ARM port sources too soon, due to lack of time (a lot of recompiling is required when I revert that modification).

Eric

Ahh, you're right - the info I was reading must have alluded to that fix rather than a patch to the ncurses sources, or they changed things subsequently. Dang, I had my hopes up for a patch lol.

I hear ya on the time involved to roll that back. For the time being, I think my approach will be to implement the AS_NEEDED approach in ncurses to retain compatibility with my existing packages that were compiled against split libraries while also avoiding lots of build failures for anyone who is trying to compile additional packages (or the kernel, in ponce's case). If/when you implement a change in your port, I'll adopt it and rebuild as necessary. I'd like to maintain as much compatibility with your source tree as possible.

I think the less harmful fix should be to link libtinfo directly in libncurses and libncursesw at ncurses compile time, but the build system doesn't allow this and I can't see -cause I'm noob- an easy way to patch it (besides the substitution of the .so link with a linker script): if you specify a LIBS=-ltinfo variable (or by LDFLAGS) then all the libraries that are built wants to link to that at compile time, libtinfo itself included, and this, besides going conceptually against the split, breaks the build because libtinfo gets truncated at linking time.

pfft. If you're a noob, I'm not sure what that makes me, but it must be pretty bad :P

I applied the changes to my local ncurses.SlackBuild, rebuilt it, and tested to verify that a package that previously required 'LDFLAGS="-ltinfo"' now builds fine with out it. I'll sync my local repo with the server tonight. Thanks again!

Any of you guys are going to try Parallella?

Ahau, I prepared a kernel (with bfq and aufs) on your platform (modified build scripts derived from David's ones are in the "sources" folder)

http://ponce.cc/slackware/testing/raspi-extras-armv6/

Ponce, that is awesome, thank you so much! Do I have your permission to pull these files and sources into my tree?

I've been busy prepping stuff for Porteus 2.1 but will definitely be returning to add and update to slackwarearmv6 :)

the original sources are of David Spencer, I just forked his stuff for the new kernels and added something: for me it's ok, but you better ask him :)

Hello fellas,

I have bought a raspberry pi b-model 5 months ago, with 512 MB RAM, and due to overworking months that followed i had not free time to play with it.
Until today , although with no luck and here is where i need your help.

I follow the guide from here using a class 10 8GB card SanDisk.
The problem is that device no boot and an with main orange color appears.
Can anyone help me to resolve this issue????

Thanks

if you're sure your SD card is supported, follow the instructions from here

http://ponce.cc/slackware/testing/ra...ADME.installer

and grab this installer for the task

http://ponce.cc/slackware/testing/raspi-extras-armv6/

The newer boards might require a more up to date firmware. I had just bought a board two months ago, and all the images listed through the slackware arm site for raspi did not boot for me. Ponce's image saved me since I did not know what was wrong either. His image is more up to date and works. So follow his instructions. It's good to see he just updated his image again too. I was going to recommend to update your kernel and firmware, but since he just did that will save you some time.

@ponce; I installed your kernel 21 May image with 20 May kernel yesterday and had an error message when installing the raspi-extra kernelI wasn't sure if the install would be any good so I dropped into a terminal and checked /mnt/boot. Everything seemed to be in order but I deleted all the READMEs and installed the kernel again just in case. I didn't have any errors that time and could boot slackware arm current but I decided to reinstall again with a larger boot partition. so I dd'd that card again and then used gparted to enlarge the boot partition. Gparted gave me 88mb for the partion size and said 87.34mb were used. I enlarged it to 100mb and then added an ext4 and swap partiton. Install was fine and the pi is now blue tacked to a wall out in my shop and talking to me via wireless as I write.

Should I have had 87.34mb used up in that boot partition after transfering your image to a card and installing as per your packages. If so an 88mb partition seems a bit small in case the kernel is replaced with another one a bit larger.