Re: crypto acclerators (was Re: LUKS overhead encrypted root fs on a slug and crypto-modules)
Tobias Frost schrieb: I have to correct myself: in git, there is at least a file for the HiFn796x crypto chips, which is used on the soekris card. It is available in 2.6.25: CONFIG_CRYPTO_DEV_HIFN_795X: This option allows you to have support for HIFN 795x crypto adapters. -- Tomasz Chmielewski http://wpkg.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Puzzling difference between debian-arm and debian-i386 re growisofs
For info. Additions to the bug report welcomed - especially any that reproduce it. Barry Original Message Subject: Bug#476846: Acknowledgement (genisoimage: On arm only, does not recognise its own Rock Ridge extensions) Date: Sat, 19 Apr 2008 15:06:04 + From: [EMAIL PROTECTED] (Debian Bug Tracking System) Reply-To: [EMAIL PROTECTED] To: Barry Tennison <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Joerg Jaspert <[EMAIL PROTECTED]> If you wish to submit further information on this problem, please send it to [EMAIL PROTECTED], as before. Please do not send mail to [EMAIL PROTECTED] unless you wish to report a problem with the Bug-tracking system. -- 476846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476846 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian upgrade
Might be not your case, just throwin in: I had the same at my thecus some time ago... However, in my case this was caused by trying to mount something using UUIDs. If you changed your fstab, you should check if this is the cause -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian upgrade
On Sat, 19 Apr 2008 07:37:48 +0100 Bob Cox <[EMAIL PROTECTED]> wrote: > > I'm sure that re-installing from scratch is unnecessary, but a re-flash > may be required I suppose (in "upgrade-mode" as you mentioned above). > > Good luck anyway. > > > > HAM Callsign G8JVM : Locator IO82SP > > 73 de G4AEL ;-) > N Thanks Bob The network scripts have the ip address as 192.168.1.77, in upgrade mode its responding to 192.168.0.1. I can ping that address, and I can telnet to port 9000, upslug2 cant find a slug in upgrade mode, but its sitting there with the top led flashing red. [EMAIL PROTECTED] debian-slug]# upslug2 -i di-nslu2.bin [no NSLU2 machines found in upgrade mode] [EMAIL PROTECTED] debian-slug]# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.40 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.992 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.466 ms --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.466/1.289/2.409/0.820 ms [EMAIL PROTECTED] debian-slug]# telnet 192.168.0.1 [EMAIL PROTECTED] debian-slug]# upslug2 -i di-nslu2.bin [no NSLU2 machines found in upgrade mode] [EMAIL PROTECTED] debian-slug]# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.40 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.992 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.466 ms --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.466/1.289/2.409/0.820 ms [EMAIL PROTECTED] debian-slug]# telnet 192.168.0.1 9000 Trying 192.168.0.1... Connected to 192.168.0.1 (192.168.0.1). Escape character is '^]'. Trying 192.168.0.1... Connected to 192.168.0.1 (192.168.0.1). Escape character is '^]'. At This point you can type anything but no response. I did find that the network scripts were not being invoked on start up so I've put the symlink back S40networking pointing to /etc/init.d/networking in RC3, RC4 and RC5. Dropping the telnet session ,stops any further attempt to telnet to it, but it can still be pinged. In normal mode it looks as if its booting, but it can't be pinged. I'll try adding a script in /etc/init.d to ping the host machine and watch the port with tcpdump. Any suggestions welcome -- Best Wishes Richard Bown ~ Registered Linux User 365161 OS Mandriva x86_64 2008.0 Kernel 2.6.22.9-1mdv HAM Callsign G8JVM : Locator IO82SP QRV all bands 80mtrs to 3 cms ,( non WARC ) http://www.software-radio.org.uk A computer is like a Native American Indian teepee, it has no gates, no windows and has an apache inside. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Speed of aptitude on NSLU2
Kurt Pruenner wrote:
> Sorry to barge into this conversation, but I was wondering if you
> maybe could share a few tips about how to configure aptitude on an
> NSLU2 so it's not unbearably slow.
>
> As it is, it takes several minutes for me to start (i.e. until I can
> actually work with it) and moving the cursor around the list takes
> about a second per line... :(
(starting new thread on this, from "Reinstalling debian on n2100".)
That's interesting. aptitude on my slug is annoyingly rather slow, but
the slow parts for me are:
* building the dependency tree
* reading & writing extended state info
* building tag database (wish I could get rid of that - an option?)
* building view
Once I have the view, the response is quite acceptable:
* latency of at most tenths of a second in moving from line to line
* very acceptable response to opening a category ("[") and to "Enter" to
bring up details on a package
* fast closing of "tabs ("q")
So the good news is that I think the response can be acceptable:
we have to determine what are the differences between your setup and
mine. Being reasonably systematic about this, the differences could be:
(1) in the basic hardware and software: unlikely, because I think all
NSLU2s are much the same (?), and we can come back to the differences
between debian/ubuntu versions and versions of aptitude: experience
suggests not much difference here;
(2) in the extent to, and way in, which ram is being used: this is my
best guess for gain: see below for investigations;
(3) in the disks: spinning metal? flash? swap? layout? (see below)
(4) in the network connection (and ssh)
(5) in the client being used (in my experience kde, and to a lesser
extent gnome, adds considerable overhead which is particularly
noticeable on a slower client machine: I get my good NSLU2/aptitude
behaviour on a number of fast clients with gnome, or slower ones with
xfce4 or similar).
Let's pursue the ram idea. My best guess is that your slug is using
ram to do other ("unnecessary") things, and this is leaving too little
ram for aptitude's needs. This leads to excessive swapping
("thrashing"), and this is a classic cause of behaviours like those you
describe. Start by using free. For me, without aptitude running, I
get:
---
[EMAIL PROTECTED]:~$ free
total used free sharedbuffers cached
Mem: 29988 23192 6796 0312 10560
-/+ buffers/cache: 12320 17668
Swap: 1992040 353761956664
---
and with aptitude:
---
[EMAIL PROTECTED]:~$ free
total used free sharedbuffers cached
Mem: 29988 28568 1420 0340 9456
-/+ buffers/cache: 18772 11216
Swap: 1992040 465041945536
---
So you'll see that aptitude can "steal enough" space from the buffers
& cache. NB the figures given by free do vary quite a lot, so use them
only "impressionistically": but if you see a small number under "free"
in the "-/+ buffers/cache" line, that's definitely an alarm sign.
If this looks promising (or even if not), now get to know "top" and try
to work out what (with and without aptitude running) is taking up ram
(and maybe cpu%). top has a lot of flaws, but it's valuable: use the
hotkeys to rank the lines descending by mem% (I think ">") and see
what's hogging ram.
Now take a look at your /etc/rc2.d (assuming your runlevel is 2). Are
you starting up a lot of services you don't actually need? I should
add that for me, aptitude is ok as above while my slug acts as a file
server, UPnP music server and (lig)http server and a few other things,
so I'm not saying it has to be idling. One of my daughters has one
running apache2 and a complete mail spam-filtering system, so there's a
lot of potential a long as the apps are not cpu or ram intensive.
In my experience, exim is a hog, so unless you really need it,
uninstall it or disable it (see man update-rc.d or probably better, do
it manually by the S20 -> K80 etc method). nfs-common and samba are
other targets for disabling: see the massively helpful
http://www.nslu2-linux.org/wiki/Debian/FAQ
http://www.cyrius.com/debian/nslu2/reducing-memory.html
I actually spent quite a bit of effort finding out what services were
writing to disk, to minimise power use by keeping the disks spun down
unless really needed: I used find with options and a few experiments;
but you may not need to go that far.
That's a start on the ram idea, my best guess. Briefly on the other
matters:
(3) I have almost all my rootfs on a 2GB usb flash drive, with two big
usb-hds (as a RAID1 pair) mainly attached as /var (with a symlink
from /home/bari/data to /var/local/data to store all data). This is
pretty efficient, and undoubtedly having most of /
(especially /bin /sbin /usr/sbin and /usr/bin) on flash speeds things
up. What is your swap setu
