On Mon, May 4, 2020 at 7:17 AM Takashi Iwai <tiwai@suse.de> wrote:

On Mon, 04 May 2020 12:37:01 +0200, Daniel Molkentin wrote:

...

Hi,

In an effort to get the naming right. I would like to propose renaming the /boot/initrd-$(uname -r) images to /boot/initramfs-$(uname -r).img.

Rationale: We are not using initrd's (that is: actual block devices) for a long time now. Instead, an initramfs is a cpio archive that gets deflated to a tmpfs. And, this would allow me to drop some more of our vendor patches off dracut.

I am currently collecting affected packages. So far I found:

- aaa_base (refresh_initrd script)

- YaST

- grub

- kdump

- perl-Bootloader

Anything I am missing?

The kernel-default and co who own those initrd files.

And that'll be tricky -- if we rename it, which file name to be packaged would depend on dracut package, but dracut isn't included in the build requirement for the kernel binary package. So we can't know whether dracut prefers initramfs or initrd at the package build time.

Just make the kernel Conflict with dracut package version prior to the change, and that should be enough. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mai 04 2020, Takashi Iwai wrote:

Will dracut detect whether it already uses initrd and keep using initrd instead of initramfs? Otherwise it won't work because we keep multi-version kernels and the old kernel package will insist initrd instead of initramfs while only the new kernel will use initramfs.

And what about the users of Kernel:{stable,HEAD} on old distributions? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, May 4, 2020 at 8:25 AM Takashi Iwai <tiwai@suse.de> wrote:

On Mon, 04 May 2020 14:05:20 +0200, Andreas Schwab wrote:

...

On Mai 04 2020, Takashi Iwai wrote:

...

Will dracut detect whether it already uses initrd and keep using initrd instead of initramfs? Otherwise it won't work because we keep multi-version kernels and the old kernel package will insist initrd instead of initramfs while only the new kernel will use initramfs.

And what about the users of Kernel:{stable,HEAD} on old distributions?

Right, that's even a bigger problem.

But nobody explicitly *supports* those users. We don't test or validate against Kernel:* projects. If we add that to this, we'll be paralyzed. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, May 4, 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote:

On Mon, 04 May 2020 14:27:24 +0200, Neal Gompa wrote:

...

But nobody explicitly *supports* those users. We don't test or validate against Kernel:* projects. If we add that to this, we'll be paralyzed.

Well, quite a lot of users have been using Kernel:stable kernel on Leap systems over many years. I have no statistics but I know it from a pile of bug reports. That is, although Kernel:stable on Leap is not tested systematically, practically it's been working, and any regression is notified by the *real* user.

So yes, we are paralyzed in that sense, and we must keep it working on both TW and Leap as much as possible. Breaking such a thing just for some random consistency purpose doesn't sound like a valid excuse...

And then we wonder why nobody is willing to contribute to packages with dozen of patches kept for seemingly no reason but to keep everything compatible with SLE10. This is even more problematic with the kernel since we cannot have version-specific packaging, because Kernel projects build only for Factory/standard. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2020-05-04 at 15:10 +0200, Olaf Hering wrote:

Am Mon, 04 May 2020 15:01:13 +0200 schrieb Stasiek Michalski <hellcp@opensuse.org>:

...

compatible with SLE10.

You entirely miss the point: We make SUSE. We do not recompile The Internet.

Well, at least some of us do...

And I think that is his point - some of us make SUSE, but ALL of us make openSUSE, and the requirements of the openSUSE community on occation trump the requirements of SUSE. Hence the different names, governance, build systems, and all the other stuff we do differently from each other ;) -- Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On 2020-05-08 08:21, Olaf Hering wrote:

Am Mon, 04 May 2020 17:35:36 +0200 schrieb Richard Brown <rbrown@suse.de>:

...

And I think that is his point - some of us make SUSE, but ALL of us make openSUSE, and the requirements of the openSUSE community on occation trump the requirements of SUSE.

You missed the point as well. It is about consistency in the base system. Questioning "compatibility with SLE10" when exactly this makes a good system is just wrong.

It is probably nice to replace the desktop background every quarter. For everything else the guys have to be grounded first before making decisions that potentially break consistency across versions.

thank you Olaf to point that out. You are 100% right. Accordingly Richard is 100% wrong with his never ending repeating that openSUSE dictates what SUSE does. This is so much destructive. The only right way is that openSUSE and SUSE collaborate. I am not a native English speaker so my word "collaborate" might not be the one with the exact right meaning of things like "work together", "cooperate", and "collaborate" but I found https://seapointcenter.com/cooperation-teamwork-and-collaboration/ Because of what is explained there I think "collaborate" is the best word for what I mean. Of course I don't mean that openSUSE and SUSE are enemies where "collaborate" is also used. But perhaps the enemies context makes it even more clear that "collaborate" is the right word because even if openSUSE and SUSE were enemies they would have to work together, think together, valuing each other’s perspective and contributions, in order for creative solutions and innovation to emerge. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 08, 2020 at 10:15:10AM +0200, Richard Brown wrote:

But how do you rationalise your perspective above that alternate views should be respected, at the same time that both you and Olaf are dismissing the view that change is not a bad thing?

Change - as an abstract term - is not good or bad per se. Each change brings some benefit (or at least it should, to be seriously considered) and usually also has some negative side effects. Whether you say "Each change is good because change is progress, progress is good, mkay..." or "Each change is bad, I want everything to stay as it was.", it's equally wrong. Instead, each change should be considered for its positive and negative effects and weighted carefully if the benefits are worth the trouble (or harm). In this particular case, the benefit is making the file names more formally corect and the cost is actual harm for real people and their systems. Of course, you are well known for your disregard of people using packages or repositories not belonging to the distribution and for discouraging such practice. But your view is far from universal and breaking such systems is a problem which outweights the benefit of formal file name corectness by far. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 08, 2020 at 10:48:59AM +0200, Richard Brown wrote:

On Fri, 2020-05-08 at 10:40 +0200, Michal Kubecek wrote:

...

On Fri, May 08, 2020 at 10:15:10AM +0200, Richard Brown wrote:

...

But how do you rationalise your perspective above that alternate views should be respected, at the same time that both you and Olaf are dismissing the view that change is not a bad thing?

Change - as an abstract term - is not good or bad per se. Each change brings some benefit (or at least it should, to be seriously considered) and usually also has some negative side effects. Whether you say "Each change is good because change is progress, progress is good, mkay..." or "Each change is bad, I want everything to stay as it was.", it's equally wrong. Instead, each change should be considered for its positive and negative effects and weighted carefully if the benefits are worth the trouble (or harm).

I agree....

...

In this particular case, the benefit is making the file names more formally corect and the cost is actual harm for real people and their systems. Of course, you are well known for your disregard of people using packages or repositories not belonging to the distribution and for discouraging such practice. But your view is far from universal and breaking such systems is a problem which outweights the benefit of formal file name corectness by far.

....and then you go and discredit yourself with ad hominems..

If you look at this thread with a little less emotion and a lot more professionalism I expect you will see that Daniel is not driving this forward without sincerely trying to find ways of mitigating impacts to peoples systems, and my contribution to the discussion was to try and remind everyone that just because a solution works fine for the specific dataset that is [SUSE], the superset that is [SUSE + openSUSE] can have differing requirements and they should be considered rather than dismissed out of hand for the sake of things that are relevant only to [SUSE] (eg. SLE 10 compatability)

Now with those personal attacks out of the way, is anyone in this thread willing to actually do something to help Daniel achieve his goal of shaving the yak, or would you prefer to continue throwing mud?

...and yet it's you who feels offended by a "personal attack". Unfortunately I can't say I'm really surprised. For the record, this "personal attack" was a simple observation of views you yourself presented in completely unambiguous way many times before and explanation why I understand that you don't consider the fallout as severe as others (like me) do. But if you prefer to feel offended and call this observation "throwing mud", it's your choice. I'm still waiting for an example of a real, palpable benefit of this "shaving the yak", benefit that would at least remotely justify the fallout that was already presented. And that is, from my point of view, the basic problem: my position is that before we start asking how to do it, we should always ask "why" and, consequently, wheter we want to. So far, I can't say I'm convinced. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 04 May 2020 13:25:04 +0200 Takashi Iwai <tiwai@suse.de> wrote:

On Mon, 04 May 2020 13:18:02 +0200, Neal Gompa wrote:

...

On Mon, May 4, 2020 at 7:17 AM Takashi Iwai <tiwai@suse.de> wrote:

...

On Mon, 04 May 2020 12:37:01 +0200, Daniel Molkentin wrote:

...

Hi,

In an effort to get the naming right. I would like to propose renaming the /boot/initrd-$(uname -r) images to /boot/initramfs-$(uname -r).img.

Rationale: We are not using initrd's (that is: actual block devices) for a long time now. Instead, an initramfs is a cpio archive that gets deflated to a tmpfs. And, this would allow me to drop some more of our vendor patches off dracut.

I am currently collecting affected packages. So far I found:

- aaa_base (refresh_initrd script)

- YaST

- grub

- kdump

- perl-Bootloader

Anything I am missing?

The kernel-default and co who own those initrd files.

And that'll be tricky -- if we rename it, which file name to be packaged would depend on dracut package, but dracut isn't included in the build requirement for the kernel binary package. So we can't know whether dracut prefers initramfs or initrd at the package build time.

Just make the kernel Conflict with dracut package version prior to the change, and that should be enough.

Well, not really that simple, I'm afraid, unless dracut is smart enough.

Will dracut detect whether it already uses initrd and keep using initrd instead of initramfs? Otherwise it won't work because we keep multi-version kernels and the old kernel package will insist initrd instead of initramfs while only the new kernel will use initramfs.

Won't work in what manner? dracut will create something, that something will be added to menu by update-grub or what the script is named, and loaded on boot. Only broken case is both initrd and initramfs exist and grub picks the wrong one. For that the dracut package needs to detect update from initrd to initramfs and rename the ramdisks or something. The other potential problem is that the old ramdisks will not go away when the kernel is removed because the package owns the initrd and not initramfs. If we want to address this dracut can query the kernel package content and decide according to that. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mai 04 2020, Michal Suchánek wrote:

Won't work in what manner? dracut will create something, that something will be added to menu by update-grub or what the script is named, and loaded on boot. Only broken case is both initrd and initramfs exist and grub picks the wrong one. For that the dracut package needs to detect update from initrd to initramfs and rename the ramdisks or something.

The other potential problem is that the old ramdisks will not go away when the kernel is removed because the package owns the initrd and not initramfs. If we want to address this dracut can query the kernel package content and decide according to that.

You also need to fix the postuninstall script of the kernel after the fact. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mai 04 2020, Takashi Iwai wrote:

And that'll be tricky -- if we rename it, which file name to be packaged would depend on dracut package, but dracut isn't included in the build requirement for the kernel binary package. So we can't know whether dracut prefers initramfs or initrd at the package build time.

Even more, existing initrds are frequently rebuilt, so this needs to work for old kernels too. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 04 May 2020 19:01:18 +0200, Andrei Borzenkov wrote:

04.05.2020 14:17, Takashi Iwai пишет:

...

On Mon, 04 May 2020 12:37:01 +0200, Daniel Molkentin wrote:

...

Hi,

In an effort to get the naming right. I would like to propose renaming the /boot/initrd-$(uname -r) images to /boot/initramfs-$(uname -r).img.

Rationale: We are not using initrd's (that is: actual block devices) for a long time now. Instead, an initramfs is a cpio archive that gets deflated to a tmpfs. And, this would allow me to drop some more of our vendor patches off dracut.

I am currently collecting affected packages. So far I found:

- aaa_base (refresh_initrd script)

- YaST

- grub

- kdump

- perl-Bootloader

Anything I am missing?

The kernel-default and co who own those initrd files.

And that'll be tricky -- if we rename it, which file name to be packaged would depend on dracut package, but dracut isn't included in the build requirement for the kernel binary package. So we can't know whether dracut prefers initramfs or initrd at the package build time.

Why not own both initrd and initramfs? After all, it is just a %ghost, it need not exist.

Having both may confuse the package size calculation. You can find in kernel-default.spec that kernel puts some (fixed) sized empty file as a dummy initrd. So this kind of change itches at every place in details... Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.05.20 um 13:17 schrieb Takashi Iwai:

On Mon, 04 May 2020 12:37:01 +0200, Daniel Molkentin wrote:

...

In an effort to get the naming right. I would like to propose renaming the /boot/initrd-$(uname -r) images to /boot/initramfs-$(uname -r).img.

Rationale: We are not using initrd's (that is: actual block devices) for a long time now. Instead, an initramfs is a cpio archive that gets deflated to a tmpfs. And, this would allow me to drop some more of our vendor patches off dracut.

I am currently collecting affected packages. So far I found:

- aaa_base (refresh_initrd script)

- YaST

- grub

- kdump

- perl-Bootloader

Anything I am missing?

The kernel-default and co who own those initrd files.

And that'll be tricky -- if we rename it, which file name to be packaged would depend on dracut package, but dracut isn't included in the build requirement for the kernel binary package. So we can't know whether dracut prefers initramfs or initrd at the package build time.

One could also see initrd, initramfs or whatever it's called, what format it has or even where it is placed an implementation detail of dracut or whatever tool is used to make the system bootable.

From that angle it wouldn't be the kernel package's duty to own the file. So whatever creates the initrd has to also clean it up when no longer required. In a sense like generated files or caches you'd normally place in /var if it wasn't about booting.

cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 06.05.20 um 11:57 schrieb Andreas Schwab:

On Mai 06 2020, Ludwig Nussel wrote:

...

One could also see initrd, initramfs or whatever it's called, what format it has or even where it is placed an implementation detail of dracut or whatever tool is used to make the system bootable. From that angle it wouldn't be the kernel package's duty to own the file. So whatever creates the initrd has to also clean it up when no longer required.

The problem is that the initrd generation is triggered by the kernel package, not dracut. Only the kernel knows the exact name of the initrd (which includes the kernel's %version and %release). All other places where initrds are regenerated just iterate over all existing kernel images in /boot (*including* any manually installed kernels).

Sure. The existing pre/post scripts of the kernel already pass that information to other scripts eg for bootloader or weak modules updates. So a mechanism like that also for the initrd doesn't look farfetched to me. Would be also possible to migrate at least some of that to file triggers going forward. So the kernel package really doesn't have to care. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Hans-Peter, On 5/4/20 5:50 PM, Hans-Peter Jansen wrote:

Apart what being discussed here already, I wonder, if it's the right time to break the system in even fancier ways, given that some users having enough trouble with booting TW already. http://bugzilla.opensuse.org/show_bug.cgi? id=1169783

While I understand your frustration, I think a polemic reply like this is not appropriate here. After all I was posting this here to debate whether or not cutting down on vendor patches, which generally means *less* trouble for both maintainers and users is worth it. This was done exactly to *avoid* "breaking the system in even fancier ways" because I am aware that this is a change the scope of which goes far beyond dracut. Anyway, the change you are experiencing issues with has been reverted, and after looking over the package update and the issue comments, I think I have found a fix for the issue. It's not my package, so I wasn't notified. But again, it is not helpful to the discussion to drag this into this context. Raising this in a new thread would have done just the same. Cheers,   Daniel -- Daniel Molkentin <daniel.molkentin@suse.com> Senior Software Engineeer System Boot and Init SUSE Software Solutions Germany GmbH Maxfeldstrasse 5, 90409 Nuernberg, Germany HRB 36809 (AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Fri, 8 May 2020 09:30:00 +0200 (CEST) schrieb Jan Engelhardt <jengelh@inai.de>:

But what relevant program uses these symlinks to do anything?

Bootloaders outside of the installed root filesystem. Olaf

Takashi Iwai composed on 2020-05-08 09:39 (UTC+0200):

On Fri, 08 May 2020 09:30:00 +0200, Jan Engelhardt wrote:

...

But what relevant program uses these symlinks to do anything?

That's very hard to know, every piece of private setup or scripts might be hit by such a change, and that's the problem of this kind of change which is hard to get through...

I virtually always boot from stanzas that use symlinks. They are much easier especially from grub> prompts trying to rescue an errant bootloader installation. Debian hasn't seen fit to follow Fedora's lead. initrd vs initramfs is a distinction without a difference, except to make life easier for a few and harder for more than a few. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2020-05-08 at 10:27 +0200, Michal Kubecek wrote:

IMHO an important point is that such fallout still could be justified if the change fixed an actual problem affecting users or improved the distribution for users in a significant way. I don't see either in the reasoning (for the rename) provided so far.

I fully agree. Daniel has put forward two arguments: 1. formally correct naming of the files, 2. removal of SUSE-specific patches. Wrt 1.) I'd say it's an academic argument, irrelevant and not worth giving a single thought, if it's clear that the name change will cause real problems for real people. 2.) is a different issue. The negative effect of ongoing maintenance efforts shouldn't be underestimated. However, in this particular case I don't see a real problem. AFAICS the current dracut code base contains only two related commits: 1442c9d Fix initramfs-$ver.img vs initrd-$ver in dracut-initramfs- restore.sh 16f2179 Adjust initramfs-$kernel.img to SUSE default: initrd-$kernel These amount to 8 deleted and 6 added code lines in total. I dare say that that's also not worth even the slightest risk of causing regressions for anyone. @Daniel, please correct me if I have overlooked something important. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2020-05-08 at 09:59 -0400, Neal Gompa wrote:

On Fri, May 8, 2020 at 7:03 AM Martin Wilck <Martin.Wilck@suse.com> wrote:

...

On Fri, 2020-05-08 at 10:27 +0200, Michal Kubecek wrote:

...

IMHO an important point is that such fallout still could be justified if the change fixed an actual problem affecting users or improved the distribution for users in a significant way. I don't see either in the reasoning (for the rename) provided so far.

I fully agree. Daniel has put forward two arguments:

1. formally correct naming of the files, 2. removal of SUSE-specific patches.

Wrt 1.) I'd say it's an academic argument, irrelevant and not worth giving a single thought, if it's clear that the name change will cause real problems for real people.

2.) is a different issue. The negative effect of ongoing maintenance efforts shouldn't be underestimated. However, in this particular case I don't see a real problem. AFAICS the current dracut code base contains only two related commits:

1442c9d Fix initramfs-$ver.img vs initrd-$ver in dracut-initramfs- restore.sh 16f2179 Adjust initramfs-$kernel.img to SUSE default: initrd- $kernel

These amount to 8 deleted and 6 added code lines in total. I dare say that that's also not worth even the slightest risk of causing regressions for anyone.

@Daniel, please correct me if I have overlooked something important.

This delta has knock-on effects, too:

* It makes it difficult for third-party software to detect and recognize our initramfs.

I understand the argument in general. Even small differences between distributions may be cumbersome to handle for 3rd parties. However, it's really not that hard in this specific case, is it?

* It is confusing as the documentation on the internet about this makes it hard for people to trust openSUSE's software is doing the right thing

I'd like to see evidence for that - mistrust in a distro, based on the choice of a file name? Actually, I don't believe that users are seriously confused. Who cares about the format? For novice users, all this goes on behind the scenes. Others understand that these are the files to be put on the "initrd" line in grub.cfg(*). More experienced users grok that these are images containing an early user space for the kernel for bootstrapping the OS. But only two entities are truly concerned with the file format, one is the kernel, and the other one is dracut itself.

Also, someone upthread mentioned Debian. Debian uses upstream naming in dracut mode, and uses their own naming with initramfs-tools. This has been that way for a few releases of Debian now.

I don't see what this implies for openSUSE. From the ISV PoV, I'd expect that supporting these two "modes" in Debian/Ubuntu, or initramfs-tools in general, would be a much bigger pain point than openSUSE's choice of the file name.

I personally was bitten by the delta in SUSE distributions when doing work as an ISV trying to support SUSE distributions. I want to make it easier for others to support SUSE distributions, so I really welcome this change.

Sorry to hear you had trouble, but saving ISVs some (relatively small) effort isn't worth breaking users' systems, IMO. Regards Martin (*) grub uses the word "initrd": https://www.gnu.org/software/grub/manual/grub/html_node/initrd.html It even calls that file "initial ramdisk". If we want to be consistent and avoid confusing anybody, that ought to be changed as well... -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 08.05.20 um 13:58 schrieb Carlos E. R.:

Thus, in a multiboot environment there are two possibilities:

 - grub is updated on all bootable partitions to keep track of the actual kernels that exist in every other bootable (Linux) partition.

 - Just have one entry per bootable partition using the symlink. No need to update them each time there is a kernel update on another Linux partition.

There is at least a third possibility for working multiboot: * install each OS's bootloader (does not need to be grub, can be ntldr or whatever) into its own boot partition * have one "first stage boot loader" that only chainloads these bootloaders from the other partitions. Install that boot loader into the MBR. * activate the windows partition (important, or windows will sooner or later fail horribly with updates) Never again worry about an error in one distribution's GRUB setup causing all other multiboot installations fail to boot. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov composed on 2020-05-08 17:23 (UTC+0300):

Stefan Seyfried wrote:

...

Carlos E. R. composed:

...

...

Thus, in a multiboot environment there are two possibilities:

...

...

- grub is updated on all bootable partitions to keep track of the actual kernels that exist in every other bootable (Linux) partition.

...

...

- Just have one entry per bootable partition using the symlink. No need to update them each time there is a kernel update on another Linux partition.

...

There is at least a third possibility for working multiboot: * install each OS's bootloader (does not need to be grub, can be ntldr or whatever) into its own boot partition * have one "first stage boot loader" that only chainloads these bootloaders from the other partitions. Install that boot loader into the MBR.

Yes. This is the only sane way to multiboot. This is actually what original os-prober was about - it chainloaded foreign OS *bootloader*.

Or employ <https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F> using generic MBR code. On most systems I have a primary partition whose primary purpose is hosting a bootloader, in most cases, Grub Legacy, but not unusually the original multiboot loader, IBM Boot Manager. This primary partition with boot flag is admin managed, which requires trivial effort, in the Grub Legacy case via use of symlinks in stanzas loading kernels/initrds directly instead of chainloading. Mine contain also chainloading and configfile stanzas for convenient access to previous kernels/initrds. Because Fedora doesn't create any symlinks to its current kernels' initramfses, those installations require admin effort not applicable to openSUSE, Mageia or Debian & its derivatives for the direct load stanzas. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org