- luv-main - example.com

Re: Disabling/bypassing UUID on Ubuntu Trusty
by zlinw＠mcmedia.com.au 25 Apr '14

25 Apr '14

Some comments based on a number of points by Rick Moen........ >> You haven't been using GRUB nearly that long. >Quite right. And I've been seriously tempted to give that piece of junk >the heave-ho and go back to lilo. (On EFI, there's elilo.) >It wasn't broken, and I am annoyed by distros fixing what wasn't broken. >(Your mileage may differ.) Lilo is still availible on Debian under "expert install" and works very well. I dislike grub greatly and have always had problems with it. Lilo is simple and I understand it and its limitations very well. The more complex something is made the chances it has to breakdown in some way! >> having multiple drive controller technologies - sata and sas, for >> example - is not at all uncommon. >I've already stated my view that this is something to avoid (concerning >main storage) if reasonably possible - and also stated that my view >applies within the scope of the usage scenarios I've found myself in >over the past 21 years of Linux use. I've also said that I think it's a >great idea to, at minimum, retain UUID-based lines in one's /etc/fstab >as comments in case the information therein is ever needed. I used for a while the combination of SCSI (3 hard drives) and a PATA data drive. (reason for this set up was large scsi drives being difficult to get) It for most part was not satisfactory, the Linux kernel having some kind of built in bias far PATA. For instance when uodating the kernel with lilo one had to unplug the PATA otherwise the lilo command would fail. As for UUID's I do not use them mainly for the reasons given by Craig and have never really had any problems. As for UUID's there is little info about them and how to use them and in a recent experiment one a system using them.... On a UUID enabled system (before I changed it back to using device's) I swapped a pair disks between devices. On reboot system failed as it could not mount the drives. I had assumed according to the UUID docs that the drives would be mounted according to UUID to mount point mapping given in fstab, this did not occur. Lindsay

2 1

Alternate Install CD for Ubuntu Trusty?
by Carl Turney 23 Apr '14

23 Apr '14

Hi, Are Ubuntu still making Alternate Install CDs for their new releases? Want to do some stuff to the hard disk before the actual install of Trusty. Otherwise: Should I just do the trial run and do things via a terminal window there, or boot up off an old Alternate Install CD? Ta, Carl Bayswater

4 5

Re: google earth of Debian testing
by zlinw＠mcmedia.com.au 21 Apr '14

21 Apr '14

I mentioned in my previous post that I was getting an "invalid HTTP request" error on search's. Now this is caused by the Debian built package including a problematical version of libcurl (/usr/lib/googleearth/libcurl.so.4), to fix the above problem all that is required is to remove this library (googleearth will use the systems libcurl). I did this by renaming libcurl. Note, the Debian package supplied by the google earth web site does not have a version of libcurl with it. Lindsay

1 0

Re: google earth of Debian testing
by zlinw＠mcmedia.com.au 19 Apr '14

19 Apr '14

Finally got it working on Debian 7.4. NVidia closed src driver was removed and reinstalled, google earth mostly works OK, I say mostly as search does not work but comes up with an "invalid HTTP request" error, everything else though seems to work. Interestingly the package from google earth works, the Debian generated package comes up with a library error message from one of the Qt libraries. This may be fixable, a post on the google earth help forums provides a archive of 4 Qt libraries that the post say create some problems on Debian based distributions. The two versions APPEARS to be able to co-exist as the main exicutable runs under different names. Lindsay

1 0

Re: google earth of Debian testing
by zlinw＠mcmedia.com.au 18 Apr '14

18 Apr '14

Many thanks for the replies, unfortunately nothing has so far worked. A small correction the distribution used is actually current Debian stable. A search on the net shows a lot of people are having problems on both Debian and Ubuntu. Interestingly the symptoms on my system do not match any of the above problems. It seems to be worth a try to get rid of the NVdia closed src drivers and see what happens as quite a number of cures have invloved playing around with the closed src driver files. Various solutions have been put up and it appears that clear it does work on some systems. Google earth though appears to be quite a fragile/picky program. In my case it certainly worked on Debian 6.0. Of my 4 systems one is running Debian 7.4 i386, another 7.4 amd64, the third debian testing i386. The forth is running 6.0 i386, GE was working on this (note 1), unfortunately this has had an Intel 530 series SSD fail recently and is out of action till I get around to replacing the drive. I will keep it at Debian 6.0 and see if GE (still) works on it............. Note 1, the amount of Debian i386 in the above list, 3 out of 4 machines, is because I use wine I have compiled myself (a later version of wine than Debian had being required). Now the debian packages of wine do work on my amd64 machine but I simply have not been able to get wine to compile on amd64 inspite of following a number of sugestions from various forums. Lindsay

1 0

Re: Linux PPPoE bridge mode issues - again
by Peter Ross 16 Apr '14

16 Apr '14

From: "Toby Corkindale" <toby(a)dryft.net> > On 16 April 2014 13:00, James Harper <james.harper(a)bendigoit.com.au> > Last time this came up, in 2013, you checked the inbound packets, and > reported: > "I can confirm what we thought - pings <= 1492 bytes get a response, > pings > 1492 bytes get no response, not even a 'fragmentation > required'." Sorry, I did not read all of your conversation before, just remember bits and pieces but it really reminds me of the introduction of a new ADSL router a few months ago. (From my e-mail conversation to the ISP then: --- With the old one[old router], I can ping up to 1464 bytes (ping -s 1464 -D www.zeit.de) above it fails. The new one I can ping just up to 1430 bytes (ping -s 1430 -D www.zeit.de) 1432 is too much. BTW, on the old one I can ping with bigger packets (e.g. 1600 bytes) as long as I allow fragmentation. So, there is something blocking packets bigger than 1430 bytes (ICMP+header), compared to 1464 on the old link. If I have packets above 1464 my end complains (ping: sendto: Message too long) because it knows its own MTU. So the 1430 limit is not on my end, it is further away. .. P.S. After this, I set the MTU at 1458 at the proxy server (not the gateway itself which sits between proxy and the ADSL modem). Then it works. --- I have no access to the ADSL router so I had to report from the device behind it (a FreeBSD router). The ADSL router was doing PPPoE. In-between the technician considered a faulty ADSL router but finally figured out: THe ADSL router had a configuration error (not a hardware problem) I vaguely remember that it had to do with path MTU discovery and blocked ICMP packages further upstream (so the result was not the same on all websites, hence my test with the "reliably failing" www.zeit.de website), as described here: http://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD Unfortunately I cannot access the ASDSL router so I do not know exactly what the change in the config was. Regards Peter

1 0

google earth on Debian testing
by zlinw＠mcmedia.com.au 16 Apr '14

16 Apr '14

I have tried to run google earth on current debian testing, both the package from google-earth and the one built by debians google-earth-package. Both of these when run cause the X server to crash back to the console with a segmentation violation, the initial loading screen shows, the screen switches to full screen with a black background, the crash occurs after another second or so. Anyone have any idea's, I may install Debian stable (7.4) and see if that works. Lindsay

2 1

Fwd: Fwd: Fwd: Cross-Compiling for Armv7
by Robert Brown 13 Apr '14

13 Apr '14

-------- Original Message -------- Subject: Fwd: Fwd: Cross-Compiling for Armv7 Date: Wed, 09 Apr 2014 22:15:14 +1000 From: Robert Brown <rebrown(a)exemail.com.au> To: luv-beginners(a)luv.asn.au Following some research on the later kernels and the role of u-boot and dtsb I have used the following - but again without a successful boot: make -j5 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- menuconfig make -j5 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- LOADADDR=0x40008000 uImage dtbs make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -j5 INSTALL_MOD_PATH=output modules make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -j5 INSTALL_MOD_PATH=output modules_install put a copy of the created uImage and arch/arm/boot/sun4i-a10-a1000.dtb into the boot partition of the sdcard copy the created modules to the /lib/modules on the rootfs partition In case the existing boot.scr has some inconsistency I save this to boot.cmd: setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait ro earlyprintk debug ext2load mmc 0 0x46000000 uImage ext2load mmc 0 0x49000000 sun4i-a10-a1000.dtb env set fdt_high ffffffff bootm 0x46000000 - 0x49000000 and run: mkimage -C none -A arm -T script -d boot.cmd boot.scr copy this boot.scr to the boot partition of the sdcard When it fails to boot there's not much chance of troubleshooting as I have not been able to get to the uboot prompt. Anyone got any thoughts? Thanks Rob -------- Original Message -------- Subject: Fwd: Cross-Compiling for Armv7 Date: Sat, 22 Mar 2014 11:02:26 +1100 From: Robert Brown <rebrown(a)exemail.com.au> To: luv-beginners(a)luv.asn.au Do I need to use u-boot to start uImage or can I just put a copy of it in the boot partition? Maybe that is where the failure to boot arises. Thanks -------- Original Message -------- Subject: Cross-Compiling for Armv7 Date: Thu, 20 Mar 2014 21:46:03 +1100 From: Robert Brown <rebrown(a)exemail.com.au> To: luv-beginners(a)luv.asn.au Hi Is anyone able to offer helpful tips or new directions with this: I am wanting to use a usb device with ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T on a MK802II mini pc using the Allwinner A10 cpu. This device requires modules rtl2830.ko, rtl2832.ko and dvb_usb_rtl28xxu. The second of these modules does not seem to exist without patches on kernel 3.4 but on a raspberry pi I have been successful using kernel 3.10.25+. Here is the relevant lsmod from the pi: r820t 16279 1 rtl2832 8020 1 dvb_usb_rtl28xxu 14333 1 dvb_usb_v2 14860 1 dvb_usb_rtl28xxu rc_core 16313 3 dvb_usb_rtl28xxu,dvb_usb_v2 rtl2830 7378 1 dvb_usb_rtl28xxu dvb_core 92797 3 rtl2830,rtl2832,dvb_usb_v2 However when I try to compile a kernel for the A10 with 3.10.25+ I have no success. If I use the raspi sources for the cross-compile: https://github.com/raspberrypi/linux/archive/rpi-3.10.y.tar.gz I get errors that seem unresolvable: e.g.: undefined reference to `v6wbi_flush_kern_tlb_range' If I use the sunxi kernel source: https://github.com/linux-sunxi/linux-sunxi/tree/reference-3.10 the compile completes without error and I get modules and a uImage file but the device won't boot I am using this as a guide: http://jas-hacks.blogspot.com.au/2012/10/hackberry-a10-compiling-kernel-arm… I have tried using various .config files as a starting point including the pi and from the earlier 3.4 kernel without success Does anyone have any experience in this area? Any help would be much appreciated. Thanks Rob

3 4

parse squid logfiles for cryptolocker URL's
by James Harper 09 Apr '14

09 Apr '14

I'm trying to find a simple way to parse squid logfiles looking for cryptolocker (http://en.wikipedia.org/wiki/CryptoLocker) URL's. The proxy in question denies these anyway because the current version of cryptolocker doesn't authenticate and this proxy requires authentication, so right now it's a useful trigger to notice an infection after the fact but before it has downloaded enough to start infecting user files. The url's in question are <something>.net/com/biz/etc, and some examples of the something are: qoemswifeitgetscytkircyfq diqkbihifambsnvbylvtdcyyd tlfmwcyfikzcuqoqgpzdpz so they are random strings of varying length. The challenge is to find a way to identify them without an excessive amount of CPU time (eg not dictionary lookups). Any suggestions? Thanks James

3 4

btrfs latency
by Tim Connors 08 Apr '14

08 Apr '14

Still running 3.10-3-rpi alas because there isn't a 3.14.15 :) version of the pi kernel yet, but is an increasing latency as the uptime increases, expected? Reboot the kernel, and I go back to having 0.1second latency on my SD card in the pi. But after a few weeks, it will be back to 2 second latencies: http://rather.puzzling.org/munin-cgi/pi/pi/diskstats_latency/mmcblk0.html (it started exhibiting this behaviour after the last reboot in January because that's when I installed a btrfs capable kernel and ran ext3tobtrfs over it. Yes, I've deleted the ext3 image snapshot) -- Tim Connors

4 9