[opensuse] Why is initrd needed...
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 A "toy /usr/ that is not the full /usr partition lives on your ram disk in less than 20MB, I can throw away that much space in a 'dummy /usr' that the real /usr mounts over. It would be preferable to having to read all of it from disk and duplicating it 12 times for the 12 kernels I had in lilo when I last cleaned it out of initrd's that don't get used. Not only are you duplicating the space of all the utils in /usr that you need to put (ONLY because you moved them from /bin.. which if you hadn't done you wouldn't need to to copy them all to /usr). I read the /usrmerge crap... They miss a major point. If they want to merge /usr/bin with /bin, why not get rid of /usr/bin? Why not copy all of /usr/bin into /bin? But to boot do you really need 15G of /usr/share? Is /usr/games really required for boot? Do you need the complete linux source to boot in /usr/src? All of these irrelevant directories live in /usr The total of my /usr/bin, lib and lib64 (1.4G, 1.3G 3.2G) can easily live in the 9.7G free of my root. It's the rest of /usr that you are pulling along. If you want /usr/bin/lib/lib64 on root... why not just move them there? I split /usr and root because I don't need 20G of docs or fonts or source on my boot disk. Why would you claim that's the only viable answer you could come up with? Moreover, what is there on initrd that you can't put in root? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On Thu, Nov 15, 2012 at 09:42:40AM +0100, 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
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. With modern journaling file systems this is required and not using an initrd would increase the risk of loosing data. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- 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
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. On the other hand it did away with the mess of umpteen different kernels (one kernel for every kind of hard disk controller). Philipp -- 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
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. -- Per Jessen, Zürich (6.9°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
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
On Mon, 19 Nov 2012 15:02:02 -0800, Linda Walsh <suse@tlinx.org> 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. Philipp -- 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 <suse@tlinx.org> 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
On Wed, 21 Nov 2012 15:47:35 -0500, Dirk Gently <dirk.gently00@gmail.com> wrote:
If this sort of thing were done on a military system, a court-martial would EASILY result in a conviction for treason.
That's why something like factory would never even come near a military system ;-) But yes, this move from /bin to /usr/bin could have been done in a test repo but then very few people had installed it thus lowering the chance to find the bugs. I still think that those that live on the bleeding edge aka factory (which includes me) must risk to bleed a bit now and then. Philipp -- 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
On 11/20/2012 1:54 AM, Per Jessen wrote:
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.
I have an old server I just spent half a day fighting with that for some reason can boot from usb, but yet the bootloader can not then load further files. initrd doesn't work there. Actually, it can load files apparently because I can navigate around a set of syslinux menus, so there must be some memory addressing problem where the initrd gets loaded somewhere that the kernel then can't find or the bios screws it up or ??? who knows, but initrd doesn't work at least not from usb. And the cd drive has filled up with dust and died or just doesn't like any of the blank cd's I happen to have (it successfully booted a sco open server 5.0.7 install cd which I needed to use just to do a temp install to read off one HTFS filesystem before installing linux), and the floppy drive is way too small for current kernels, and it's a customer's site with no pxe server, although I suppose I could run a pxe server from my laptop, or get them a new cd drive... Today they still don't have a running server because I couldn't get any kind of installer to work, because I too usually have no problem with initrd. It always worked before. So I didn't have a new cd drive in my pocket. Point is, initrd is nice, and most of the time it can be loaded by the booting mechanism and most of the time there is plenty of ram to waste on it. But not always. -- bkw -- 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
On Mon, 19 Nov 2012 15:07:04 -0800, Linda Walsh <suse@tlinx.org> wrote:
And how often do you you switch disk controllers on your end user system?
That's not the question. 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?
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.
As I said, implement something like that or try to find equal minded folks to implement it and *then* come back and try to convince the rest. Philipp -- 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 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? And have a look into run_all.sh. Have a nice day, Berny -- 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
Bernhard Voelker wrote:
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?
And here is the problem. Only if you use a file system that Needs fsck is this important. Look at fsck.xfs. It's a shell script that determines whether or not the file system is mounted. If you want a reliable system, you use xfs. If your rootfs has mounted, you've already passed fsck. It's all about reliability and being sure your system boots... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Anders Johansson -
Anton Aylward -
Bernhard Voelker -
Brian K. White -
Dirk Gently -
Dr. Werner Fink -
Linda Walsh -
Per Jessen -
Philipp Thomas -
Roger Oberholtzer