Anders Johansson wrote:

On 11/15/2012 09:17 AM, Linda Walsh wrote:

...

So far no one is able to explain why it is needed other than It's a fad or it's cool..

You have a 20MB RAM disc that you think you have to load and do secret things before you start my OS.

I have a 12GB root disk (and RH/Fedora on their "Excuses for UsrMerge page, claims to need 400GB in root?! Talk about a broken model to be following!)

Never the less, a 14 GB root with over 50% free.. and What, can't I put on my root hard disk that you have to have initrd?

The drivers on my kernel are built-in. You are deliberately making people use a ram disk for no reason.

Give me ANY reason. and don't say it's to mount /usr

It is to mount /

The alternative would be to have one kernel for every driver that could possibly be needed - this is the way it used to be, and it was ugly

That's for the installation - once a system is running, one is free to build a kernel with the needed modules and skip the initrd. -- Per Jessen, Zürich (6.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dr. Werner Fink wrote:

It is more than only mounting / ...

First of all it is that the file system of / should not be accessed before the system time of the kernel is in UTC, then the file system check should be done without accessing the file system, and last but not least it should be mounted with correct time stamps.

As has already been pointed out, there is no file system check if one uses XFS. Not only is one not done, but it one was needed -- booting from initrd wouldn't help, since the file system repair utils for XFS have never been included on 'initrd'.

With modern journaling file systems this is required and not using an initrd would increase the risk of loosing data.

---- With *advanced*, (vs. modern), this isn't an issue. Only fragile, modern file systems have these problems. That opensuse inflicts this type of risky behavior on users/clients, throws any arguments about doing this for 'safety' out the window -- as using a file system that needs to be checked before it is mounted, vs. using a file system that has no such need, shows, a willingness to expose the user to a file system that can so easily develop problems, that it needs to be checked, at least, with every boot. If safety was really a concern, then suse would be using an advanced file system rather than a 'modern' one. Trendy is often, _not_, technically better. Another example, no more than a few releases back, it was suggested to use an ext2 file system for your boot partition because the new, trendy 'grub' had unreliable behavior with journaling file systems. Rather than waiting until grub was fixed and staying with a proven performer like 'lilo', decision makers at OSus, threw caution to the winds and went with shiny. Even last week, initrd was so broken people couldn't boot their systems without a rescue disk... It is guaranteed -- ever since 10.2, I've not been able to upgrade to the released system using an initrd without resulting in a non-bootable system that I had to repair from a rescue disk. You can't use safety as a reason for initrd -- it's has a proven track record of having problems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philipp Thomas said the following on 11/17/2012 09:25 AM:

I've been using initrd since SUSE started using it and never had a problem with it. On the other hand it did away with the mess of umpteen different kernels (one kernel for every kind of hard disk controller).

+1 Makes sense to me :-) -- "Most victories came from instantly exploiting your enemy's stupid mistakes, and not from any particular brilliance in your own plan." -- Orson Scott Card, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Philipp Thomas wrote:

...

...

You can't use safety as a reason for initrd -- it's has a proven track record of having problems. What do you call a proven track record? And don't vaguely point to mailing lists but name them.

I've been using initrd since SUSE started using it and never had a problem with it.

Ditto.

And how many times have you downloaded and rebuilt your kernel? Or how many times have you loaded rpms from factor in the past month? Look at the opensuse-factory list -- they had to use rescue disks for a week, week before last, because it was broken. If you do anything in the boot or kernel area, it makes things incredibly complicated. When was the last time you needed to do an xfs_check on a disk that didn't come up? initrd will fail because it won't mount -- but will need a rescue disk to run xfs's file system checker. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philipp Thomas wrote:

On Mon, 19 Nov 2012 15:02:02 -0800, Linda Walsh wrote:

...

And how many times have you downloaded and rebuilt your kernel?

That's a special case because the vast majority won't do that. But I did do that in the past. Nothing to it besides calling mkinitrd to rebuild the initrd after having compiled the kernel. Never had a problem with that.

...

Or how many times have you loaded rpms from factor in the past month?

Factory is just that. It's the developement version of what will become the next release and as such will be broken now and then. People who can't live with that should use the released version.

Yes, but even factory shouldn't be breaking egregiously due to a , brittle, problem-magnifying and poorly-thought out act of moving critical executables from /bin to /usr/bin. If this sort of thing were done on a military system, a court-martial would EASILY result in a conviction for treason. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

Per Jessen wrote:

...

Philipp Thomas wrote:

...

...

You can't use safety as a reason for initrd -- it's has a proven track record of having problems. What do you call a proven track record? And don't vaguely point to mailing lists but name them.

I've been using initrd since SUSE started using it and never had a problem with it.

Ditto.

---

And how many times have you downloaded and rebuilt your kernel? Or how many times have you loaded rpms from factor in the past month? Look at the opensuse-factory list -- they had to use rescue disks for a week, week before last, because it was broken.

Yeah I saw that - I don't think that is indicative of the generate state of using an initrd.

If you do anything in the boot or kernel area, it makes things incredibly complicated. When was the last time you needed to do an xfs_check on a disk that didn't come up? initrd will fail because it won't mount -- but will need a rescue disk to run xfs's file system checker.

I don't use xfs, but I regularly fiddle with booting with root on NFS or over iSCSI. I feel quite comfortable with working with the initrd. -- Per Jessen, Zürich (3.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philipp Thomas wrote:

On the other hand it did away with the mess of umpteen different kernels (one kernel for every kind of hard disk controller).

And how often do you you switch disk controllers on your end user system? You are describing HW test environment, which will need features offered by initrd, or a very large kernel. However, most users don't change controllers daily -- maybe every few years. For those, you *offer* them the option to rebuild the kernel with their needed-boot modules and install that to disk to enable direct boot. Just as DKMS builds and configures kernel modules, unique to a user's system, so it has and could again be done for a kernel. The option to generate kernel with static modules for your boot HW, isn't a new idea... many unix vendors 15-20 years ago offered it as an optional optimization. Yet this generation seems to have forgotten about that option. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philipp Thomas wrote:

The question is, how do I support a maximum of different devices *without* requiring the user to compile his own kernel.

...

For those, you *offer* them the option to rebuild the kernel with their needed-boot modules and install that to disk to enable direct boot.

The is free software, so why don't you implement something like that and then offer it to those that do want it?

It would have been trivial if the boot system hadn't been modified to be difficult to maintain, unfriendly, error-prone, boot-resistant, fault-intolerant -- the move to systemd with the now claimed false requirement of moving all to /usr/bin, has made things incredibly unstable and unusable for a development platform without severe repair work. If I were to work from 11.4, I could have it as a replacement for 12.3 timeframe for the stuff in there now, but trying systemd, has caused numerous hangs and having to bring it up by hand -- boot 'S' run bootscripts by hand, then run rcdir by hand. initscripts timed out -- and the system came up -- it was resilient. systemd, 1 thing hangs and the system has you locked out and you can't fix it without rebooting to single user -- if that works. I haven't been able to keep track of all the ways systemd is failing when it tries to come up -- and don't ask me to report bugs, as 1) there are too many and I wouldn't know where to start, and 2) no one is willing to fix the underlying problems, but continue to go down hill -- the move /usr isn't necessary, you said it yourself, but it is continue and causing more damage as it moves forward. I couldn't understand why boot processes no longer worked -- "boot.local" was reserved for calling site-local boot needed processes after boot and before single-user. It is no longer called, but worse, trying to add it, I am told: #chkconfig boot.local on insserv: Note: sysvinit service boot.local is shadowed by systemd local.service, Forwarding request to '/bin/systemctl --root / enable local.service'. Operation failed: No such file or directory insserv: Forward service request to systemctl returned error status : 256 insserv: script name boot.local is not valid, skipped! ==== Great -- boot.local isn't valid? Yet it is the same header and format as the rest. It loaded modules and set the font/tty cuz it doesn't get set right by systemd when one does a warm reboot. Now it doesnt' get called at all, and the drivers not loading caused systemd to hang and the sytem not to come up... wonderful! and this is in SuSE 12.1?? I deliberately enabled the break key in 'boot'.... - so if the system hung during boot, I could press break and interrupt boot and fix it. now.. it's locked out. This is Suse inovation??? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 2012-11-15 at 10:26 +0100, Bernhard Voelker wrote:

On 11/15/2012 09:17 AM, Linda Walsh wrote:

...

Moreover, what is there on initrd that you can't put in root?

Find out yourself:

$ mkdir /tmp/initrd $ cd /tmp/initrd $ gzip -dc - < /boot/initrd | cpio -i $ find . -ls [...]

It's a question of timing, e.g. how do you want to do an fsck of the root file system when you have it already mounted?

One could have the initrd components in a separate partition, which would contain the only copy of these, so that whatever the current kernel has is available at boot. This disadvantage of that is (1) it takes a partition (one per kernel) (2) you then have to deal with the size of that partition should more space be needed. The initrd puts that info in a file so that (1) there can easily be many of them and (2) the space required is easier to manage. Also, I use KIWI to make diskless openSUSE images that are mounted over the network via PXE. If the initrd was a partition, this would surely be much more complicated. Getting the image via tftp (which is how it is gotten) is 'simple'. Otherwise the loader would need to have, say AoE (ATA over Ethernet) at this early stage. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org