Andrey Borzenkov wrote:
On Thu, Nov 15, 2012 at 12:17 PM, Linda Walsh <suse@tlinx.org> wrote:
Give me ANY reason. Personal experience.
- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.
If you want reliability, you mount root by dev -- that's another reason to make it small.
- support for root on layered storage. Yes, it probably can be done without initrd, but even Solaris moved to initrd at the end after all those years.
Layered? Like RAID? My root runs on RAID5 -- works great. If you have a HW raid card that's handled outside the OS. Again -- reliability is the key.
- minimal debugging environment in which I am able to poke around when root is not found instead of just cursing blindly
I have that as well. Not much you CAN'T put on a 14G root. That's larger than the distro's DVD.
claims to need 400GB in root?! Talk about a broken model to be following! You still need 400GB be it on two partitions or on one partition. Why exactly one is more broken than two?
We are talking about what is necessary to boot, all the apps you want to run. At one point openSuse went with XFS as the default file system (1 release I think). It moved away from that when it wanted to use the, then broken grub manager -- which was known to be unreliable at that time. Many of the decisions above come a lack of need for reliability. My machine boots in another room -- and doesn't run a graphical console on boot. Suse is promoting the idea of virtual machines usable as appliances -- many of those don't need a "Desktop". If you want reliable, this entire push for a unified Usrbin/lib is a negative for reliability. MANY legacy scripts with fixed values for the distro's basic utils are failing in 12.2. This will be a corporate nightmare as those fail. I've seen 10 year old scripts fail in 12.2 as well as many rpms. Shells have always lived in /bash, along with many other basic functions. You are voiding compatibility with 40 years of unix scripting -- stuff that will no longer work without being modified for OSuSE. If you want reliability, Make your basic utils *statically* linked, and then load dynamically linked versions in /usr/bin, and put /usr/bin first in the path. Again -- all about reliability. How many times have we seen on this list about the current release being non-bootable? This would almost never happen if the root was static and small -- it makes testing easy. You wouldn't have users posting how to fix their systems if they could get to an operational shell prompt with basic utils. As it is now -- I see many messages of them posting where they are screwed -- The current system is incredibly *fragile*. Please note -- there has been no reason given for the need for an initrd -- EVEN differing HW is easily solvable. If they user *wants* direct boot, you compile a kernel with the modules their machine needs to boot *once*. Then you have 2 choices. You stick with rebuilding the kernel on kernel updates, OR, you load an updated kernel from a mounted partition and pivot to the new kernel. If you want the optimization step, you can run it AFTER boot, in background and update the root-kernel -- so it doesn't slow down boot. Not only is it more reliable -- it streamlines the boot process. As the boot process is now, many users boot twice -- first off the ram disk to load support for disk "labels", and *then* they can boot from a labeled root unless you already have a running OS to find the label with 'udev' -- UNLESS, you use 'lilo'. Again.. we are talking reliability over features. I boot from a labeled root -- but the root is labeled when I install the kernel to boot from. I get booting from a labeled root, off of RAID5, with a kernel tailored for my HW...that takes 20% the space of the current solution w/an initrd. Guess which loads ALOT faster when being loaded by the block-loader of the BIOS... Points in my processes favor: reliability, speed, easy to get to a working single user to fix problems should they arise. Even easy to get to login from a remote shell when there are problems if you disable "unreliability features" that have been added to prevent boot if any 'T' is not crossed, or 'i' is not dotted. If you want reliability, and speed, the choice is clear. What are the supposed benefits of an initrd again? So far, I see only reasons given due to use of other unreliable pieces of software. If reliability was a priority -- if speed of boot was a priority, these issues would never have come up. But choices have been made to provide things that can be added *after* boot. But so far, EVERYTHING, that has been given can be done without initrd -- both FASTER and with vastly improved reliability. So what is so important that you would sacrifice a high level of reliability and a large speed boost to provide the indirect step of using an initrd? Note -- for working on a root partition -- which was rare, when memory was tight, a 'miniroot' (a rescue type system) was copied into SWAP, and run from there. -- then root could be moved/resized, or whatever. Now days, equivalent functionality can be done from a RAM disk most often. There is no need for initrd, and getting rid of it in the default case would improve reliability, performance and speed of boot. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org