VM을 가지고 노는데(?) 있어 중요한 요소가 자동화다.(사람마다 다르겠지만...)
자동화와 관련된 Open Source 몇가지를 알아보던중, 괜찮아 보인게 Chef다. Puppet이라고 비슷한 기능을 가진것 같은데, 아직 자세히 보진 못했다. Chef에 어느정도 적응하고 나면 Puppet도 해볼 생각이다. 어차피 둘다 해보긴 해봐야 할것 같기에...

 Chef 관련 정보를 찾다가 아줄 정리가 잘되어 있는 PDF문서도 발견했다. 아래 첨부파일은 한번쯤 보시길...



개략적인 운영방식은 아래와 같다.

  Chef는 기본적으로 Server/Client 구조다. (필요에 따라 Solo로 작동 시킬수도 있다.)
  Chef-Server에서 원하는 Package와 그에 적절한 Configuraton를 사전에 Recipe로 만들어 Cookbook에 등록해두고, Chef-Client에 적절한 수행을 가해주면, 원하는 패키지 설치/제거는 물론이고, 설정까지 자동으로 적용된다. Chef-Clinet는 동일한 기능을 가질수도 있고, 개별적인 기능들을 가지게하여, 하나의 '서버군'을 형성하게 할 수도 있다.(사실 난 아직 해보질 못했음...ㅡㅡ;;).

  또 Chef-Server 설정에 따라, 특정 Chef-Client가 관리자 실수나, 기타 장애로 설정값이 변경되거나, Chef로 관리되는 서비스에 문제가 발생됬다고 판단될 경우, Package와 Configuration을 자동 복원하고, 서비스를 다시 시작해준다. 매역적인 기능이다.

  서로 다른 여러 기능의 Chef-Clinet를 조합하여, 한의 부하 분산 서버군을 구성할 수도 있을 것 같다. 그것도 각각의 VM에 접속할 필요 없이. Chef-Server에서 몇번의 명령만으로... 관리 포인트도 하나로 집중시킬수도 있을 것 같고... 무식한 영어 실력으로 더듬더듬한 내용이지만, 대충 그런것 같다.

그리고, Chef에서는 Cookbook/Recipe가  굉장히 중요한 요소 같다. 아니 Chef의 전부인듯........
각자가 원하는 Recipe를 만들수도 있지만, 아마도 내가 만들고자 하는 Recipe와 90%이상은 유사한 Recipe가 이미 오픈되어 공유되고 있다. 실제로 Cookbook을 한번 다운로드 받아 봤더니 아래와 같이...........엄청..........ㅜㅡ;; 보시다 시피 어지간한 세트는 다 이미 마련되있다. 세부 설정은 해당 recipe의 Configuration을 아주 약간 변형함으로서 내가 원하는 형태로 배포/설정 할수 있다. (그리고 OPSCode라는 곳에서는 더 많은 레시피를 제공받을 수 있는 것 같다. 이부분은 좀더 확인해 봐야 함....)

Chef Cookbook에 포함되어 있는 Recipe (git clone git://github.com/opscode/cookbooks.git)

[root@localhost chef-repo]# ll

total 44

drwxr-xr-x   8 root root 4096 Mar 25 13:10 .

drwxr-xr-x   3 root root 4096 Mar 25 13:14 ..

drwxr-xr-x   2 root root 4096 Mar 25 13:10 certificates

drwxr-xr-x   2 root root 4096 Mar 25 13:10 config

drwxr-xr-x 129 root root 4096 Mar 25 13:11 cookbooks

drwxr-xr-x   2 root root 4096 Mar 25 13:10 data_bags

drwxr-xr-x   8 root root 4096 Mar 25 13:10 .git

-rw-r--r--   1 root root   18 Mar 25 13:10 .gitignore

-rw-r--r--   1 root root 2171 Mar 25 13:10 Rakefile

-rw-r--r--   1 root root 3521 Mar 25 13:10 README.md

drwxr-xr-x   2 root root 4096 Mar 25 13:10 roles

[root@localhost chef-repo]# 

[root@localhost chef-repo]# 

[root@localhost chef-repo]# ll cookbooks/

total 548

drwxr-xr-x 129 root root  4096 Mar 25 13:11 .

drwxr-xr-x   8 root root  4096 Mar 25 13:10 ..

drwxr-xr-x   5 root root  4096 Mar 25 13:11 activemq

drwxr-xr-x   3 root root  4096 Mar 25 13:11 ant

drwxr-xr-x   7 root root  4096 Mar 25 13:11 apache2

drwxr-xr-x   4 root root  4096 Mar 25 13:11 apparmor

drwxr-xr-x   5 root root  4096 Mar 25 13:11 application

drwxr-xr-x   6 root root  4096 Mar 25 13:11 apt

drwxr-xr-x   6 root root  4096 Mar 25 13:11 aws

drwxr-xr-x   6 root root  4096 Mar 25 13:11 bluepill

drwxr-xr-x   3 root root  4096 Mar 25 13:11 boost

drwxr-xr-x   3 root root  4096 Mar 25 13:11 build-essential

drwxr-xr-x   4 root root  4096 Mar 25 13:11 capistrano

drwxr-xr-x   5 root root  4096 Mar 25 13:11 chef

drwxr-xr-x   5 root root  4096 Mar 25 13:11 chef-client

drwxr-xr-x   7 root root  4096 Mar 25 13:11 cloudkick

-rw-r--r--   1 root root   408 Mar 25 13:11 CONTRIBUTING

drwxr-xr-x   6 root root  4096 Mar 25 13:11 couchdb

drwxr-xr-x   3 root root  4096 Mar 25 13:11 cron

drwxr-xr-x   7 root root  4096 Mar 25 13:11 daemontools

drwxr-xr-x   4 root root  4096 Mar 25 13:11 database

drwxr-xr-x   4 root root  4096 Mar 25 13:11 django

drwxr-xr-x   7 root root  4096 Mar 25 13:11 djbdns

drwxr-xr-x   6 root root  4096 Mar 25 13:11 dmg

drwxr-xr-x   3 root root  4096 Mar 25 13:11 drbd

drwxr-xr-x   6 root root  4096 Mar 25 13:11 dynect

drwxr-xr-x   5 root root  4096 Mar 25 13:11 dynomite

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ec2

drwxr-xr-x   3 root root  4096 Mar 25 13:11 emacs

drwxr-xr-x   4 root root  4096 Mar 25 13:11 erlang

drwxr-xr-x   4 root root  4096 Mar 25 13:11 fail2ban

drwxr-xr-x   6 root root  4096 Mar 25 13:11 gems

drwxr-xr-x   4 root root  4096 Mar 25 13:11 git

drwxr-xr-x   8 root root  4096 Mar 25 13:11 .git

-rw-r--r--   1 root root    38 Mar 25 13:11 .gitignore

drwxr-xr-x   5 root root  4096 Mar 25 13:11 glassfish

drwxr-xr-x   4 root root  4096 Mar 25 13:11 gnu_parallel

drwxr-xr-x   5 root root  4096 Mar 25 13:11 god

drwxr-xr-x   7 root root  4096 Mar 25 13:11 gunicorn

drwxr-xr-x   4 root root  4096 Mar 25 13:11 hadoop

drwxr-xr-x   5 root root  4096 Mar 25 13:11 haproxy

drwxr-xr-x   3 root root  4096 Mar 25 13:11 heartbeat

drwxr-xr-x   3 root root  4096 Mar 25 13:11 imagemagick

drwxr-xr-x   4 root root  4096 Mar 25 13:11 instiki

drwxr-xr-x   6 root root  4096 Mar 25 13:11 iptables

drwxr-xr-x   6 root root  4096 Mar 25 13:11 java

drwxr-xr-x   3 root root  4096 Mar 25 13:11 java_sun

drwxr-xr-x   5 root root  4096 Mar 25 13:11 jetty

drwxr-xr-x   6 root root  4096 Mar 25 13:11 jira

drwxr-xr-x   5 root root  4096 Mar 25 13:11 jpackage

drwxr-xr-x   4 root root  4096 Mar 25 13:11 keepalived

drwxr-xr-x   5 root root  4096 Mar 25 13:11 kickstart

-rw-r--r--   1 root root 10850 Mar 25 13:11 LICENSE

drwxr-xr-x   5 root root  4096 Mar 25 13:11 logrotate

drwxr-xr-x   3 root root  4096 Mar 25 13:11 logwatch

drwxr-xr-x   3 root root  4096 Mar 25 13:11 lvm

drwxr-xr-x   3 root root  4096 Mar 25 13:11 man

drwxr-xr-x   5 root root  4096 Mar 25 13:11 maradns

drwxr-xr-x   3 root root  4096 Mar 25 13:11 maven

drwxr-xr-x   6 root root  4096 Mar 25 13:11 memcached

drwxr-xr-x   3 root root  4096 Mar 25 13:11 mercurial

drwxr-xr-x   7 root root  4096 Mar 25 13:11 munin

drwxr-xr-x   8 root root  4096 Mar 25 13:11 mysql

drwxr-xr-x   8 root root  4096 Mar 25 13:11 nagios

drwxr-xr-x   3 root root  4096 Mar 25 13:11 nanite

drwxr-xr-x   7 root root  4096 Mar 25 13:11 nginx

-rw-r--r--   1 root root   999 Mar 25 13:11 NOTICE

drwxr-xr-x   3 root root  4096 Mar 25 13:11 nscd

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ntp

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ohai

drwxr-xr-x   5 root root  4096 Mar 25 13:11 one-shot

drwxr-xr-x   6 root root  4096 Mar 25 13:11 openldap

drwxr-xr-x   4 root root  4096 Mar 25 13:11 openssh

drwxr-xr-x   4 root root  4096 Mar 25 13:11 openssl

drwxr-xr-x   5 root root  4096 Mar 25 13:11 openvpn

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ossec

drwxr-xr-x   5 root root  4096 Mar 25 13:11 packages

drwxr-xr-x   5 root root  4096 Mar 25 13:11 pacman

drwxr-xr-x   5 root root  4096 Mar 25 13:11 passenger_apache2

drwxr-xr-x   5 root root  4096 Mar 25 13:11 passenger_enterprise

drwxr-xr-x   5 root root  4096 Mar 25 13:11 perl

drwxr-xr-x   7 root root  4096 Mar 25 13:11 php

drwxr-xr-x   5 root root  4096 Mar 25 13:11 postfix

drwxr-xr-x   5 root root  4096 Mar 25 13:11 postgresql

drwxr-xr-x   5 root root  4096 Mar 25 13:11 pxe_dust

drwxr-xr-x   6 root root  4096 Mar 25 13:11 python

drwxr-xr-x   5 root root  4096 Mar 25 13:11 quick_start

drwxr-xr-x   5 root root  4096 Mar 25 13:11 rabbitmq

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rabbitmq_chef

drwxr-xr-x   6 root root  4096 Mar 25 13:11 radiant

drwxr-xr-x   5 root root  4096 Mar 25 13:11 rails

drwxr-xr-x   4 root root  4096 Mar 25 13:11 rails_enterprise

-rw-r--r--   1 root root  1227 Mar 25 13:11 Rakefile

-rw-r--r--   1 root root   659 Mar 25 13:11 README

drwxr-xr-x   5 root root  4096 Mar 25 13:11 redmine

drwxr-xr-x   4 root root  4096 Mar 25 13:11 reprepro

drwxr-xr-x   5 root root  4096 Mar 25 13:11 resolver

drwxr-xr-x   8 root root  4096 Mar 25 13:11 riak

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rsync

drwxr-xr-x   6 root root  4096 Mar 25 13:11 rsyslog

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ruby

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ruby_enterprise

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rubygems

drwxr-xr-x   7 root root  4096 Mar 25 13:11 runit

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rush

drwxr-xr-x   7 root root  4096 Mar 25 13:11 samba

drwxr-xr-x   7 root root  4096 Mar 25 13:11 sbuild

drwxr-xr-x   3 root root  4096 Mar 25 13:11 screen

drwxr-xr-x   5 root root  4096 Mar 25 13:11 snort

drwxr-xr-x   7 root root  4096 Mar 25 13:11 solr

drwxr-xr-x   3 root root  4096 Mar 25 13:11 sqlite

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ssh_known_hosts

drwxr-xr-x   4 root root  4096 Mar 25 13:11 stompserver

drwxr-xr-x   5 root root  4096 Mar 25 13:11 subversion

drwxr-xr-x   5 root root  4096 Mar 25 13:11 sudo

drwxr-xr-x   4 root root  4096 Mar 25 13:11 teamspeak

drwxr-xr-x   5 root root  4096 Mar 25 13:11 teamspeak3

drwxr-xr-x   3 root root  4096 Mar 25 13:11 thrift

drwxr-xr-x   3 root root  4096 Mar 25 13:11 tmux

drwxr-xr-x   5 root root  4096 Mar 25 13:11 tomcat

drwxr-xr-x   8 root root  4096 Mar 25 13:11 tomcat6

drwxr-xr-x   5 root root  4096 Mar 25 13:11 trac

drwxr-xr-x   8 root root  4096 Mar 25 13:11 transmission

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ubuntu

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ucspi-tcp

drwxr-xr-x   5 root root  4096 Mar 25 13:11 unicorn

drwxr-xr-x   4 root root  4096 Mar 25 13:11 users

drwxr-xr-x   5 root root  4096 Mar 25 13:11 varnish

drwxr-xr-x   4 root root  4096 Mar 25 13:11 vim

drwxr-xr-x   5 root root  4096 Mar 25 13:11 wordpress

drwxr-xr-x   3 root root  4096 Mar 25 13:11 xfs

drwxr-xr-x   3 root root  4096 Mar 25 13:11 xml

drwxr-xr-x   8 root root  4096 Mar 25 13:11 zenoss

drwxr-xr-x   3 root root  4096 Mar 25 13:11 zlib

drwxr-xr-x   3 root root  4096 Mar 25 13:11 zsh

[root@localhost chef-repo]# 

 
   
이제 슬슬 간단한 것 부터 한번 실제로 해봐야 겠다..........
Posted by 사랑줍는거지
,

Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?


http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-always-use-apache-httpd-front-apache-tomcat-improve-perform


원문은 : 위 링크

Apache-Tomcat과 httpd의 핵심 개발자들이 직접 작성한 내용입니다. 오늘 옆팀에서 Apache만 붙이면 성능이 떨어진다고 해서 좀 봐주다가 찾은 자료네요. PHP를 서비스 하거나, 기타 Apahce의 특정 모듈기능을 필요하지 않는다면, 다시 말해 단순 정적인 웹서비스에서는 굳이 httpd서버를 Tomcat앞단에 둘필요는 없을듯 합니다. 흔히들 대부분의 개발자들이 기본적인 HTTP요청은 Apache가 처리하고 Tomcat내에서 처리될 자바 어플리케이션만 Tocmat으로 보내 처리되도록 하는게 가장 성능이 좋을것이라 믿어 왔지만. 구조상으로 봐도, 더 좋을리는........ Tomcat의 Apache Native Module성능이 httpd에 비교해 전혀 차이가 없는데..........(PHP등을 사용한다면, Apache가 앞단에 있어야 하니, 그런 부분은 논외 처리. 번거로움없이 일반유저로 80포트를 사용하고 싶다거나, Tomcat에러페이지를 관리 하고 싶다거나, 등등 나름대로 Apache를 앞단에 두어야 할 이유도 충분히 있다. 이글의 요점은 Apache를 앞단에 두어서는 안된다~가 아니니 오해 없기를~)
 

Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?

 posted by mthomas on April 14, 2010 11:14 PM

The short answer is that this is a myth. The longer answer is that back in the days of Tomcat 3 there was some truth to this depending on circumstances. However, for the versions of Tomcat in use today (5.5.x and 6.0.x) then there is no need to use httpd for purely performance reasons. Tomcat now supports the native/APR connector which uses the same native library (the Apache Portable Runtime—APR) as httpd for the low-level I/O and therefore can achieve similar performance to httpd. When serving static content there is ever so slightly more overhead when using Tomcat compared to httpd but the differences are so small they are unlikely to be noticeable in production systems.

If you research the httpd vs Tomcat performance issue, you will find a variety of load and performance benchmarks that show a range of results. An often quoted result shows that Tomcat's pure Java connector is consistently faster than httpd.

This particular result is the opposite of what is expected. httpd should be significantly faster than Tomcat's pure Java connector. This result is probably caused by the size of the file used. Tomcat caches small static files in memory by default and this will provide a significant performance improvement. httpd does not cache files in memory by default. This demonstrates quite nicely how the definition of the benchmark can have a significant impact on the results.

The performance testing performed by Christopher Schultz, a regular on the Tomcat users mailing list, used a wider range of file sizes and provides – in my view – better results. The results of his tests are shown in the graph below.

Click to see larger image

These results are much more in line with what is expected, although there are a few interesting points to note:

  • Apache httpd and Coyote APR/native show similar performance levels.
  • Coyote NIO isn't too far behind httpd and Coyote APR/native.
  • There appears to be a limit on the usefulness of sendfile. This may be a hardware limitation but is worthy of further attention. I've added this to my todo list.
  • For small file sizes (less than ~10KiB) the static file caching in Tomcat provides a significant performance boost.

The detailed results for any performance test will vary with a number of factors such as the hardware used, the number of concurrent requests, the use of keep-alive and the use of caching. These factors can change the results of a particular test but the broad performance results will remain the same:

  • httpd and Coyote APR/native typically have similar performance.
  • Coyote NIO is typically just behind Coyote APR/native (further behind for SSL).
  • Coyote BIO will typically offer the lowest performance.

The settings to achieve the best performance will vary from application to application. The best settings for an application will depend significantly on the size of the resources, the ratio of static to dynamic content, the number of concurrent users, the usage patterns of those users and so on. Generally, performance can be improved by increasing the cacheMaxSize for the context, increasing the number of connector threads (using maxThreads [4]) available to process requests and enabling keep-alive (using maxKeepAliveRequests) but all of these come at the cost of increased resource usage. There is a trade-off to make here between performance and resource usage that will be different for each application.

It should also be noted that there is no magic "make it run faster" option in Tomcat. If your application takes 15s to generate a request, there is nothing that Tomcat can do to improve that. You'll need to profile your application to understand why requests are taking that long and then tune your application code appropriately.

While raw performance for static content may not be a good reason to use httpd, there are a number of good reasons why you might want to use httpd with Tomcat. The most frequent reason is to provide load-balancing to two or more Tomcat instances. httpd isn't the only option to so this - hardware load balancers or other reverse proxies can be used - but it is a popular choice amongst system administrators as many of them are already familiar with httpd. I'll write more on using httpd as a load-balancer in a future article.

httpd is also used with Tomcat when there is a requirement to support technologies other than Java. While Tomcat can support PHP or Perl, the support for these is better in httpd. Therefore, for sites that need a mix of technologies httpd can be used as the front-end web server, directing requests to mod_php, mod_fastcgi, mod_proxy_http (for Tomcat) or any other module as appropriate.

httpd's support for integrated Windows authentication is also a reason for using httpd in front of Tomcat. There are Tomcat based solutions for integrated windows authentication and, as these gain acceptance through wider use, this particular reason for using httpd may become less important. However, at the moment, it remains one of the more frequently cited reasons for using httpd with Tomcat.

In summary, there are good reasons for using httpd with Tomcat but raw performance for static content isn't one of them. If you are using httpd solely to improve static content performance then I recommend taking a look at the Coyote APR/native connector for Apache Tomcat.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.

Comments

Configuring Response Headers

We're currently using Apache Httpd to handle such things as expires by type and gzip configuration. I wonder if these things can be set up in tomcat, thereby eliminating the httpd layer for us.

CDN & Throughput

I think that it is useful to use the httpd when you are configuring the Content Delivery Network.

IMHO if you use both the httpd and tomcat on different machines, each can fully concentrate only on its work. Tomcat's threads can compute your application's logic and use the whole memory for speed up the application. Whilst httpd's threads can serve the content from the disk. This can improve the throughput.

-- tom

Different Myth(?)

While this post answers the myth question of native HTTP vs Tomcat HTTP, if you are using a native HTTP to do (perhaps) other services, I'm curious about whether it's myth or truth that one should go with AJP or HTTP for the native<->Tomcat communication. The tomcat documentation mostly seems to suggest that this should be AJP rather than HTTP - is this still just a myth?


Posted by 사랑줍는거지
,
커널 컴파일을 해야할 일이 생겼다. 실용단계에 있는 건 아니지만, 분산파일시스템으로서 2.6.34부터 kernel 베이스 라인에 포함된 ceph라는 걸 테스트 해보라는 Order가 떨어진 관계로.. 그런데!!!! 지난주 목요일 부터, CentOS 5.5 x86_64의 커널을 최신으로 올릴려고 하는데, 이게 컴파일도 에러 없고, 설치 완료하고 부팅만 하면 아래 에러와 함께 Kernel Panic에 빠져 버린다.

Mounting root filesystem.mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fssetup
root: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /devunmounting old /procunmounting old /sysswitchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

 
구글링 해봐도, 해결책 찾기가 쉽지 않았다. 뭐 root 파일시스템 지정을 LABEL로 하지말고, /dev/sda3등과 같은 실제 장치명으로 하라는... 뻔한 이야기들만.........
VMware에서 진행했던거라, 혹시, VMware SCSI모듈쪽 문제인가 싶어, 커널에 VMware관련 모듈도 포함시켜 봤지만 소용없었음.

별짓을 다 해봤지만, 해결이 되지 않던 와중, 역시 구글 형님께서 해결의 실마리를 주셨음.
(링크 : http://funky-dennis.livejournal.com/3290.html)
문제는, 커널 컴파일 설정중 CONFIG_SYSFS_DEPRECATED_V2=y 가 활성화 되어 있어야 했다.
실제 적용해보니 그렇게 실패했던 것이 한방에 성공했다.
허무하다...ㅡㅡ;; 그러고 보니 커널 컴파일을 해본지가 너무 오래됐넹... 예전에 호스팅회사 있을때는 커널 컴파일 건수가 자주 있어 그럭저럭 대처했었는데, 하나도 기억이 안난다. 메롱이다 ㅡㅡ;;


적용방법은, make menuconfig 상에서 아래와 같이 체크 해줌
General setup ->
[*] enable deprecated sysfs features to support old userspace tools
[*]   enabled deprecated sysfs features by default 


최종적으로 .config 내용에서 아래와 같이 되어 있어야 한다.
# grep CONFIG_SYSFS_DEPRECATED .config
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y


 위 옵션의 역할에 대해서 현재 나로선 정확히 모른다. enable/disable에 따라 뭐가 다른지 분명히 해야 하는데.. 관련 정보는 나중에 구글에서 좀더 찾아봐야 겠다. 


(내용 추가)
하나 해결되니, 다른게 또 튀어 나오는군...;;;
커널 부팅은 정상이나, 부팅중 fail 하나 발견...ㅡ.ㅡ Udev관련된것 같긴 한데, 자세한건 또 손가락 품팔이 할수 밖에... 잇힝;; 이거 말고도 할거 많은데, 시작부터~

  -> 급히 검색해본 결과로는  CONFIG_SYSFS_DEPRECATED 옵션 y일경우, 발생함. 그렇다고 해당 옵션을 끌수는 없는 상황(끄면 부팅이 안되므로..ㅡㅡ;)이라, 우선은 이 메세지는 무시하기로 함. (자세한 조사는 뒤로...뒤로..뒤로...;;;)
Posted by 사랑줍는거지
,