[HOWTO]Debian Weezy for AC68 and AC56 + OwnCloud
- Thread starter Xerxist
- Start date
Very nice, coz *ware is outdated.
But I have some newbie questions, i have never ever used chroot and other "advanced" unix tricks:
What about RAM consumption, is it shared with router?
Does it need swap space on hdd?
What about router performance?
What about extra heating when using torrents, for example?
How networks are shared with router? Which interfaces debian apps can bind to?
Who build debian for asus, who will maintain it?
How to properly update merlin firmware builds and debian base?
Do I need ext4 or ext2 will do (ext2 is significantly faster on arm according to raspberry pi users)?
Is it possible to intall GCC and compile directly in debian on router and not only to install ready-made apt packages (without any chaintools)?
What happen when asus will change kernels, device drivers etc in its firmware?
But I have some newbie questions, i have never ever used chroot and other "advanced" unix tricks:
What about RAM consumption, is it shared with router?
Does it need swap space on hdd?
What about router performance?
What about extra heating when using torrents, for example?
How networks are shared with router? Which interfaces debian apps can bind to?
Who build debian for asus, who will maintain it?
How to properly update merlin firmware builds and debian base?
Do I need ext4 or ext2 will do (ext2 is significantly faster on arm according to raspberry pi users)?
Is it possible to intall GCC and compile directly in debian on router and not only to install ready-made apt packages (without any chaintools)?
What happen when asus will change kernels, device drivers etc in its firmware?
Last edited:
TeHashX
Very Senior Member
This build is for mipsel devices, uninstall minidlna if you don't need it.
http://forums.smallnetbuilder.com/showthread.php?t=14573
Outputs are:
ASUSWRT-Merlin RT-AC68U_3.0.0.4 Fri Jan 31 05:21:52 UTC 2014
accName@RT-AC68U:/tmp/home/root# ls -la /mnt/sda1/debian/utils/
drwxrwxrwx 2 1 1 4096 Feb 23 18:16 .
drwxrwxrwx 22 accName root 4096 Feb 23 18:22 ..
-rw-rw-rw- 1 1 1 25407 Feb 23 18:16 chroot
accName@RT-AC68U:/tmp/home/root# ls -la /mnt/sda1/debian/
drwxrwxrwx 22 accName root 4096 Feb 23 18:22 .
drwxrwxrwx 4 1000 1000 4096 Feb 23 23:27 ..
drwxr-xr-x 2 accName root 4096 Feb 23 18:22 bin
drwxr-xr-x 2 accName root 4096 Dec 8 23:04 boot
-rw-rw-rw- 1 1 1 89193932 Feb 23 18:22 debian-wheezy-fullbase- arm.tgz
drwxr-xr-x 5 accName root 1660 Jan 1 2011 dev
drwxr-xr-x 46 accName root 4096 Feb 23 18:22 etc
drwxr-xr-x 2 accName root 4096 Dec 8 23:04 home
drwxr-xr-x 10 accName root 4096 Feb 23 18:22 lib
drwxr-xr-x 2 accName root 4096 Jan 21 15:14 media
drwxr-xr-x 2 accName root 4096 Dec 8 23:04 mnt
drwxr-xr-x 2 accName root 4096 Jan 21 15:14 opt
dr-xr-xr-x 89 accName root 0 Jan 1 1970 proc
drwx------ 2 accName root 4096 Feb 23 18:22 root
drwxr-xr-x 6 accName root 4096 Feb 23 18:22 run
drwxr-xr-x 2 accName root 4096 Feb 23 18:22 sbin
drwxr-xr-x 2 accName root 4096 Jun 10 2012 selinux
drwxr-xr-x 2 accName root 4096 Jan 21 15:14 srv
drwxr-xr-x 11 accName root 0 Jan 1 1970 sys
drwxrwxrwt 2 accName root 4096 Jan 21 15:16 tmp
drwxr-xr-x 10 accName root 4096 Feb 23 18:22 usr
drwxrwxrwx 2 1 1 4096 Feb 23 18:16 utils
drwxr-xr-x 11 accName root 4096 Feb 23 18:23 var
accName@RT-AC68U:/tmp/home/root# ls -la /mnt/sda1/debian/bin/bash
-rwxr-xr-x 1 accName root 818084 Jan 1 2013 /mnt/sda1/debian/bin/bash
Ford Prefect
Senior Member
...there we have it...your chroot binary is not marked as executable.
Do a
Code:
chmod ug+x /mnt/sda1/debian/utils/chroot
Last edited:
Ford Prefect
Senior Member
...you should do some reading what this kind of setup does....it'll help.
yes
by itself no, it'll depend on what you'll be doing with it...compiling a larger package could
be eating a lot of memory...swap can help.
the chroot will not eat any performance at all
The same performance penalty applies as with running binaries from other package sources.
see above...not dependant on the chroot/deboan package...simply on you much strain you put on the CPU by using some binaries that perform more or les hard work for you.
see the tutorial...all devices are loop-mounted into the chroot environment and are available
to programms there.
There is no debian for asus...this is official debian for ARM (armel).
The ASUS is just happen to have the compatible CPU
Thus maintenance is done by the debian package/distro.
With the small difference, that you will not be upgrading/using the debian kernel and device/kernel modules...you will only use the debian userspace with chroot.
This is not tied to Merlin FW...it'll work with stock FW as well.
Update debian by "apt-get upgrade"
Do as you prefer...I am on ext4 with a USB3/SDHC-class10 card.
Yes, absolutely possible.
I have just done this for "tinyproxy", which needs some patching in order to work in a multi-homed environment...worked like a charm and I've been impressed with the performance of the ASUS on this task.
the chroot will not see these...there is a risk that other kernels will have a different API than that of deban wheezy (in fact wheezy runs on 3.x kernel whilst ASUS is still on 2.6), but
I would consider this risk to be very low. The common devices, like net, block, etc used in our scenarios have been there for years and won't change anymore.
Ford Prefect
Senior Member
Thanks Ford for answering the questions!
I didn't have much time today to look at all the questions but when I got home you already answered all of them
Made some adjustments to the tutorial from the questions that came up.
No worries.
Pls look at the "bug" from user TyraelAC.
Your download for chroot is the single binary..however, the executable flag will *not* be transferred that way and gets missing, hence.
I suggest, since your tut places it inside the debian-tree anyway, to incorporate it in the debian-tree download archive.
Last edited:
If you want to use a swapfile you can do the following.
Create a swap file of 512MB
Goto a folder where you want to create a swap file (in this instance /mnt/sda1)
Use the swapfile
If you want this at every boot
add the following line
Create a swap file of 512MB
Goto a folder where you want to create a swap file (in this instance /mnt/sda1)
Code:
cd /mnt/sda1
dd if=/dev/zero of=swapfile bs=1024 count=524288
mkswap swapfile
chmod 0600 swapfileUse the swapfile
Code:
swapon swapfileIf you want this at every boot
Code:
cd /jffs/scripts
vi services-startadd the following line
Code:
swapon /mnt/sda1/swapfile
Last edited:
Yes I'll will add that too like the sleep command which is needed in some cases on slow spin ups which I seem to have some time as well.
When i placed the chroot on the share it was still 777 so it automatically was executable so I didn't notice but will adjust it in there.
Last edited:
Ford Prefect
Senior Member
...on my AC68U the user root is not defined, so "chown root:root" does not work
...may I suggest to use script "post-mount" instead?
...and make it executable after with a "chmod a+x post-mount"
Last edited:
Ah I see.
The chown isn't really needed as the root of sda1 already has the right permissions.
I'll remove it.
I can move the script in "post-mount".
Do you mean for all?
At the time I wasn't aware of all the scripts that could be executed but the post mount is probably better as we don't need the sleep command then.
Ford Prefect
Senior Member
Well, come to think of it....since we rely on the debian-tree to be available, which in turn requires the disks to be mounted by the system, the post-mount script would make the best, less error-prone place for all our commands.
Maybe it is better to use another small partition for swapfile performance-wise?
Instead of tinyproxy have a look at 3proxy.
It smaller, faster, simpler. I use it on my ubuntu server where squid just dies...
http://www.3proxy.ru/?l=EN
Last edited:
TeHashX
Very Senior Member
Use a label
If sleep 10 in script is used to wait for usb drive to mount - it is bad idea and it doesn't always work!
It is better to move script to post-mount, it runs after services-start in my tests.
Also, there is a problem with /dev/pts add
mount -o bind /dev/pts /mnt/sda1/debian/dev/pts
Thanks to r00t4rd3d
It is better to move script to post-mount, it runs after services-start in my tests.
Also, there is a problem with /dev/pts add
mount -o bind /dev/pts /mnt/sda1/debian/dev/pts
Thanks to r00t4rd3d
Last edited:
Similar threads
