Difference between pages "Install/ru/Partitioning" and "Making the Distribution, Part 2"

< Install(Difference between pages)
(Метод (UEFI/GPT) "Модерн")
 
m
 
Line 1: Line 1:
<noinclude>
+
{{Article
{{InstallPart|процесс разбиения диска и создания файловых систем}}
+
|Summary=In his previous article, Daniel Robbins told the story of how he became a Stampede Linux developer and why he eventually left Stampede to start the Enoch Linux distribution. In this go-round he lets you in on the strange events that happened after the Enoch development team discovered a little-known, blazingly fast compiler.
</noinclude>
+
|Article Category=General
=== Подготовка жесткого диска ===
+
|Author=Drobbins
 +
|Previous in Series=Making the Distribution, Part 1
 +
|Next in Series=Making the Distribution, Part 3
 +
}}
 +
== From Enoch to Gentoo, via minor setbacks and corporate run-ins ==  
  
В этой части  мы научимся различным способам установки Funtoo Linux -- и загрузки с -- жесткого диска.
+
=== First steps to Enoch ===
  
==== Введение ====
+
In my previous article, I gave you the low-down on my days with the Stampede development team and why I left (to get away from lower-level politically-minded, project-controlling "freaks"). Because of the interference from these meddlesome by-standers, I figured it would be easier to put together my own Linux distribution than to continue improving Stampede under such dirty conditions! Fortunately I took with me a considerable amount of experience based on my (may I say substantial?) work for Stampede, including maintaining several of their packages, designing the initialization scripts, and leading the slpv6 (next-generation package management project).
  
В прежние времена существовал лишь один способ загрузить PC-совместимый компьютер. Все наши дектопы и сервера имели стандартный PC BIOS, все наши харды использовали MBR и были разбиты используя схему разбивки MBR. Вот как это все было и нам это нравилось!
+
The distribution I began working on, code-named Enoch, was going to be blazingly fast because it would completely automate the package creation and upgrading process. I have to admit that this was in large part because I was a one-member team and couldn't afford to spend my time on repetitive work that my development box could be automated to do for me. And since I was designing a complete distribution from scratch (rather than "spinning off" from someone like RedHat), I had my work cut out for me and needed all the free time I could scrounge up.
  
Затем появились EFI и UEFI, встроенные программы нового образца наряду со схемой разбивки GPT, поддерживающая диски размером более 2.2TБ. Неожиданно, нам стали доступны различные способы установки и загрузки Линукс систем . То, что было единым методом, стало чем-то более сложным.
+
After getting my basic Enoch system up and running, I headed back to irc.openprojects.net and started my own channel called #enoch. From there I gradually assembled a team of about ten developers. In those early days we all hung out on IRC and worked on the distribution in our spare time. As we communally and cooperatively hacked away at it, finding and fixing new bugs, Enoch became more functional and professional every day.
  
Воспользуемся моментом и рассмотрим доступные способы конфигурации жесткого диска для загрузки Funtoo Linux. Данное Руководство рекомендует способ "по-старинке" , загрузка BIOS и использование MBR.  Данный способ работает (за исключением редких случаев) и всесторонне поддерживается. И в этом нет ничего плохого. Если Ваш жесткий диск 2TБ или меньшего размера это не является препятствием для использования всего дискового пространства.
+
=== The first roadblock ===
  
Но, бывают ситуации когда метод "по-старинке"  не является оптимальным. Если Ваш жесткий диск размером более 2TБ , MBR разбивка не сможет обеспечить доступ ко всему дисковому пространству. Это одна из причин. Вторая причина: существуют  "PC" системы, которые более не поддерживают  BIOS загрузку  и  форсируют UEFI загрузку. Из чувства сострадания к тем, кто попал в затруднение перед выбором, это Руководство также описывает установку и загрузку UEFI систем.
+
One inevitable day, Enoch hit its first roadblock. After adding Xfree86, glib, and gtk+, I decided to get xmms (an X11/gtk+-based MP3/CD player app) working. I figured it was time to celebrate with some music! But after installing xmms, I tried to start it... and X locked up! At first I thought xmms locked up because I used insane compiler optimizations ("-O6 -mpentiumpro", in case you were wondering). My first thought, to compile xmms with standard optimizations, didn't solve the problem. So I started looking elsewhere. After spending a full week of development time trying to track down the problem, I got an e-mail from an Enoch user, Omegadan, who was also experiencing xmms lockups.
  
Мы всё же рекомендуем разбивку "по-старинке". Загрузчик, который мы используем для загрузки Линукс в этом руководстве называется GRUB,  таки образом мы называем метод  как '''BIOS + GRUB (MBR)''' . Это традиционный способ установки на PC-совместимые компьютеры.
+
We corresponded for a while, and after many hours of testing we determined that the problem was a POSIX threads-related issue. For some reason, a pthread_mutex_trylock() call did not return the way it should. As the creator of a distribution, these were the types of bugs I really didn't want to encounter. I counted on the developers to release perfect sources so I could focus on enhancing the Linux experience rather than getting buggy sources to work. Of course I soon learned that this was an unrealistic expectation, and that problems like this will always pop up from time to time.
  
Если Вам необходимо использование UEFI для загрузки, мы советуем не использовать MBR вообще, ввиду того, что некоторые системы поддерживают MBR, а некоторые нет. Вместо, мы советуем использование UEFI  для загрузки GRUB, который, затем в свою очередь загрузит Линукс. Мы называем этот  метод как '''UEFI + GRUB (GPT)'''.
+
As it turned out, the problem wasn't with xmms, gtk+, or glib. And it wasn't an issue with Xfree86 3.3.5 not being thread-safe and locking up. Surprisingly, we found the bug in the Linux POSIX threads implementation itself, part of the GNU C library (glibc) version 2.1.2. I was shocked at the time to find that such a critical part of Linux had such a major bug. (And we used a release version of glibc in Enoch, not a prerelease or CVS version!).
  
И да, есть еще несколько способов, некоторые из них задокументированы в [[Boot Methods]] . Обычно мы рекомендуем  '''BIOS + GRUB (GPT)''' метод, но он ограничивается не столь широкой поддержкой со стороны комплектующих.
+
So how did we track down the problem? Actually, we never were able to come up with a bug fix, but at one point I stumbled across a couple of e-mails on the glibc developer mailing list from another person who had the same problem. The glibc developer who replied posted a patch that solved the thread problem for us. But I was curious why RedHat 6 (which also used glibc 2.1.2) didn't suffer from this problem since the patch was just posted and RedHat 6 had been available for some time. To find out, I downloaded RedHat's glibc SRPM (source RPM) and took a look at their patches.
  
'''Вопрос --  какой из методов использовать?'''  Вот какой.
+
RedHat had their own homegrown glibc patch that solved the pthread_mutex_trylock() issue. Apparently they experienced the same problem and created their own custom fix. Too bad they didn't send this patch "upstream" to the glibc developers so it could be shared with the rest of the world. But who knows, maybe RedHat sent the patch upstream and for some reason the glibc developers didn't accept it. Or maybe the thread bug was triggered by a specific combination of compiler and binutils versions, and RedHat never ran into it (although they did have a thread patch in their SRPM). I suppose we'll never know exactly what happened. But I did learn that RedHat SRPMs contain a lot of private bug fixes and tweaks that never seem to make it upstream to the original developers. I'm going to rant about this for a little while.
  
;Принцип 1 - "По-старинке":  Если Вы можете успешно загрузить System Rescue CD и видите синее меню, то Вы используете BIOS,  и скорее всего Вы можете загрузить Funtoo Linux используя BIOS. Итак,  следуйте этому способу и используйте BIOS загрузку,  кроме случаев Вам по-какой либо причине необходим UEFI, например если размер жесткого диска >2.2TБ.  В этом случае следуйте Принцип  2.
+
=== Rant ===
  
;Принцип 2 - "Модерн":  Если Вы можете успешно загрузить System Rescue CD и видите черно-белое меню -- поздравления,  Ваша система поддерживает UEFI загрузку. Это значит, что Вы готовы установить Funtoo Linux к загрузке с помощью UEFI. Ваша система также может поддерживать загрузку BIOS, но попрбуйте UEFI для начала. Вы можете "покопаться" в настройках BIOS.
+
When you put together a Linux distribution it's really important that any bug fixes you create are sent upstream to the original developers. As I see it, this is one of the many ways that distribution creators contribute to Linux. We're the guys who actually get all these different programs working as a unified whole. We should send our fixes upstream as we unify so that other users and distributions can benefit from our discoveries. If you decide to keep bug fixes to yourself, you're not helping anyone; you're just ensuring that a lot of people will waste time fixing the same problem over and over again. This kind of policy goes against the whole open source ethic and stunts the growth of Linux development. Maybe I should say that it "bugs" us all.
  
;Какая разница между "По-старинке" и "Модерн"?:  Если Вы следуете  MBR разбивке, Ваш <code>/boot</code> раздел будет отформатирован файловой системой ext2 , и Вы будете использовать <code>fdisk</code> для создания MBR разделов.  Если Вы следуете "модерн", GPT разделам и UEFI загрузке,  Ваш <code>/boot</code> раздел будет отформатирован  в файловую систему vfat,  поскольку это единственная файловая система поддерживаемая UEFI, и Вы будете использовать <code>gdisk</code> для создания GPT разделов.  И Вы установите GRUB несколько иначе.  Вот к чему сводится различие между методами.
+
It's unfortunate that some distributions (ahem) aren't as good (RedHat) as others (Debian) about sharing their work with the community.
  
;Имейте в виду: Для установки Funtoo Linux используя метод "модерн", Вы должны загрузить System Rescue CD в UEFI режиме -- и увидеть начальное черно-белое меню. В противном случае, UEFI не активно и Вы не сможете продолжить!
+
=== Compiler drama ===
  
{{Note|'''Некоторые материнские платы якобы поддерживают UEFI, но на самом деле нет.''' Исследуйте . К примеру, Award BIOS в моей Gigabyte GA-990FXA-UD7 rev 1.1 имеет возможность включить UEFI загрузку для CD/DVD. '''Этого не достаточно для обеспечения UEFI загрузки для жестких дисков и установки Funtoo Linux.''' UEFI должно поддерживать и сьемные носители (таким образом Вы сможете загрузить System Rescue CD используя  UEFI) и жесткие диски (Вы можете загрузить Funtoo Linux.) Оказывается, что более поздние ревизии этой платы (rev 3.0) имеют новую версию BIOS который полностью поддерживает UEFI. Это приводит к третьему принципу -- знайте Ваши комплектующие.}}
+
During the time we were trying to fix the glibc threads problem, I e-mailed Ulrich Drepper (one of the guys at Cygnus who is heavily involved with glibc development). I mentioned the POSIX thread problem we were having, and that Enoch was using pgcc for optimum performance. And he responded with something like this (I'm paraphrasing here): "Our own compiler included with the CodeFusion product has an excellent x86 backend that produces executables far faster than those generated with pgcc." Obviously, I was very interested in testing out this mystery "turbo" compiler the Cygnus guys had created.
  
==== Метод (BIOS/MBR) "По-старинке" ====
+
I thereupon requested a demo copy of Cygnus Codefusion 1.0 so that I could test it out, and Omegadan and I were amazed to find that this compiler was everything that Ulrich claimed and then some. The x86 backend increased the performance of some of the CPU-intensive executables (like bzip2) by close to 90%! All applications seemed to benefit from at least a 10% real-world performance increase, and all we did was swap out compilers. Enoch even booted 30 - 40% faster. The performance gains were far, far greater than what we gained by switching from gcc to pgcc. Obviously, after experiencing it for ourselves, we wanted to use this compiler for Enoch. Fortunately, the sources were included on the CodeFusion CD and were released under the GPL, so we were fully permitted to use this compiler... or so we thought.
  
{{Note|Используйте данный метод при загрузке с помощью BIOS,  и если System Rescue CD имеет начальное меню загрузки светло-голубое.  Если Вы собираетесь использовать "модерн", [[#Метод (UEFI/GPT) "Модерн"|кликните здесь в меню UEFI/GPT.]]}}
+
=== Let the freakiness begin ===
  
===== Подготовка =====
+
I sent an e-mail to the marketing manager at Cygnus to let them know our intentions, expecting a "yeah, go for it, thanks for using our compiler" response. Instead the reply was that although we were (technically) allowed to use the Cygnus compiler, we were strongly urged not to use or include the compiler sources with Enoch. I responded by asking why they had released the source under the GPL, if that was the case. It's my guess that if they had a choice, they wouldn't have used the GPL, but because they derived their compiler from egcs (released under the GPL), they had no choice.
  
Прежде чем начать , неплохо бы удостовериться, что Вы используете нужный диск для разбивки. Попробуйте эту комманду и проверьте, что <code>/dev/sda</code> тот самый диск, который Вы желаете разбить:
+
This is a good example of a situation where the GPL prevented a company from creating a proprietary product based on open sources. My educated guess is that Cygnus was afraid that if we used their compiler we would undermine their boxed product sales, which would be especially strange because none of their marketing materials (nor the InfoWorld review) mentioned the new compiler included with CodeFusion. CodeFusion was marketed solely as a "development IDE" product, not as a compiler.
  
<console>
+
In an attempt to put some of their paranoia to rest, I offered to endorse CodeFusion and place the endorsement on our Web site with a link to help spur CodeFusion sales. Personally I didn't think that a "turbo" Enoch would negatively affect their sales, since CodeFusion was marketed as an IDE. But I tried nevertheless to make them happy. The IDE component of CodeFusion was a commercial product, and we had no desire or intention (or right) to distribute it with Enoch.
# ##i##fdisk -l /dev/sda
+
  
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
+
I e-mailed my (generous?) offer to Cygnus and received another strange response. They wanted authority over all of our "marketing materials" (apparently, this also included the content of our Web site!) Another shocker. The Cygnus marketing team seemed to have no grasp of how the Linux community or the GPL worked, so I decided to cut off communication with Cygnus for the indefinite future. In the mean time, we created a private "turbo" and public "non-turbo" version of Enoch, leaving the final decision for later.
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk label type: gpt
+
  
 +
But after several months they integrated the CodeFusion x86 backend into gcc 2.95.2. Now everyone could benefit from the nice new backend, not just the people who knew about the "secret GPL compiler" included on the CodeFusion CD. But we decided to go ahead and use gcc rather than the CodeFusion compiler. In addition to being more stable, gcc 2.95.2 also allowed us avoid Cygnus, which by this time had been purchased by RedHat for a ridiculous sum of money. (Note: the new x86 backend in gcc 2.95.2 is what gave newer Linux distributions the significant speed boost that we all got to experience. It also gave FreeBSD 4.0 a nice speed boost over 3.3.6. Notice the difference?)
  
#        Start          End    Size  Type            Name
+
=== On the soapbox ===
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
+
</console>
+
  
Теперь, рекомендуем стереть  существующие таблицы разделов  MBR или GPT,  которые могут помешать BIOS во время загрузки. Мы используем комманду <code>sgdisk</code>:
+
Thanks to this and other experiences, I've learned a lot about for-profit open source companies. There's absolutely nothing bad about being a for-profit open source company. Nor is there anything morally wrong with producing proprietary closed-source software, if that's what you'd like to do. But it doesn't make any sense for open source companies to subvert or refuse to cooperate with the rest of the open source world, either by not supporting the GPL or by any other means. This is a practical point that clearly makes business sense.
{{fancywarning|Это необратимый процесс, который уничтожит все разделы!  Вы предупреждены! Советуем сохранить критические данние перед этим.}}
+
 
+
<console>
+
# ##i##sgdisk --zap-all /dev/sda
+
 
+
Creating new GPT entries.
+
GPT data structures destroyed! You may now partition the disk using fdisk or
+
other utilities.
+
</console>
+
 
+
Не стоит беспокоится об этом сообщении, так как комманда успешно выполнена:
+
 
+
<console>
+
***************************************************************
+
Found invalid GPT and valid MBR; converting MBR to GPT format
+
in memory.
+
***************************************************************
+
</console>
+
 
+
===== Разбивка диска =====
+
 
+
Теперь мы используем <code>fdisk</code> для создания таблицы разделов MBR и самих разделов:
+
 
+
<console>
+
# ##i##fdisk /dev/sda
+
</console>
+
 
+
В консоли <code>fdisk</code>, следуйте следующим шагам:
+
 
+
'''Очистить таблицу разделов''':
+
 
+
<console>
+
Command (m for help): ##i##o ↵
+
</console>
+
 
+
'''Создать раздел 1''' (boot):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (1-4, default 1): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+128M ↵
+
</console>
+
 
+
'''Создать раздел 2''' (своп):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (2-4, default 2): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+2G ↵
+
Command (m for help): ##i##t ↵
+
Partition number (1,2, default 2): ##i## ↵
+
Hex code (type L to list all codes): ##i##82 ↵
+
</console>
+
 
+
'''Создать корневой раздел:'''
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (3,4, default 3): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
</console>
+
 
+
'''Проверить таблицу разделов:'''
+
 
+
<console>
+
Command (m for help): ##i##p
+
 
+
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
+
Units: sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disklabel type: dos
+
Disk identifier: 0x82abc9a6
+
 
+
Device    Boot    Start      End    Blocks  Id System
+
/dev/sda1          2048    264191    131072  83 Linux
+
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
+
/dev/sda3        4458496 625142447 310341976  83 Linux
+
</console>
+
 
+
'''Записать таблицу разделов на диск:'''
+
 
+
<console>
+
Command (m for help): ##i##w
+
</console>
+
 
+
Ваша новая таблица разделов будет записана на диск.
+
 
+
{{Note|Вы завершили создание разделов! Теперь, перейдите к  [[#Создание файловых систем|Создание файловых систем]].}}
+
 
+
==== Метод (UEFI/GPT) "Модерн" ====
+
 
+
{{Note|Используйте данный метод при загрузке с помощью UEFI,  и если System Rescue CD имеет начальное меню загрузки черно-белого цвета. Если оно было светло-голубого цвета, этот метод не будет работать.}}
+
 
+
Комманда <tt>gdisk</tt> используется для создания таблицы разделов GPT .  Измените размеры в соответсвии Вашим требованиям, хотя приведенные ниже размеры будут работать для большинства пользователей. Запустите <code>gdisk</code>:
+
 
+
<console>
+
# ##i##gdisk
+
</console>
+
 
+
В консоли <tt>gdisk</tt>,  следуйте следующим шагам:
+
 
+
'''Создайте новую пустую таблицу разделов''' (Это уничтожит данные при сохранении на диск):
+
 
+
<console>
+
Command: ##i##o ↵
+
This option deletes all partitions and creates a new protective MBR.
+
Proceed? (Y/N): ##i##y ↵
+
</console>
+
 
+
'''Создайте раздел 1''' (загрузочный):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##1 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+500M ↵
+
Hex Code: ##i##↵
+
</console>
+
 
+
'''Создайте раздел 2''' (своп):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##2 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+4G ↵
+
Hex Code: ##i##8200 ↵
+
</console>
+
 
+
'''Создайте раздел 3''' (корневой):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##3 ↵
+
First sector: ##i##↵
+
Last sector: ##i##↵##!i## (for rest of disk)
+
Hex Code: ##i##↵
+
</console>
+
 
+
По пути Вы можете набрать "<tt>p</tt>" и нажать Enter для просмотра текущей таблицы разделов. Если Вы допустили ошибку,  наберите "<tt>d</tt>" для удаления созданного раздела. Если Вы удовлетворены Вашей схемой разделов, наберите "<tt>w</tt>" для записи таблицы на диск:
+
 
+
'''Записать таблицу разделов на диск''':
+
 
+
<console>
+
Command: ##i##w ↵
+
Do you want to proceed? (Y/N): ##i##Y ↵
+
</console>
+
 
+
Таблица разделов будет записана на диск и <tt>gdisk</tt> завершит работу.
+
 
+
Теперь  GPT/GUID разделы созданы, и будут показаны как ''блочные утройства'' в Linux:
+
 
+
* <tt>/dev/sda1</tt>, будет использоваться  для <tt>/boot</tt>, загрузочный раздел
+
* <tt>/dev/sda2</tt>, будет использоваться как своп , и
+
* <tt>/dev/sda3</tt>, корневой раздел.
+
 
+
==== Создание файловых систем ====
+
 
+
{{Note|Данная часть рассматривает как BIOS ''так и'' UEFI установки. Не пропускайте раздел!}}
+
 
+
Before your newly-created partitions can be used, the block devices need to be initialized with filesystem ''metadata''. This process is known as ''creating a filesystem'' on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.
+
 
+
Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:
+
 
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:
+
 
+
<console>
+
# ##i##mkfs.vfat -F 32 /dev/sda1
+
</console>
+
 
+
Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.
+
 
+
You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the <code>mkswap</code> command. Then we'll run the <code>swapon</code> command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:
+
 
+
<console>
+
# ##i##mkswap /dev/sda2
+
# ##i##swapon /dev/sda2
+
</console>
+
 
+
Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:
+
 
+
<console>
+
# ##i##mkfs.ext4 /dev/sda3
+
</console>
+
 
+
...and here's how to create an XFS root filesystem, if you choose to use XFS:
+
 
+
<console>
+
# ##i##mkfs.xfs /dev/sda3
+
</console>
+
 
+
Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.
+
 
+
{{fancywarning|1=
+
When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of <code>openvz-rhel6-stable</code> are '''not''' compatible with XFS, and you may experience kernel bugs.
+
}}
+
  
==== Mounting filesystems ====
+
Open source companies should realize that the free exchange of ideas and code is what they profit from. By opposing things like the standard GPL practices, they undermine the environment they rely upon to prosper and grow. If open source is the soil from which your business has sprouted, it makes sense to keep the soil healthy.
  
Mount the newly-created filesystems as follows, creating <code>/mnt/funtoo</code> as the installation mount point:
+
I understand that there's a temptation to keep at least some information secret for short-term financial gain. Advanced code or special techniques provide a coveted competitive advantage, which could potentially result in increased sales and profit. But if the goal is to be the sole provider of a product, the product should be commercial rather than open source. Open source does not allow for exclusive access to the inner workings of anything. That's what it means.
  
<console>
+
=== Back to Enoch ===
# ##i##mkdir /mnt/funtoo
+
# ##i##mount /dev/sda3 /mnt/funtoo
+
# ##i##mkdir /mnt/funtoo/boot
+
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
</console>
+
  
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:
+
Now, I'll step down from my soapbox and continue my story.
  
<console>
+
As Enoch became more and more refined, we decided that a name change was in order, and "Gentoo Linux" was born. By this time we had released a couple of versions of Enoch (now Gentoo), and were racing to get to Gentoo Linux version 1.0. Around this time I also decided to upgrade my old Celeron 300 box (overclocked and rock-solid at 450Mhz) to a brand-new Abit BP6 (a dual Celeron board that had just hit the market). I sold my old box and put my dual Celeron 366 system together. After overclocking the processors to something on the order of 500Mhz, I was cruising. But I noticed that my new machine wasn't very stable.
# ##i##mkdir /mnt/funtoo/home
+
# ##i##mount /dev/sda4 /mnt/funtoo/home
+
</console>
+
  
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:
+
Obviously my first reaction was to go back down to 2x366Mhz. But now I experienced an even stranger problem. As long as my machine kept the CPUs chugging away, the machine didn't lock up. But if I left the machine idle overnight, there was a good probability that the system would lock up completely. Yes, an idle bug -- argh! After some research, I found several other Linux users with the same problem on this particular motherboard. A chip on the BP6 (was it the PCI controller?) seemed to be flaky or out of spec, which caused Linux to lock up at idle.
  
<console>
+
I was more than a wee bit upset, and because I couldn't afford to order more PC parts, Gentoo development effectively halted. I became more and more pessimistic about Linux and decided to switch over to FreeBSD. Yes, FreeBSD. And that's where I'll end this installment -- see you in Part 3. :)
# ##i##chmod 1777 /mnt/funtoo/tmp
+
{{ArticleFooter}}
</console>
+

Revision as of 15:43, January 9, 2015

In his previous article, Daniel Robbins told the story of how he became a Stampede Linux developer and why he eventually left Stampede to start the Enoch Linux distribution. In this go-round he lets you in on the strange events that happened after the Enoch development team discovered a little-known, blazingly fast compiler.

Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container.

From Enoch to Gentoo, via minor setbacks and corporate run-ins

First steps to Enoch

In my previous article, I gave you the low-down on my days with the Stampede development team and why I left (to get away from lower-level politically-minded, project-controlling "freaks"). Because of the interference from these meddlesome by-standers, I figured it would be easier to put together my own Linux distribution than to continue improving Stampede under such dirty conditions! Fortunately I took with me a considerable amount of experience based on my (may I say substantial?) work for Stampede, including maintaining several of their packages, designing the initialization scripts, and leading the slpv6 (next-generation package management project).

The distribution I began working on, code-named Enoch, was going to be blazingly fast because it would completely automate the package creation and upgrading process. I have to admit that this was in large part because I was a one-member team and couldn't afford to spend my time on repetitive work that my development box could be automated to do for me. And since I was designing a complete distribution from scratch (rather than "spinning off" from someone like RedHat), I had my work cut out for me and needed all the free time I could scrounge up.

After getting my basic Enoch system up and running, I headed back to irc.openprojects.net and started my own channel called #enoch. From there I gradually assembled a team of about ten developers. In those early days we all hung out on IRC and worked on the distribution in our spare time. As we communally and cooperatively hacked away at it, finding and fixing new bugs, Enoch became more functional and professional every day.

The first roadblock

One inevitable day, Enoch hit its first roadblock. After adding Xfree86, glib, and gtk+, I decided to get xmms (an X11/gtk+-based MP3/CD player app) working. I figured it was time to celebrate with some music! But after installing xmms, I tried to start it... and X locked up! At first I thought xmms locked up because I used insane compiler optimizations ("-O6 -mpentiumpro", in case you were wondering). My first thought, to compile xmms with standard optimizations, didn't solve the problem. So I started looking elsewhere. After spending a full week of development time trying to track down the problem, I got an e-mail from an Enoch user, Omegadan, who was also experiencing xmms lockups.

We corresponded for a while, and after many hours of testing we determined that the problem was a POSIX threads-related issue. For some reason, a pthread_mutex_trylock() call did not return the way it should. As the creator of a distribution, these were the types of bugs I really didn't want to encounter. I counted on the developers to release perfect sources so I could focus on enhancing the Linux experience rather than getting buggy sources to work. Of course I soon learned that this was an unrealistic expectation, and that problems like this will always pop up from time to time.

As it turned out, the problem wasn't with xmms, gtk+, or glib. And it wasn't an issue with Xfree86 3.3.5 not being thread-safe and locking up. Surprisingly, we found the bug in the Linux POSIX threads implementation itself, part of the GNU C library (glibc) version 2.1.2. I was shocked at the time to find that such a critical part of Linux had such a major bug. (And we used a release version of glibc in Enoch, not a prerelease or CVS version!).

So how did we track down the problem? Actually, we never were able to come up with a bug fix, but at one point I stumbled across a couple of e-mails on the glibc developer mailing list from another person who had the same problem. The glibc developer who replied posted a patch that solved the thread problem for us. But I was curious why RedHat 6 (which also used glibc 2.1.2) didn't suffer from this problem since the patch was just posted and RedHat 6 had been available for some time. To find out, I downloaded RedHat's glibc SRPM (source RPM) and took a look at their patches.

RedHat had their own homegrown glibc patch that solved the pthread_mutex_trylock() issue. Apparently they experienced the same problem and created their own custom fix. Too bad they didn't send this patch "upstream" to the glibc developers so it could be shared with the rest of the world. But who knows, maybe RedHat sent the patch upstream and for some reason the glibc developers didn't accept it. Or maybe the thread bug was triggered by a specific combination of compiler and binutils versions, and RedHat never ran into it (although they did have a thread patch in their SRPM). I suppose we'll never know exactly what happened. But I did learn that RedHat SRPMs contain a lot of private bug fixes and tweaks that never seem to make it upstream to the original developers. I'm going to rant about this for a little while.

Rant

When you put together a Linux distribution it's really important that any bug fixes you create are sent upstream to the original developers. As I see it, this is one of the many ways that distribution creators contribute to Linux. We're the guys who actually get all these different programs working as a unified whole. We should send our fixes upstream as we unify so that other users and distributions can benefit from our discoveries. If you decide to keep bug fixes to yourself, you're not helping anyone; you're just ensuring that a lot of people will waste time fixing the same problem over and over again. This kind of policy goes against the whole open source ethic and stunts the growth of Linux development. Maybe I should say that it "bugs" us all.

It's unfortunate that some distributions (ahem) aren't as good (RedHat) as others (Debian) about sharing their work with the community.

Compiler drama

During the time we were trying to fix the glibc threads problem, I e-mailed Ulrich Drepper (one of the guys at Cygnus who is heavily involved with glibc development). I mentioned the POSIX thread problem we were having, and that Enoch was using pgcc for optimum performance. And he responded with something like this (I'm paraphrasing here): "Our own compiler included with the CodeFusion product has an excellent x86 backend that produces executables far faster than those generated with pgcc." Obviously, I was very interested in testing out this mystery "turbo" compiler the Cygnus guys had created.

I thereupon requested a demo copy of Cygnus Codefusion 1.0 so that I could test it out, and Omegadan and I were amazed to find that this compiler was everything that Ulrich claimed and then some. The x86 backend increased the performance of some of the CPU-intensive executables (like bzip2) by close to 90%! All applications seemed to benefit from at least a 10% real-world performance increase, and all we did was swap out compilers. Enoch even booted 30 - 40% faster. The performance gains were far, far greater than what we gained by switching from gcc to pgcc. Obviously, after experiencing it for ourselves, we wanted to use this compiler for Enoch. Fortunately, the sources were included on the CodeFusion CD and were released under the GPL, so we were fully permitted to use this compiler... or so we thought.

Let the freakiness begin

I sent an e-mail to the marketing manager at Cygnus to let them know our intentions, expecting a "yeah, go for it, thanks for using our compiler" response. Instead the reply was that although we were (technically) allowed to use the Cygnus compiler, we were strongly urged not to use or include the compiler sources with Enoch. I responded by asking why they had released the source under the GPL, if that was the case. It's my guess that if they had a choice, they wouldn't have used the GPL, but because they derived their compiler from egcs (released under the GPL), they had no choice.

This is a good example of a situation where the GPL prevented a company from creating a proprietary product based on open sources. My educated guess is that Cygnus was afraid that if we used their compiler we would undermine their boxed product sales, which would be especially strange because none of their marketing materials (nor the InfoWorld review) mentioned the new compiler included with CodeFusion. CodeFusion was marketed solely as a "development IDE" product, not as a compiler.

In an attempt to put some of their paranoia to rest, I offered to endorse CodeFusion and place the endorsement on our Web site with a link to help spur CodeFusion sales. Personally I didn't think that a "turbo" Enoch would negatively affect their sales, since CodeFusion was marketed as an IDE. But I tried nevertheless to make them happy. The IDE component of CodeFusion was a commercial product, and we had no desire or intention (or right) to distribute it with Enoch.

I e-mailed my (generous?) offer to Cygnus and received another strange response. They wanted authority over all of our "marketing materials" (apparently, this also included the content of our Web site!) Another shocker. The Cygnus marketing team seemed to have no grasp of how the Linux community or the GPL worked, so I decided to cut off communication with Cygnus for the indefinite future. In the mean time, we created a private "turbo" and public "non-turbo" version of Enoch, leaving the final decision for later.

But after several months they integrated the CodeFusion x86 backend into gcc 2.95.2. Now everyone could benefit from the nice new backend, not just the people who knew about the "secret GPL compiler" included on the CodeFusion CD. But we decided to go ahead and use gcc rather than the CodeFusion compiler. In addition to being more stable, gcc 2.95.2 also allowed us avoid Cygnus, which by this time had been purchased by RedHat for a ridiculous sum of money. (Note: the new x86 backend in gcc 2.95.2 is what gave newer Linux distributions the significant speed boost that we all got to experience. It also gave FreeBSD 4.0 a nice speed boost over 3.3.6. Notice the difference?)

On the soapbox

Thanks to this and other experiences, I've learned a lot about for-profit open source companies. There's absolutely nothing bad about being a for-profit open source company. Nor is there anything morally wrong with producing proprietary closed-source software, if that's what you'd like to do. But it doesn't make any sense for open source companies to subvert or refuse to cooperate with the rest of the open source world, either by not supporting the GPL or by any other means. This is a practical point that clearly makes business sense.

Open source companies should realize that the free exchange of ideas and code is what they profit from. By opposing things like the standard GPL practices, they undermine the environment they rely upon to prosper and grow. If open source is the soil from which your business has sprouted, it makes sense to keep the soil healthy.

I understand that there's a temptation to keep at least some information secret for short-term financial gain. Advanced code or special techniques provide a coveted competitive advantage, which could potentially result in increased sales and profit. But if the goal is to be the sole provider of a product, the product should be commercial rather than open source. Open source does not allow for exclusive access to the inner workings of anything. That's what it means.

Back to Enoch

Now, I'll step down from my soapbox and continue my story.

As Enoch became more and more refined, we decided that a name change was in order, and "Gentoo Linux" was born. By this time we had released a couple of versions of Enoch (now Gentoo), and were racing to get to Gentoo Linux version 1.0. Around this time I also decided to upgrade my old Celeron 300 box (overclocked and rock-solid at 450Mhz) to a brand-new Abit BP6 (a dual Celeron board that had just hit the market). I sold my old box and put my dual Celeron 366 system together. After overclocking the processors to something on the order of 500Mhz, I was cruising. But I noticed that my new machine wasn't very stable.

Obviously my first reaction was to go back down to 2x366Mhz. But now I experienced an even stranger problem. As long as my machine kept the CPUs chugging away, the machine didn't lock up. But if I left the machine idle overnight, there was a good probability that the system would lock up completely. Yes, an idle bug -- argh! After some research, I found several other Linux users with the same problem on this particular motherboard. A chip on the BP6 (was it the PCI controller?) seemed to be flaky or out of spec, which caused Linux to lock up at idle.

I was more than a wee bit upset, and because I couldn't afford to order more PC parts, Gentoo development effectively halted. I became more and more pessimistic about Linux and decided to switch over to FreeBSD. Yes, FreeBSD. And that's where I'll end this installment -- see you in Part 3. :)

Next >>>

Read the next article in this series: Making the Distribution, Part 3

Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container.

In his previous article, Daniel Robbins told the story of how he became a Stampede Linux developer and why he eventually left Stampede to start the Enoch Linux distribution. In this go-round he lets you in on the strange events that happened after the Enoch development team discovered a little-known, blazingly fast compiler.
About the Author

Daniel Robbins is best known as the creator of Gentoo Linux and author of many IBM developerWorks articles about Linux. Daniel currently serves as Benevolent Dictator for Life (BDFL) of Funtoo Linux. Funtoo Linux is a Gentoo-based distribution and continuation of Daniel's original Gentoo vision.

Got Funtoo?

Have you installed Funtoo Linux yet? Discover the power of a from-source meta-distribution optimized for your hardware! See our installation instructions and browse our CPU-optimized builds.

Funtoo News

Drobbins

ARM Rebuild

ARM systems will use new stage3's that are not compatible with earlier versions.
2015-06-27 by Drobbins
Drobbins

ABI X86 64 and 32

Funtoo Linux has new 32-bit compatibility libraries inherited from Gentoo. Learn about them here.
2015-06-18 by Drobbins
Drobbins

Pre-built kernels!

Funtoo stage3's are now starting to offer pre-built kernels for ease of install. read more....
2015-05-12 by Drobbins
More...

More Articles

Browse all our Linux-related articles, below:

A

B

F

G

K

L

M

O

P

S

T

W

X