Jump to content

Your vision of Mandriva 2007/2008/2009/...


arctic
 Share

Recommended Posts

God!!! You are quiet a pessimist, don't you have something positive to wish for Mandriva? :)

 

Hope dies last !

 

at least they (mandriva)are still alive, and that's a little of a wonder

Link to comment
Share on other sites

  • Replies 152
  • Created
  • Last Reply

Top Posters In This Topic

For those who, like me, didn't get the gowator's button, here's your answer. maybe i'm just a dumb american :P

Thanks for the link... funnily enough from the link

These are rumored to be the creation of a certain village smithy, Hugh F.W. Jr, from New England.

 

I'm dreading finding one in the post myself, one of these days I'll get one and I have a list as long as my arm of things that need to be done then :D

Link to comment
Share on other sites

Mandriva definitely uses hal/fstab-sync/gvm/etc. for CD/DVDs and USB devices from 10.2. I've been told by their developers on the Cooker mailing list and they have documented it here: http://qa.mandriva.com/twiki/bin/view/Main...eRemovableMedia Or look at any Mandriva box whith the default kernels - it only uses supermount for the floppy drive.

 

The steps I used where to download the vanilla source for my kernel, add in the relevant contents of the 3rdparty/ directory (all of which are device drivers compiled as modules and don't have anything to do with supermount), load the existing Mandriva config with make xconfig and recompile. The kernel RPMs I made can be found here: http://linuxonacer5020.sourceforge.net/

 

As I said before if you manually added in supermount its probably trying to use that. I didn't add supermount into my kernels (its not their by default - you have to download it and patch it in don't you?) because I don't have a floppy drive in the computer I was making the kernels for. Even if I did I'd probably just use autofs or manual mounting for the floppy, there's nothing forcing you to use supermount if you compile your own kernel for Mandriva. You'll probably agree with me when I say I think its something best avoided.

 

I know they use hal, etc, etc, but what isn't explicable is why, after a kernel compile, it mentioned supermount for the CD-ROM. I never introduced this patch to the kernel. It was raw, unpatched, unlike Mandriva's kernels, which are. Supermount for one, and bootsplash is another that I know about, god knows what else. Incidently, mcc never worked again after the kernel upgrade, but was OK if I booted a normal Mandriva kernel.

 

This patching, makes it difficult for compiling your own kernel. Who knows what else didn't work without further testing. My steps were:

 

make && make modules_install && make install

 

which takes care of compiling the kernel, installing the modules and creating the initrd and everything else putting it all in place for me to use.

Link to comment
Share on other sites

I know they use hal, etc, etc, but what isn't explicable is why, after a kernel compile, it mentioned supermount for the CD-ROM. I never introduced this patch to the kernel. It was raw, unpatched, unlike Mandriva's kernels, which are. Supermount for one, and bootsplash is another that I know about, god knows what else. Incidently, mcc never worked again after the kernel upgrade, but was OK if I booted a normal Mandriva kernel.

 

This patching, makes it difficult for compiling your own kernel. Who knows what else didn't work without further testing. My steps were:

 

make && make modules_install && make install

 

which takes care of compiling the kernel, installing the modules and creating the initrd and everything else putting it all in place for me to use.

What annoyed me in the old days was because I had a gig of RAM I used to have to use the enterprise kernel but if you downloaded the srpms and compiled it it wasn't the same as the mandriva kernel? Not even the same size!

I never did actually work out what was the reason and this was the straw that broke the camels back for me in terms oif it meant everything else had to be compiled specially as well like the nvidia driver modules for the sound and network because they wouldn't compile against the mandriva supplied source code.

 

This happened over several releases .. and 10.1 did it for me which is why I ditched mandriva .. they seemed to have some secret thing in the kernel patches they refuse to GPL ..? Mandriva kernels are actually pretty fast in my experience, even compared to a tuned K8 gentoo one ... so they must do something well, its just extremely dishonest of them to hide it IMHO.

Link to comment
Share on other sites

I know they use hal, etc, etc, but what isn't explicable is why, after a kernel compile, it mentioned supermount for the CD-ROM. I never introduced this patch to the kernel.

 

What mentioned supermount for the CD drive? your fstab? That's got nothing to do with your kernel compile - you must have put that in there somehow.

 

It was raw, unpatched, unlike Mandriva's kernels, which are. Supermount for one, and bootsplash is another that I know about, god knows what else.

 

I compiled fine from raw, unpatched kernels from kernel.org with the Mandriva .config file. The kernels I made had no supermount and no bootsplash. If you have supermount or something still showing up it must be because of something you did outside the kernel (eg. the fstab file).

 

What annoyed me in the old days was because I had a gig of RAM I used to have to use the enterprise kernel but if you downloaded the srpms and compiled it it wasn't the same as the mandriva kernel? Not even the same size!

I never did actually work out what was the reason and this was the straw that broke the camels back for me in terms oif it meant everything else had to be compiled specially as well like the nvidia driver modules for the sound and network because they wouldn't compile against the mandriva supplied source code.

 

Did you look in the spec file before you tried to rebuild the RPM, eg:

# this flag build kernels for:
# i686-up-4GB
# i686-up-1GB
# i686-smp-1GB
%define build_test 0

%define build_enterprise 0
%define build_BOOT 1
%define build_secure 0

There are a lot of build options in there for all the different kernels the SRPM can build.

 

 

Its also possible that you didn't upgrade the kernel RPM, which has to be done manually with the urpmi command (http://www.mandriva.com/en/security/kernelupdate), whereas the kernel-source RPM gets upgraded automatically when you do updates. This leads to a mismatch between the kernel installed and the kernel-source and not surprisingly Nvidia drivers and stuff won't install.

 

IMHO its one of the most stupid things they do but there are no secret kernel patches or anything like that.

Edited by timelord100
Link to comment
Share on other sites

Did you look in the spec file before you tried to rebuild the RPM, eg:
# this flag build kernels for:
# i686-up-4GB
# i686-up-1GB
# i686-smp-1GB
%define build_test 0

%define build_enterprise 0
%define build_BOOT 1
%define build_secure 0

There are a lot of build options in there for all the different kernels the SRPM can build.

 

 

Its also possible that you didn't upgrade the kernel RPM, which has to be done manually with the urpmi command (http://www.mandriva.com/en/security/kernelupdate), whereas the kernel-source RPM gets upgraded automatically when you do updates. This leads to a mismatch between the kernel installed and the kernel-source and not surprisingly Nvidia drivers and stuff won't install.

 

IMHO its one of the most stupid things they do but there are no secret kernel patches or anything like that.

I tried every possible combination, every time i updated I ended up without network just about the most serious thing that can happen if by chance you need internet access to fix it :D

 

Every time I downloaded just the kernel-source package and tried to compile the nvidia network and sound drivers they would complain about missing hooks and flags.

If i used the kernel headers same thing...

But if I actually compiled that kernel without doing anything it would actually have the EXTRAVERSION info set as custom ...

 

IMHO the .config that comes as the source for a kernel should make && make install and make EXACTLY the sdame kernel as Mandrake compiled and put on the mirrors. Even if it was extactly the same but has the EXTRAVERSION metatag it is not the same but when you start getting undefined symbols then its not the same.

 

Look at it this way....

I download a kernel from Mandriva and the corresponding kernel source ... I should be able to compile against that source should I not without any change whatsoever...

 

If the kernel is labelled linux-v.v.v-v-mdk-enterprise then kernel-source-linux-v.v.v-v-mdk-enterprise should be the EXACT source ? and if I use the same GCC version it should be IDENTICAL to the one mandriva built ... but its not. They don't even pretend it is since they fit in the EXTRAVERSION metatag ... but the fact its a different size leads me to beleive there is more to this than just a metatag and the fact it has different and missing symbols leads me to believe it is patched.

 

If I wanted linux-v..v.v.-v withoput patches and without Mandriva putting in their own stuff like -mdk meta then I would download from kernel.org and not suffer the mandriva mirrors but if I specifically try and download the source from the kernel with the exact same name I expect the .config to be the .config mdk used?

Link to comment
Share on other sites

If the kernel is labelled linux-v.v.v-v-mdk-enterprise then kernel-source-linux-v.v.v-v-mdk-enterprise should be the EXACT source ? and if I use the same GCC version it should be IDENTICAL to the one mandriva built ... but its not. They don't even pretend it is since they fit in the EXTRAVERSION metatag ... but the fact its a different size leads me to beleive there is more to this than just a metatag and the fact it has different and missing symbols leads me to believe it is patched.

the source is only the kernel source and not necessarily configured the same. for the exact configuration and source they use you would have to get the linux-*.src.rpm not kernel-source-*.rpm

 

To clarify a bit: while the .config file may be the same in kernel-source-*.rpm as the one used for building the default kernel, there are more options that can be added in the spec file for the RPM which may create a difference. This spec file should be included in the .src.rpm

Link to comment
Share on other sites

What mentioned supermount for the CD drive? your fstab? That's got nothing to do with your kernel compile - you must have put that in there somehow.

 

I compiled fine from raw, unpatched kernels from kernel.org with the Mandriva .config file. The kernels I made had no supermount and no bootsplash. If you have supermount or something still showing up it must be because of something you did outside the kernel (eg. the fstab file).

 

Nope, my fstab was completely correct. This is it:

 

/dev/hdc /mnt/cdrom auto umask=0,user,iocharset=iso8859-15,codepage=850,noauto,ro,exec,users 0 0

 

completely fine and nothing to do with supermount, yet the error still appeared! The kernel was direct from kernel.org just like you did. So it leads me to conclude that the problem with supermount is because of Mandriva, not because something was wrong with my system. I'm not actually bothered about it, because I can live with the Mandriva kernels. I don't need the latest and greatest, but it just proves that you cannot compile your own kernel without problems because Mandriva heavily patch it for their own requirements based on what they use in their distro. I have not had problems compiling kernels on Red Hat, Gentoo or other systems.

 

Its also possible that you didn't upgrade the kernel RPM, which has to be done manually with the urpmi command (http://www.mandriva.com/en/security/kernelupdate), whereas the kernel-source RPM gets upgraded automatically when you do updates. This leads to a mismatch between the kernel installed and the kernel-source and not surprisingly Nvidia drivers and stuff won't install.

 

IMHO its one of the most stupid things they do but there are no secret kernel patches or anything like that.

 

I know that kernel-source get's upgraded automatically, and I know I have to upgrade my kernel manually. So it wasn't that either.

Link to comment
Share on other sites

So it leads me to conclude that the problem with supermount is because of Mandriva, not because something was wrong with my system. I'm not actually bothered about it, because I can live with the Mandriva kernels. I don't need the latest and greatest, but it just proves that you cannot compile your own kernel without problems because Mandriva heavily patch it for their own requirements based on what they use in their distro. I have not had problems compiling kernels on Red Hat, Gentoo or other systems.

 

I disagree, Ive had no trouble compiling my own kernels with Mandriva's .config and no kernel patching. The resulting RPMs and SRPMs are on that page I linked to before (http://linuxonacer5020.sf.net). My CD/DVD and USB mounting works perfectly out of the box.

 

You still haven't said where the supermount error appeared?

 

I know that kernel-source get's upgraded automatically, and I know I have to upgrade my kernel manually. So it wasn't that either.

 

Sorry that was a reply to another poster, 2 posts seemed to get mixed together.

Edited by timelord100
Link to comment
Share on other sites

I disagree, Ive had no trouble compiling my own kernels with Mandriva's .config and no kernel patching. The resulting RPMs and SRPMs are on that page I linked to before (http://linuxonacer5020.sf.net). My CD/DVD and USB mounting works perfectly out of the box.

 

You still haven't said where the supermount error appeared?

 

I'll have to agree to disagree for the time being :P

 

The error appeared as CD's wouldn't automount, so I tried to mount manually using:

 

mount /mnt/cdrom

 

as you can see from fstab this would normally work fine, but it reported back a supermount error. Strange :unsure:

Link to comment
Share on other sites

That's just it, it's practically impossible to tie down where the hell the problem is. It would be far better for the distro to be cleaned up so that "these" type of issues don't exist. I'm not the only one who experienced them, so I know it's not just me. My kernel upgrade post clearly shows this.

 

If they're doing yearly cycles now for their releases, then surely they'd be better up cleaning and polishing the distro to ensure it doesn't have any of the old crap lying around from the previous use of supermount. The last patch for supermount was for kernel 2.6.3 or something around there. That's ages ago, so why continue to use it. Phase it out, and use autofs instead.

 

This would help make it far better, cleaner, crisper and probably a bit more leaner too.

Link to comment
Share on other sites

maybe it's an error message left over from supermount days that never got fixed, and the real problem was elsewhere? :unsure:

it could be but my experience though a different area leads me to believe the same. Im sure the old posts are around somewhere and mine is somewhat solved by the new kernel-himem setting anyway ....

 

The reaon it annoyed me was i was desperately trying to stick with mandrake at the time but I had to either accept 868MB RAM OR go through the hassle of a kernel compile (minor) followed by getting nvidia/nfoce/philips webcam/ and lots of other things working time after time ...(not minor)

 

I guess the smart thing would be just to have compiled it and stick with one kernel!

 

The fact I didn't succeed is the other thing which annoys me because if I had then it would be a learning experience but as it was it was several weeks of wasted time.

Link to comment
Share on other sites

That's just it, it's practically impossible to tie down where the hell the problem is. It would be far better for the distro to be cleaned up so that "these" type of issues don't exist. I'm not the only one who experienced them, so I know it's not just me. My kernel upgrade post clearly shows this.

 

If they're doing yearly cycles now for their releases, then surely they'd be better up cleaning and polishing the distro to ensure it doesn't have any of the old crap lying around from the previous use of supermount. The last patch for supermount was for kernel 2.6.3 or something around there. That's ages ago, so why continue to use it. Phase it out, and use autofs instead.

 

This would help make it far better, cleaner, crisper and probably a bit more leaner too.

One thing about program/OS/etc. development: it doesn't matter how much you try to clean up the code, somethings going to be screwy or forgotten, and some user is bound to find it. once one user finds it, the number of others who run into the same issue increases exponentially :lol2:

 

That isn't to say they couldn't do some clean-up, just that with something as large as a distribution it's very hard to catch everything before release. Certainly Mandriva could do a bit better of a job, though.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...