Grub2 demolishes old grub bootloaders but works fine with Windows.

What gives?

I have UBCD that I have used to get back into my old linux and it has grub2 finding ALL other operating systems and can even run ISOs it finds in /boot or in /boot-isos on any partitions it finds.

Why are these "modern" Linuxes so loathe to coexist with older systems? The older systems we FIX the newer systems with?

Thanks.

Sure they can reside in any boot partition separately but AFAIK in the MBR GRUB and GRUB2 aren't meant to coexist and be used together. I'm pretty sure the GRUB2 README would confirm that.


Since you've been cautioned for not doing things "the Linux way" (OK, whichever way that is) I take it that was a rhetorical question, right?

Agreed.

Thanks for the reply.

[Again, the point was why are modern linuxes windows-friendly and linux-unfriendly. So far it appears that unSpawn acknowleges this as fact.]

You can use grub2 with older systems and you can use Lilo or grub1 on newer systems who said you can't? Use chainloading if you want that's all grub dies for windows and you can do the same to grub1 grub2 and lilo

I've invited one of the moderators from openSUSE to field this one for their distro.

Kubuntu (and presumably Ubuntu, and probably all things Deb) does have grub1 and lilo, but I am not sure they actually installed and set up automatically. It can be a pretty complicated process.

I DO know, however, that when I tried to boot into kubuntu from a grub1 installation (from another distro) it complained "Kubuntu doesn't support booting from flopppies", though it was booting from a grub1 installed on the mbr.

So speaking for Kubuntu, Kubuntu says you can't.

That answers your question. Mine remains.

And we're still waiting to hear openSUSE's explanation... they don't even HAVE lilo or grub1.

Mandrivia, I think does work with older linuxes, but it's also endangered by that fact because the less considerate linuxes will kill it same as they do an older linux.

Thanks for the reply.

[The question here was why are modern linuxes Windows-friendly and Linux-unfriendly. There must be a reason. Type kwrite /etc/fstab in a terminal and we'll start a new thread looking into possible reasons. Type 'su' in openSUSE or 'sudo su' in kubuntu and try the same thing. I can show you how to get both to work and work without crashing, with or without the commandline noise. But the larger issue is that there must be a reason for this situation having evolved in the first place.]

That is just your interpretation of my words and not what I said.

I do not compare Linux distributions with Microsoft products.
I make no distinction between Linux distributions for subjective, arbitrary reasons.

I believe you wanted to say that auto-configuration of grub1/2/lilo is windows friendly and not other-linux friendly. Well that's probably because the men who write this auto-configuration tool assume that say 90% of the users will dual-boot their system with windows, and the rest 10% is experienced enough to install and configure the boot loader of their choice.

I never had any trouble configuring lilo, not even the first time I installed Slackware 10.2
For a little time I had 2 windows and 2 linux all booting through lilo configured by hand. I have never used grup (I have installed Slackware/Simply Mepis/Debian/Gentoo/Backtrack 2 all with lilo, all configured by hand, no difficulty).

A couple quick notes and then possibly a wrap for this thread.

unSpun. You didn't need to "intend" to agree with my obsevation. You, in the context of your reply, simply did agree.

The entire conversation is still there.

Segmentation Fault: I think slackware, and possibly whatever distro you are now using if it's not slack, is like mandrivia and not really part of the problem which is being caused by the more mainstream distros that do NOT expect even 10% of their users to know how to deal with grub, much less launch a terminal. (I'm flat out serious.)

Thanks for the notes!

May I proceed? :-)

This is a fairly long one but may be a real eye-opener to you old-timers and "traditional" linux users.

[Disclaimer: This applies primarily to KDE-based linuxes but to an extent also Gnome due to it's tolerance of THE grub2 anomaly.]

As mentioned above, there is no grub1 for openSUSE, for example. That is there is no opaque rpm binary download for it.

So we could compile grub1 from scratch. That is if it required compilation. It's mostly script based, but let's say we need to compile it (or anything else for that matter).

Now let us ask ourselves how we might compile ANYTHING on a kde system such as openSUSE or Kubuntu.

On kubuntu, it's possible, at least with Casper/oneiric. With 12.4 I decided to revert to 11.10 due to the fact that they wiped out too much of the environment for anything to work except cmake and a few other things -- provided they cooperate
with dash (as opposed to 'bash').

That last point isn't a big deal for most programmers but it might take a bit of poking around to discover that the default shell (dash) is causing problems finding and linking pthreads.

Not pthreads itself and not code source. Let's put this all on one line so it shows all over the internet. Pthreads isn't the problem in *buntu. 'DASH' apparently is. It can't handle the syntax of the assumed 'BASH' shell sometimes.

So up until the lastest (admittedly alpha) Kubuntu, folks could at least compile from sources.

That is the check and balance in open "source". It keeps the developers honest, increases the risk of getting caught if they pass stuff around in these huge distros that consist almost entirely of 'opaque' source binary packages.

But how does openSUSE stack up in the compilation area?

The DVD comes with nearly all the dependencies required to build anything excpt kde from scratch. That's great.

But can you compile?

The answer is long and ranges from questions about /usr/local installations that get pkg-config data re-routed into /usr/share folders (where it cannot be found, nor removed if you uninstall), to questions about terminal apps in general, and finally to about the attitude at the forums regarding low-level programmers, which is not only not conducive to curiosity and investigation (never mind meaningful bug reports), but genuinely suppresses questions about the source of some of the more obvious and egregious oversights on the part of KDE.

So let's condense this to a nutshell.

Let me prove this point about 'opaque' binary packages and lack of oversight that is caused (literally "caused") by this intolerance toward low-level experimentation and inquiry.

[I have warned them to remove this package now three times over a period of as many months. Time's up! THIS is what happens when you don't encourage people to "play" with their systems. THIS is what happens when those at the top say "trust us" and we foolishly follow along, in violation of the very concept of "open" source.]

http://ftp5.gwdg.de/pub/opensuse/fac...26-1.1.src.rpm

This (above) is the file linked at the opensuse downloads page if you search for libffi and grab what looks like the "latest" for a "standard" openSUSE 11.4 distro.

Here's the trail to tht link.
http://www.opensuse.org/en/ [hit additional software, search "libffi" for 11.4]
We end up here.
http://software.opensuse.org/search?...ude_debug=true

There are several packages. Let's get the latest. It's libffi45 about halfway down the page.

This is an allegedly "standard" source package for openSUSE 11.4, as we can see. That's the finalized distro which I got as a DVD because I use dialup.

This libffi package should have been 280K not 58 megs.

While there is nothing inherently dangerous in downloading (3 hours for dialup users) and compiling GCC for X hours, it's inconvenient, disappointing, unnecessary, and indicative of what CAN happen when we don't keep our eye on the ball -- or "keep many eyes on the ball" which is one of the main purposes of "open" source.

It has been my experience that about two out of three source packages from openSUSE are fouled up in one way or another. From missing content to corrupted content to unexpected end of file errors and ... The latest was amarok, patches that didn't work straight out of the bux but when forced broke the compilation at 46% when it discovered a file that didn't exist.

Before closing this part of my explanation of why I question the direction linux (KDE-based, mostly) is heading:

Define "source" as in "open source"?

Back to the question about Linux being unfriednly to linux, it appears that linux has lost it's base philosophical advantage and while it remains highly secure at the user level, there are NO CHECKS on what is being done at the development level.

I think this is a wrap for this thread.

Thanks for lending an ear.

And thanks for the comments, guys.

And now you old-timers know why I am asking this question. It's not about YOUR linux. It's about mine.

:-)

1 members found this post helpful.

Gentoo sourcemage sabayon Linux from scratch and other source based distributions do just fine at source security. I don't use kde or Ubuntu so untested but I don't see how kde or gnome has anything to do with grub and Lilo as your login manager isn't required to start on boot etc

Since when do binary packages need to be classified arbitrarily as "opaque"?.. OpenSuSE up to 11.3 uses GRUB legacy aka GRUB 1. While it's not being enhanced anymore the OpenSuSE source package is still available as "grub-0.97-82.src.rpm" issuing 'rpmbuild --rebuild grub-0.97-82.src.rpm' as root account user will rebuild the package. Even those who are not "old-timers" or "traditional linux users" know that's all there's to it. To be able to do something you need to know the commands. If you don't know them you can look them up in the documentation your distribution comes with or ask. That doesn't take much time and it doesn't require extraordinary prowess. To be able to compile something you need a compiler. This means you need to install a development environment. That's just common sense. So anyone, provided they know how to read, have the ability to learn, find the documentation and issue the right commands can do this.

It's kind of sad to see that most of what you wrote is based on misconceptions, it's sad to conclude the only purpose your responses serve is to illustrate again what you've been cautioned for (not doing things "the Linux way") and it's doubly sad to see you thought writing childish remarks would serve you trying to make your point. Still it's not too late for even you stop fscking things up out of sheer ignorance, stop blaming others and learn to use Linux as it was meant to be used.

Good luck with that!

If you really think KDE is the problem, hit Ctrl-Alt-F1
You don't need an IDE to compile a package, you need the necessary compiler(s) like gcc/g77/javac etc
If you think your shell is the problem, change it to what is more appropriate for your purpose. Bash scripts are just that: bash scripts. They don't run on tsh,csh.
I'm currently using Gentoo, but in Slack I had installed a lot of packages from source, which was as simple as
"configure && make && make install".
Finally, if you think a specific distro doesn't do what you want, then don't use it. Try find another that fits you better. And then another, and another. That's a luxury you don't get with non-open-source software. And study as much as you can about your computer. Hardware and software. You are that system's administrator, you have to know everything about it, so study as much as you can and you will be rewarded.

Are they or aren't they opaque? Are windows binaries visible? If the sources do NOT match the binary, come to your own conclusion.

I have had suse 8.1, 10.0, 11.1, 11.3, and now 11.4.

Before I risk (again) losing my older linux in this experiment, what are you willing to bet that if I follow your (admittedly) 'linux way', that my kde-based linux will behave in the 'linux way' in return.

I caution you before you wager too much that 'kdesu' is NOT the linux way. Having to use kdesu or any of the other wrappers to run gui apps is a disconnection in the assumption that "all the parts work together". They do NOT work together. And in the case of openSUSE, if you are already root and you run kdesu, not only will it crash but it will take drkonqi with it -- and no bug report can EVER get out to the developers.

Furthemore, if you type kwrite /etc/fstab on the commandline and get 30 or more lines of warnings and errors, is leaving that JUNK in the terminal the "linux way"?

Make it worth my time and I'll test your "theory".

I now know the commands. Copied to file and I thank you for that. Now all that remains is a question about what I might need to do if I reinstall -- to keep my old linux in the loop.

I have copied 18 blocks of the mbr, and I have restored that with success in the past.

But that is not what you recommended. What you recommended is an arbitrary, presumed to work recipe handed down by folks you don't know about a linux distribution you don't use.

I should also warn you that I used the grub2 option to update legacy (the "linux way") which supposedly DOES work with older grubs without success too. But I forget if that was Kubuntu or openSUSE that that failed on.

Still, I'm willing to try your experiment if you are willing to believe me when I tell you the results.

I am willing to retract if it works, and I'll be grateful on top of that.

Deal?

(That grub has a number that looks like a grub2 and you can't rebuild an rpm that isn't installed, and I see no 'spec' file in your recipe. But who knows...)

With a bit of work I got kdevelop3 to work in my openSUSE and also in Kubuntu. It's the best programming editor/ide around.

Kdevelop4, on the other hand, creates 50 MEGS of JUNK for every "hello world" app you write. (And again, I'm absolutely serious. It's shocking.)

But thanks for the tips and I would have agreed with your statement a few years ago. But things have changed, and not for the better, though I truly LOVE the plasma desktops.

And I am indeed looking for something that suits my needs. So far it doesn't exist and I'm having to build it myself.

That doesn't help anyone else.

Thanks again. :-)

Let's make this interesting.

For this we'll need to tool up. (It's easy, not to worry.)

The original question was why are modern linuxes windows-friendly and linux-unfriendly.

We are now investigating whether or not modern linuxes have lost their "linux way".

For RPM-based systems.

If you don't have fileroller, here's how to take a look inside RPM files, which we'll do in order to see what's in an RPM before committing to an installation.

In source files we can also see what is supposed to be patched and even see if those patches are being applied. We can also check to see if the paths in the spec file in source packages match the paths where we actually find the files in a system that is supposedly built from those sources.

This also extracts the pre/post scripts, so in a way it may be better than fileroller.

[This simple version expects the rpm or a link to it to be in the current working directory and extracts only one file at a time.]


For Kubuntu and other debian

We can use the dpkg functions or even
to extract the control and data tarballs.

We can compare the data in the control files to what is in the /var/lib/dpkg status and info files.

This may be of interest to those who have installed Kubuntu and found that muon and/or apt-get delete their systems down to a bare bones terminal setup. If you have high-speed internet AND are connected to the net when you install you may never notice this 'effect'. ;-) But deletion of your desktop, all of kde, and even x11 is real, provable, and repeatable in Kubuntu if you install from the DVD without an internet connection -- and possibly under other circumstances.

For All KDE/Gnome

For this let's prime the pumps with the general question about these modern linuxes:

Is backdoor downloading the "linux way"?

It's certainly the Windows way. But is this something we want our linux distro to do?

How reliable are the binaries we are getting passed? Who wrote them? And most importantly, "who is checking" to make sure these packages are what they say they are?