Oct 192012
 

今天看到老外写了篇文章,讨论目前Openstack的欠缺。还是挺有意思的。做公有云和私有云的区别还是很大的。

其实国内很多人经常问的问题,这篇文章都涉及,相信社区肯定会去解决的。

大家经常问的日后如何升级和迁移。目前这方面的资料确实不多,不过还是有人愿意去当小白鼠和探索

http://aababilov.wordpress.com/2012/10/18/openstack-migration-from-diablo-to-essex/ 相信日后的升级,会更加简单。

这篇文章,估计需要注册才能看,所以也就copy过来,大家好好读读。

http://searchcloudcomputing.techtarget.com/news/2240166970/Enterprise-OpenStack-projects-encounter-feature-gaps?asrc=EM_NLN_19192023&track=NL-1329&ad=882783&

SAN DIEGO — For enterprises kicking the tires on the OpenStack cloud management platform, there are still some key ingredients missing from the current release.

These gaps include monitoring, high availability (HA), business continuity (BC) and integration with existing user management systems, as well as issues with upgrade support and documentation, according to attendees and presentations at this week’s OpenStack Summit.

Monitoring is a key pain point for James Penick, an architect at Yahoo Inc., which is looking to deploy tens of thousands of nodes on OpenStack by 2014. “There are solutions out there you can pay for,” he said, “but that’s a huge gap in OpenStack right now.”

Storage monitoring that’s up to par with existing enterprise tools is also a missing element, according to Pete Johnson, an engineer at Hewlett-Packard Co. (HP). For example, if users today want to get the average age or size of objects in a Swift storage container, that information has to be gathered through individual queries; that process needs to be raised to the level of existing storage management tools used in enterprises, Johnson said.

Enterprises, however, shouldn’t necessarily hold their breath waiting for low-level monitoring to become part of core OpenStack.

“It doesn’t really make sense for us to build it,” said Josh McKenty, OpenStack Foundation board member and CEO at Piston Cloud Computing Inc. “But we’re also hard-pressed to pick which [existing open source monitoring tool] to include.”

In his previous role at NASA, McKenty’s team used multiple open source monitoring tools — namely, Nagios, Munin and Ganglia — to monitor different elements of OpenStack.

HA and DR: OpenStack hot potatoes

High availability and BC are two more areas of debate as to who should build which features for OpenStack. Right now, users are encouraged to integrate existing open source tools, such as the HA Pacemaker utility or DRBD [Distributed Replicated Block Device], an HA clustered storage file system.

But not everyone trusts these tools. “There are lots and lots of open comments [on them] and things [about them] that can break,” Yahoo’s Penick said.

While HA might be a no-brainer for enterprises, it might not be such a natural fit for OpenStack, which is focused on newer cloud-based applications that design for failure rather than requiring HA from the underlying infrastructure. Enterprises are also expecting integration into existing environments for user management, according to HP’s Johnson, which means integration with Active Directory and Lightweight Directory Access Protocol (LDAP).

There are four packages for Active Directory integration currently submitted to OpenStack for future releases.

Database changes and documentation shortcomings

The rate of change in OpenStack in the two years it’s been developed has been tricky to keep up with, Penick said. For example, there have been changes to the Nova database schema between the Essex and Folsom releases that streamline queries but also hinder upgrades.

“I absolutely don’t disagree with changing [database] schema between revisions,” he said. But converting between the Essex schema and the Folsom schema is easier said than done.

Currently, there are no tools to do this conversion.

“OpenStack cloud operators have to write the tools necessary to make this happen, do it by hand, or do nothing at all,” Penick said. “I spend a good amount of time speaking with other OpenStack operators, listening to their stories,” he said. “More than a few have answered the ‘How do you upgrade?’ question by saying, ‘We don’t. Build a new cluster. Tell everyone to recreate their VMs.'”

Another area of change between Essex and Folsom that’s tripped up some users has been the extraction of block storage, previously known as Nova Volumes, into a separate application programming interface called Cinder.

“It used to be that data about volumes and instances could always be found in the same database,” McKenty explained. Some users “cheated,” in McKenty’s words, creating certain method calls around that assumption, which no longer applies.

Finally, users are calling for better high-level documentation, which would be particularly helpful in troubleshooting problems for infrastructure operations teams, said one developer working as an independent contractor with a major European telecom. “If there’s something wrong, you still have to find what’s wrong,” he said. “It’s easy for me as a developer to look at the code, but it’s not that easy for infrastructure operations people.”

The OpenStack Foundation plans to publish documentation of this nature soon, McKenty said. Piston Cloud also offers an “OpenStack 101” white paper.

Beth Pariseau is a senior news writer for SearchCloudComputing.com and SearchServerVirtualization.com. Write to her at bpariseau@techtarget.com or follow @PariseauTT on Twitter.

Oct 182012
 

其实比较郁闷,我的机器不支持64bit的虚拟化系统。这是cpu的问题,我可以装64bit的win 7,不过我的虚拟机就只能跑32bit的。所以也就没法去测试Openstack。

不过国外开发社区,全部都是使用virtualbox来开发测试Openstack,身边已经有一位朋友把virtualbox 跑起Openstack。

用Virtualbox跑Openstack,一个麻烦的地方是如何设置网络.

http://blog.phymata.com/2012/10/03/contributing-openstack-support-to-jclouds/

http://serverfault.com/questions/409216/what-is-the-correct-network-configuration-for-a-devstack-vm-virtualbox/409331#409331

http://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox

这3篇文章,应该可以让我们把Openstack在virtualbox跑起来。不过我没环境测试。只能做一个记录。

Oct 142012
 

这篇文章其实我很早就看到。很多人估计也是看看热闹。对于搞云计算的人,这篇文章的意义是非同寻常,很多地方是值得思考。。

从别的渠道了解过这位牛人。现在阿里搞的绿色计算:http://www.greencompute.org/index.html 只能算是当年历建宇规划的很小的一部分,已经是大打折扣。据说他们以前的人马已经都跳槽到腾讯,按照他的牛叉思路去搞绿色数据中心。

我是2010年的时候看Rackspace开源的swift的资料,才知道外面做云存储的,其实都不用Raid,而且都是使用家用硬盘,而不是硬盘厂商推销的所谓商业硬盘。他们间到底有啥区别呢。看下面的文章应该就应该清楚。

其实Facebook的开源数据中心的思路和这位老大非常相似。可惜啊,当年马云没有按照这位老大的思路去做,现在开始搞,就大大折扣。现在据说他在负责美国苹果的数据中心。

个人观点:如果你打算运营IAAS,这篇文章也是必读。

下面是转载内容

下文就是他之前要离开阿里巴巴留下的离职信。回顾了他在蓝讯和阿里巴巴的路程。本文也展现了他的一些工作理念,应该说跟着这样的领导还是跟对人的。也许这就是google之所以伟大的原因中的一点:简单。 

中文不佳,全用英文写又无法让更多的同学了解我的心路旅程,所以请各位原谅我蹩脚的中文。

一个简单的道理:一块2TB桌面级硬盘今天的价格约为700元,相同大小的企业级硬盘一块今天的要价仍然超过1,500元,这两个硬盘最大的差别是RVI震动率的设置(因此,桌面级硬盘在震动率稍大的时候,依然能够正常工作,企业级硬盘为了提升可靠性,所以当震动略大的时候,会停止工作,保护磁盘),两者连螺丝的位置都相同(不是用于固定硬盘的螺丝,是用于固定磁盘内部机构的螺丝),我们假设硬盘仍然坚守摩尔定律(每18个月容量增加一倍),一年半后就算我们需要更换所有的桌面级硬盘(注),我们还可以做到用相同的成本,获取两倍的存储容量!四年半后,我们将以同样的价格拥有四倍的存储!加上半导体制程的进步,当固态硬盘开始取代机械硬盘(约计在2015年前后发生),我们服务器的性能和效率能将再上一个台阶(每块SSD可以提供250MB/s 吞吐量,而且只有2.5英寸(SFF),一台2RU的服务器可以配置24个SFF的服务器,也就是6GB的吞吐量,这也就不难解释为什么2012年开始销售的服务器会配置两个万兆以太网端口了)!

成本!成本!成本!:我为什么放弃在ChinaCache的股权,回到美国求职呢?那是因为作为CTO,我没有阻挡我的CEO快速扩张视频分享下载(FLV)这条业务线,结果,到2008年中,当土豆在投资者(VC)的降低成本的要求下,自建CDN设施的时候,Chinacache的业务一下子下降了60%,几个月前刚刚购买的交换机和服务器都必须折价出售,最糟糕的是还找不到买家,IT设备的价格是天天掉价的!倘若当初CEO拒绝10%股权赎回的诱惑(VC要求业绩必须连续两年出现100%增长),将发展FLV业务的经费投资在集群效率的优化,那么ChinaCache就可能可以用更低的成本提供FLV下载的业务,加上时段复卖及规模效应,就可以将FLV下载业务的销售价格低于土豆(自建CDN)的成本价,土豆,优酷等视频分享业者也就不会在 VC的压力下建设自己的FLV下载基础设施。两个月发不出薪水给普通员工啊!你们一定能够体会那种痛苦,我堂堂一个中国互联网骨干设施的先期建设者,居然要靠砸锅卖铁来等待VC的bridge loan来渡过那艰难的三个月,所以我把股权给了留下来的同事(不知道CEO有没有执行这个意愿),自己回到美国求职。相同的道理,阿里巴巴在过去十年,凭借优秀的商务模式,占据80%的电子商务市场,但是,业务模式创新的速度已不如前十年,同质竞争的压力又不断地增加………一种似曾相识的感觉涌上心头:2000年之后,思科分别在两个阶段受到来自Juniper和华为的追赶,ChinaCache只不过将类似的问题集中在一年之内爆发,所以,当这样的问题来临是,无论你请什么人来,都救不了这样的企业。

新商业文明 – 谈厂商和用户之间的关系 (扭曲化的结果就是贿赂,无意义的折扣),电子商务在解决供需的问题,我们也应该用相同的概念来解决我们基础设施的问题。讲实在话,阿里巴巴和国有电信运营商采购的腐败就只有一步之远!如果厂商在我们团建时提供一桌四千元的晚餐,我们这些月薪一万元的SA工程师,怎么能够不嘴软呢?如果团建经费再多一点,如果厂商招待费放开一点,我们的工程师需要厂商那一点点小恩小惠吗?

思科让我回去做主管EC3(企业级云计算),华为让我进入CTO办公室主管云计算业务,我都没同意,它们的薪水可都是高出阿里巴巴三倍的薪水!我想留下来,就是马总的一句“国有”企业 — 一个真正意义的公用事业!另外,是谁鼓励土豆,优酷建设自己的FLV基础设施呢?我怎么可能跟这些砸了我的事业的人再继续合作呢?这些设备厂商唯一想的事情就是让你多买一些,至于你能不能高效应用这些设备,它们才不关心呢!地球明天会不会因为Global warming而变得风雨无常,你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题,因为他们只关系自己的荷包是不是够满,是不是够钱能够买一部Audi R8 Spyder,明天会不会因为业绩不佳而被裁员…………

我愿意和Intel合作,是因为它总是能告诉我产业发展的方向,我愿意和英业达,富士康,广达,锐捷合作,因为它们总是能够非常快速的反映我们的需求(直接帮助提升我们服务器的效率),我们甚至做到让这些厂商提供原材料的价格(BoM cost),让它们自己提它们认为合理的利润,借此建立一种可持续发展的合作关系。可是,每一次一到采购,我们这些策略就执行不下去(总是买 Dell,Huawei品牌的商用服务器),我也没脸再跟ODM厂商要求开发新的机种(一个原因是厂商没有因为前期研发的付出而获利,另一个原因是 2011年项目没有获得支持,所以研发经费为0)。

就算在中国电信,也知道采购部门必须和需求部门分离,就这样还不能阻挡腐败的发生,我们阿里云却把运行维护,计划建设,采购放在同一个VP下,虽然这么做有助于解决(小)部门KPI被过份放大的问题,但是这三个部门合在一起,许多Check & Balance就消失了,结果当然不是以阿里巴巴的利益为优先,更不要提公用事业这个伟大的理想了!

我为什么不愿再继续写代码 – 这几个月为了提升服务器的性能,我每天工作到半夜,连续了三四个月,在代码的世界里,我很快地就找到了自己,很快地就能够有一些成就感,特别是捡起15年没有再读过的TCP内核代码,我很快乐我能够找出它在LFN(高性能,高延迟(缓存))的不足,但是,做这个工作我只能带动几位工程师,做绿色数据中心,我却能够带动整个中国的互联网基础设施工业,这就是我为什么不愿意再继续写写代码,而是希望能够去改变一个产业。

注:厂商提供的桌面级硬盘的质保也是三年,而根据Google提供的数据,硬盘的年损坏率略低于4%,生命周期内损坏率约为8.6%,也就是说 90%硬盘都能够工作三年,而不是一年半,那么一块硬盘差800元,12块硬盘就是10,000元,11,000台12盘的服务器三年的成本就节省一亿元人民币,这一亿元人民币难道不够让我们请10个高级系统工程师(三万元一个月也就是一亿元的10%),,将我们硬盘跟换的流程优化,所以他们就不必每次跟换硬盘的时候都必须工作到半夜12点?

########################################### 

Oct 132012
 

今天看到淘宝的技术写了一篇交流总结。感觉也印证了我的很多想法。

  1. 公司没有测试人员
  2. 直接上线进行压力测试
  3. 所有技术人员需要了解网站全部架构

 

下面转载内容http://blog.csdn.net/cenwenchu79/article/details/6196886

 

也算机缘巧合,一个不能称之为机会的机会让我再次和国外现在炙手可热的T公司(由于也不想过多的说这家公司的名字,因此就用T作为代号了)做了一次技术和公司文化的简单交流,这里做个简单的交流分享,希望能够让更多的朋友能够从中找到自己团队或者公司有帮助的内容。但这里还是丑话说在前头,中国有句成语:东施效颦。国外的月亮多圆我不知道,但是我们需要客观的看待不同环境的差异,看到目标,而不要过多模仿过程。下面的阐述将都分成场景和观点,如何做三部分,场景描述了具体的情况,观点仅仅代表我自己的一些感触和理解,如何做是对问题Action提出自己的想法。

场景1:

         T公司的任何一个小Team(业务上划分或者职能上划分)都需要熟悉整个系统从前到后从上到下的代码实现。例如相册团队,从前端脚本,到业务逻辑,再到底层的Memcached或者图片服务器代码在必要的时候都能自己修改和实现业务需求。UserGroup团队是负责对全球业务的用户做统计分析的,当希望做一些变革能够尝试着提升用户转化率的时候,首先是考虑自己如何动手去修改已有系统的功能,而不是去协调各个团队去做。

观点:

垂直化的开发模式其实挑战了国内很多企业的横向细分化流水线方式的开发模式。从技术的横向细分,到业务的模块化细分,好处是提高企业的生产效率,坏处是对人全方面的培养成为一种制约。最大的问题:对自己上游系统的需求了解不透彻,对自己依赖系统的实现完全不理解。

如何做:

横向切分的方式和纵向的方式都有适应的场景,因此可以考虑在互连网企业中部分部门中实施垂直化开发模式,这些部门人员素质较高,能够从产品层面全局的考虑整体的发展,通过实际的参与各个业务线和各个层次的技术中间件开发,为横向切分的部门工作做出改进和建议。这样在高素质人才发展和网站规模化整体化发展之间找到平衡点,相互促进。

场景2:

         T公司的任何一个技术框架都可以被挑战和替换,只要用数字和测试结果作为有效的证据,大家都抱着对公司负责的态度来对待技术选型。因此在T公司中,技术的发展完全是最原始的优胜劣汰机制。

观点:

这点其实很赞同,首先技术如果不是用数据来说话,采用自上而下的方式来决定选型,那么就是拍脑袋做事情。另一方面,如果技术不持续的按照用户需求来优化和演进,那么一定会烂掉,最好的触动不断发展的方式,就是竞争。有人会担心技术竞争会带来资源消耗,其实烂掉的东西在被使用的过程中一样在消耗。

如何做:

首先当然还是提倡积累,能够在已有的技术基础上不断积累发展是最好的,其次也应该鼓励创新,如果有足够理由证明成熟的技术能够替代现有技术,而现有技术又没有发展的动力时,变革并不是坏事(也许这种压力就会迫使原有技术实现者去更好服务客户),最后就是给每个人都有改变任何一部分代码的能力,因为依赖的不稳定也决定了上层系统的不稳定,作为一个产品来看,每个人是对产品负责,而不是对一个组件负责。

场景3:

没有任何文档。最多写一点wiki。

观点:

设计从简,代码需要更优雅,注释需要更全面。文档是代码的骨架。

如何做:

应该有产品需求文档,理解业务需求。技术文档多半是总体性设计和一些协议描述,多一些代码注释和Demo,更利于学习和阅读。

场景4:

应用都被编译在一个包里,一台机器就运行了诺大一个网站的所有功能,不存在服务器间的应用服务调用,都是本地服务方法调用(服务依赖较少)。

观点:

这和Java类型的应用还有些差别,Java的第三方依赖较多,版本凌乱复杂,导致应用部署在一台机器上很困难。但很多大型网站的系统设计慢慢地就将模块分的很细,结果导致服务调用和依赖特别复杂,自身的可用性和稳定性变得难以估量。

如何做:

需要审视服务粒度的合理性及垂直化设计在不同系统中的应用,需要在可扩展和可用性及效率中差别对待不同系统设计,同时降低服务差异性,减少应用服务器由于应用差异导致无法复用的问题。

场景5:

任何一个应用或者中间件开发完成后,都会有一个监控应用伴随诞生。(有些是直接通过已有工具实现,有些独立实现)

观点:

1:1的透明化开发比unit test来的还要重要,因为运行期的系统透明化是业务分析,系统优化,系统监控告警最基本的要求。

如何做:

最低代价就是将监控数据记录打点,应用或者外部系统对数据进行计算和分析,最终提供结果给外部系统展现和处理。

场景6:

没有测试团队,任何开发都是测试人员,通过工具完成页面,接口,集成测试。

观点:

强大的测试工具框架为开发人员提供了测试的规范性和便利性,同时开发人员自身的责任感增强,也让开发人员在测试过程中总结和思索开发设计的常规性错误,理解边界问题。

如何做:

需要有专人专职来负责测试框架的有效性,当然对于这个人或者这么一个小团队来说要求很高。可以借鉴的是,测试团队应该有更加高效的方式自动化测试,同时应该将测试框架开放给开发人员,增强开发人员对产品质量的责任感。

场景7:

没有线下的压力测试和极限测试,线上引流和部分区域发布来做测试。

观点:

一直认为线下的网络环境,用户数据的仿真度都难以模拟线上,因此很多压力测试和极限测试的数据基本就不能成为依据。在数据透明化体系完成后,线上的任何改变都可以获得数据的支持,这样单独或者对比的结果就是压力测试或者AB测试的结果。

如何做:

系统透明化工作为基础,结合Beta发布或者局部发布的模式来验证和测试不同压力下的新老系统。

场景8:

Hack Day,一个晚上通宵做出原型,第二天在全公司面前展现创意,用技术来说服有兴趣的同事一起去做一些有创意的工作。T公司最典型的视频项目就出自于Hack Day。

观点:

通过自己努力和时间的投入,在公司给的平台上展现,最后取得好的效果。

如何做:

公司给平台,个人挤时间。

场景9:

公司中所有的开发人员都是Engineer,每个人可能不同Level,但是每个人的工作都是自己来考虑,上级M只是替Engineer去协调资源。此时任何Team的人如果有想法和创意,如果要做,也需要资源,只能靠自己去说服同事一起做,而M没有权利否定或者强制Engineer去做任何工作。

观点:

由于考核都是同事之间点到点的评价,因此其实M没有任何实质性的技术管理职能在,任务分配和工作目标也是工程师自己需要去考虑的,主动权掌握在自己手中。工程师需要去考虑自己有限的工作时间中如何做有效的做出最有用的内容。能力越大责任越大,因此原本认为束缚工程师的方式,其实反而给工程师偷懒思考的机会。

如何做:

在工程师技术能力达到一定阶层时,国内的公司可以考虑采用这样的方式去管理他们,同时为他们提供更广阔的技术空间去创新和渗透到他们希望渗透的产品中。

场景10:

对于问题从效率角度去考虑如何解决,而不是简单的从资源角度去考虑。

观点:

公司发展壮大,业务战线不断变长,往往第一就考虑需要资源,往往忽略了如何用技术提升效率。增加资源有时候反而是增加内耗和降低工作效率的诱因。

如何做:

压力带来动力,决策者需要判断和观察。

场景11:

每个新人进来都会进入新兵训练营,每个人选择自己有兴趣加盟的两到三个团队,一个月内完成两到三个团队的一些线上问题修复,在熟悉业务的同时,也锻炼了自己的能力,同时更加明确自己感兴趣的团队究竟是哪一个。

观点:

这种方式可以最直接的让新人了解业务,熟悉将来的方向,同时也是检验一个人能力的最有效的手段。

场景12:

不同Level的错误有不同的通报,产生较大问题时,全公司邮件通报,但考核并不看问题发生次数和严重程度(因为每个人都可以修改各个层次内容,多做多错,少做少错这种事情不应该鼓励)。同时,任何过失需要描述四方面内容:现象,问题原因,解决方法,防范措施。范例:有一个同事修改了底层配置系统的部分代码,结果导致全站系统2小时不可用,全公司通报。遂这个同事花了几天时间全部重写了底层配置系统代码,为了防止别人和他犯一样的错误,后遇人都笑谈他重写代码的事,而不是那次问题。

观点:

首先,大家都抱着乐观的态度去看待犯错,看到别人的总结,也是审视自己的工作。其次,最重要的是问题的解决和预防,这点是透明化问题的关键所在,也是驱动犯错者改进自身不足的动力。

如何做:

倡导这种氛围,提升工程师的责任感。

场景13:

对于所有代码的更新时间有监控,很久没有更新的代码将会被提出来,作为烂掉的代码告警全团队。

观点:

很多时候不是做减法不易,而是没人知道什么时候该减什么。

时间有限,其实也没谈太多技术内部的东西,但是从周边的这些内容聊下来,两点让我感觉和去年自己做的一些工作很类似,也很重要。产品责任感,系统透明化。

不论是业务或者技术的垂直化,测试工作前移,产品设计后移(在另外文章中有提到),技术工作自我定义,其实都是在考验一个工程师对产品的责任感,不简单的约束自己在某一个技术领域,在某一个产品环节,在某一个岗位职责,也许听起来是一个较高Level的工程师(国内叫架构师)所需要考虑的,但其实也只有这样的工程师才会称得上是合格的工程师。

不论是1:1系统设计方式,线上仿真测试,丰富的监控系统,其实就是要求做每一个业务系统或者技术框架一定要做好透明化工作,系统透明化是对当前系统负责,对依赖这个系统的外部系统负责。当一个网站各个零部件都能被外部所观察到的时候,出现问题不为人知,缓慢出现量变病化,业务模式AB结果都将变得一目了然。

Oct 132012
 

这其实是我一直想要实现的目标。不过要搞定这个不是那么容易。

如果只是用cobbler装系统,puppet部署Openstack,这其实还是在我的能力范围,我可以搞定。不过如果希望整合好,那就无法避免需要做些开发, 这我就搞不定了。

一定要相信,假如你的设想是对的,那么就一定有人在做。如果没有人在做,就说明你的设想是错误的。

http://www.slideshare.net/guanxiaohua2k6/dodai-openstack-2012autumn

https://github.com/nii-cloud

这个项目已经开源,看PPT介绍,做了一个web界面管理。值得好好测试。这是日本的NTT Data做的。他在Openstack社区应该是很活跃的。比较难得的这位朋友感觉是华人。

我找时间测试测试,争取和他交流交流

Oct 112012
 

今天在超微的机器安装ubuntu 12.04,结果出现这个错误

快照2

The partitiontable table format in use on your disks normally requieres youto create a separatepartition for boot loader code.This partition should be marked for use as “Reserved BIOSbootarea” and should be at least 1 MB in size. Notethat this is not the same as a partitionmounted on /boot.
If you do not go back to the partitioning menu and correct this error, boot loader installationmay fail later, although it may still be possibleto installthe boot loaderto a partition.

http://hi.baidu.com/vc277/item/83db7b905a0112dd7a7f01dd

这个错误,我以前听sina的朋友提过,看来我也中招。解决的办法,就是在preseed文件增加多一个1M的分区。

照sina朋友给的办法不行,自己去搜索。这个应该是和他以前装centos的时候,采用类似lvm分区导致的。

http://cptyesterday.wordpress.com/2012/07/20/get-expert_recipe-mdraid-lvm-gpt-and-grub2-playing-together-on-ubuntu-lucid-and-debian-squeeze/

搞定,让我很爽。解决了我一大问题。

d-i partman-auto/expert_recipe string                         \
          boot-root ::                          \
             1 1 1 free                          \
                $iflabel{ gpt }                  \
                method{ biosgrub }               \
              .                                               \
              150 150 150 ext4                                 \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ /boot }                     \
              .                                               \

在我以前的文件里,增加一段就可以。

             1 1 1 free                          \
                $iflabel{ gpt }                  \
                method{ biosgrub }               \
              .                                               \

这其实也算是解决一个大问题。

http://cptyesterday.wordpress.com/2012/06/17/notes-on-using-expert_recipe-in-debianubuntu-preseed-files/

http://cptyesterday.wordpress.com/2012/07/20/get-expert_recipe-mdraid-lvm-gpt-and-grub2-playing-together-on-ubuntu-lucid-and-debian-squeeze/