Jump to content

astronomer

Members
  • Posts

    11
  • Joined

  • Last visited

astronomer's Achievements

New Here

New Here (1/7)

0

Reputation

  1. Ya, I did that to get it going, but better to understand what is happening with it. No we do not use DHCP here, and I agree - I see no real usefulness for resolvconf so will drive a wooden stake through its... well, I'll kill it anyway. Thanks for the response.
  2. Hi ffi. Fluxbox did not install with 'Other graphical desktops' and was not in the DVD ISO so I just grabbed the source. Same with wine but I had the latest source already at hand so just built it - my wine app is 'mission critical' so I usually manage it myself anyway. I have added repositories to urpmi and installed a few more things today, lyx, gnuplot, all the greats! Hope kdm gets fixed. Thanks.
  3. I recently attempted to install 2009 RC1 and encountered a few problems (see first 2009 install post). Thanks to all for the responses. I have now found time to get it all working and thought it deserved a second post - hope it is OK to start a new thread... My biggest problem(s) with the first attempt were a lilo failure complicated by my first brush with UUIDs in the lilo.conf and fstab files (ie, my own lack of understanding). I think I now have the 'failure' resolved and have accepted UUIDs as a fact of life and implemented an alternative using labels which accomplishes the same thing (suggested by arctic). The lilo failure was related to the installation being on an older system (HP cica 2003, 1.3ghz, 250gb disk). It turns out that the BIOS does not correctly handle disk geometry beyond 137GB - vmlinuz and initrd.img were sitting right on the 137gb blocks so lilo got it wrong (from the BIOS). I had been aware of this limit long ago but had never hit it on this box... (also, my 2007 lilo on the same box was able to create a chain boot to it - odd). Anyway, I reclaimed a lower swap block for /boot, resized a couple of partitions with diskdrake (great tool!) and got it all going... So - finally - 'second' first impressions... quick answer: overall another GOOD Mandriva distro in the making! ... long answer: here we go... KDE 4 - this was my first look at KDE4, I am a long time KDE user, but much like the transition from KDE2 to KDE3, I think KDE4 has a ways to go. Overall look and feel is pretty good... I keep feeling as if I am missing the point with plasma (a possibility) - it is different, but what is the 'advantage' - that is, what compelling reason is there for using it? I also found KDE4 to be a bit slow. Granted this machine is showing it's age, but it is still a workhorse and has no problems at all with 2007 PowerPack/KDE3. I also found KDE4 configuration choices to range from obscure to missing in action. So - KDE4 looks nice - but let me know when it is a little more useful. KDE3 - I switched to KDE3 and found it to be mostly familiar and pretty much as fast and useful as on older Mandriva distros. The difference between it and KDE4 was very apparent on this machine. I selected the KDE menus instead of kicker (another new thing to me - why?) and got down to work. I have a single 'must have' legacy application from anotherr OS that I have run under Wine since Mandrake 10 days - so I needed to see it work under 2009. I downloaded source for wine-1.1.4 and compiled - had to also compile GNU Bison from source as there was no pakage on the DVD. All went well - worked out of the box and my legacy app fired right up! Excellent! I also compiled the latest Fluxbox (1.1.1 as I recall) and there were no problems until I tried to add it to kdm... the familiar configs were not there and it was all very confusing. I was able to figure out that I needed to add a file to /etc/X11/wmsessions.d/... but that had no effect. I found a page on the Mandriva wiki that supposedly told how this should work using 'fndSession', but it was certainly not a 'how-to'... I got it going but with as many WMs and tastes as there are, this really needs to be better documented (or the better docs need to be much more accessible). Also, the MCC does not seem to offer any choices on configuring dm or kdm - don't think I missed anything. But - the newly compiled Fluxbox also worked fine with no other packages required. In getting Fluxbox working I also found that I could not get a text login from kdm - it would kill the Xserver and look like it was going to give a text session - then the Xserver would restart and you are back where you started. This was easy enough to get around with ctrl-alt-F1-6, but the menu item needs to at least work. I also had difficulty with resolvconf rewriting my /etc/resolv.conf file. This was also new to me so I did my homework and see how it is supposed to work - but I think it is a mistake to enable it by default. Anyway, I disabled it using MCC/Boot options... but it still clobbers my resolv.conf file. I see a couple of ways of stopping it but still don't know why it persists after being turned off... anybody else had experience with this? But for now I am out f play time so it will have to wait a few days... Lilo - I am, and remain a lilo diehard - even more so after my ability to ultimately cope with the initial boot problems I experienced - and in rebuilding the boot loader for all partitions after it became unbootable. I had to take a refresher course on it, but remain warm and fuzzy with lilo ;-). It seems to be an inactive project - I really hope it is not abandoned - but it is still a solid, useful boot loader system and I am glad to see it in 2009 - and beyond I hope. But I found that MCC does not offer a graphic lilo boot screen - any reason why? Hope that is included in the offical release. I have more comments but no more time... so to close - even with my own problems getting things going, I am looking forward to the 2009 official release - and the Power Packs. We had planned to evaluate moving most of our production boxes to 2009 and still plan to do so. Clearly we have some new things to learn and cope with, but the attraction of Mandriva for us has long been the ability to do so without any lingering mysteries or obscure configurations or dependencies. Easy installation, good hardware support out of the box, solid basic kernel build with few surprises, good continuity of structure (mostly) from release to release... we will stick with Mandriva. Thanks for reading this way too long post! Anybody else tried 2009?
  4. Thanks Adam. I have been able to boot the 2009 install by working with my 2007 lilo, but not yet by generating the boot record within 2009, so I think there must be a problem there. I hope to have some time to look at it more in the coming week and will file a bug report (as opposed to a rant ;) ) once I understand what is happening. I agree (mostly), but old habits are hard to change, even if it is just training your eyes to land at a different place when you look at the file layout. And please do not think me to be argumentative which is not my intent, but perhaps the term 'readability' was not the best choice - 'meaningful to humans' is probably better. Strings like... UUID=ddee4f6c-7dac-11dd-90ce-c7961ac25dfa LABEL=Tosh_100_12 /dev/sda5 ... are all readable, but the second and third are meaningful on their face in a way that the first is not, particularly when they occur in a list. Thanks for the help.
  5. Yes there are +/-'s, but I can see that it is becoming 'standard' and will adapt. The big minus is still the 'not meaningful to humans' property, but I will address that by using volume labels which retains all the goodness of UUIDs while being meaningful to humans, and me, with only a little thought on my part... I admit to the same perspective - mostly - lilo is familiar. But in my own case, I looked at grub several years ago and had more than one bad experience/frustration with it. Some of it may have been my own lack of understanding, but I concluded at the time that it was buggy/unstable and returned to lilo. I recall reading other's comments at the time to that effect also, so I was reinforced in my prejudice in any event. On the other hand, although I would not claim any expert status, I have always been able to solve lilo based boot problems and to get things to work the way I wanted, which counts for a lot! (I have since been able to boot my 2009 install by working from my 2007 lilo, so one more lilo success! I hope it is not abandoned... :unsure: ) Thanks for the comments pmpatrick.
  6. Thanks Adam. I now understand the problem this is intended to solve, and I see the upstream changes that it addresses. And in retrospect these things were not the real problem I ran into, but they were unexpected stumblingblocks to recovering from that problem. The original problem was a lilo bootloader failure. So first, I would draw your attention to the fact that the 2009 rc1 setup does seem to have problem setting the bootloader with lilo. I think that problem is with passing the UUIDs as parameters, specifically in my case one of these two lines: root="UUID=ddee4f6c-7dac-11dd-90ce-c7961ac25dfa" append=" acpi=off resume=UUID=0d094110-9a8a-11db-91b0-37356fad212b splash=silent" When I switched from grub to lilo during the installation process it reported no errors, but boot failed completely on restart - no lilo menu at all. Sending the 'root' line (in proper context) to my 2007 lilo causes it to fail, and the 'resume=UUID=...' appears incorrect on it's face, my best guess is that it should be something like 'resume=UUID:...', and probably the 'root' parameter should be passed in the same way - but I have not fully checked that out. What I do know is that with a running 2009 rc1 install if you switch from grub to lilo using MCC it fails due to the 'root' line. So there seems to be a problem with 2009 and lilo in any event. My guess is that the installer masked the lilo errors during install, which resulted in my inability to boot it. Now, that said, the hda/sda change (beyond your control) frustrated my efforts to recover to the 2007 lilo config, and the UUIDs in fstab added much to my difficulty in troubleshooting and recovering from the lilo failure - which I suppose is the real strength of human meaningful configs. The comment lines above each entry are helpful and much appreciated, the problem with them is of course that they are comments and not config data and can become out of synch with the lines under them. If I could suggest, maybe you could add the use_uuid=0 option to the installer options so that users who care will at least be aware of it - I certainly was not. Thanks for the reply, and for your work on Mandriva!
  7. Hi viking777, That is a good idea. It meets the meaningful to humans and uniqueness requirements, and it is easy. I think I will incorporate that into my own methods-and-habits as the best way around this problem. (HA! Although it was never a problem for me until I ran into the solution!). I think this also illustrates a comment I made in an earlier reply, in an obscure way. It requires human thought and awareness. The UUID solution does not require any thought - it is an attempt to solve a problem without the user having any awareness of it. But it proves to be a big problem for those users who ARE aware of it or who must solve a related problem, and cannot now make use of the solution! I think the best solution is to explain the connection between the configs the hardware and the various identifiers, and the options for using it. The 'no thought' option will be one of them, but then we at least keep the user pool aware of how it works instead of letting it quietly slip below the consciousness level.
  8. Thanks arctic. I have not run into the xorg.conf autodetect problem myself. I had a couple of laptops that required significant whittling of the X config to get going, but the last few years things have been pretty solid so I have not paid much attention to it. But as with the UUIDs in fstab and other things meant to make Linux somehow easier to use, I agree that Linux development has taken a few wrong steps lately. One of the very strengths of the *nix philosophy, one of the reasons it is so good, and one intentionally adopted from the early MIT/ATT days (actually B4 unix for the youngsters), is the very fact of plain text, human readable data streams - particularly with regards to system configuration. Just as with document formats, human readability is the ultimate guarantee of unlimited, uncontrolled future use. If a human can open a file and make some sense of it's meaning, then a human can use it and adapt it. If a human cannot determine the meaning by inspection, then there exists an impassable brick wall somewhere ahead on the 'future use path'. I am all for making things both easier to use and more robust. But that should be done on the basis of those solid foundation principles, written and unwritten, and not as a departure from them! (Side comment: Just as it will inevitably prove to have been a very fatal mistake to trash the principles of Magna Carta for little political convenience, and for the same reasons). Two of those foundation principles of *nix are human readability and simple cause-and-effect connection between configuration and behavior. Departures from either for the sake a few new users' convenience will ultimately prove fatal... I think it is that serious.
  9. Forgot to add to my first reply ti ffi... Any friend of Thomas Jefferson is a friend of mine! Those words, and many more have an immediacy that this generation is only beginning to get a glimpse of and I fear, may never actually understand. Software freedom is only one aspect of it, but a most important one as it is directly connected to freedom of information, knowledge and thought. It REALLY is all about the freedom! Thanks for the quote! If you want a full sermon - just ask!
  10. Thanks ffi, glad to be here! I had not seen that before, will try it out as I explore the 2009 candidate(s) in coming days. HA! I had not seen them used in basic system config files before and did not understand the reason initially, which was the cause of my alarm. I see the 'problem', although I have never considered it to be a real problem (I call it basic system administration ;) ), and after looking into it I see how UUIDs can resolve runtime confusion, but to do so at the cost of human confusion does not seem to be the best solution. I will probably 'sermonize' more on this in another reply down the list... On the other hand, there does seem to be a problem with passing UUIDs as lilo parameters, which is why my 2009 install would not boot. I do not have the definitive answer on that one yet, but I should later today. More on that down the page... Yes, I see that. That is not actually a big problem in the overall scheme of things. Mostly it meant that I could not easily restore my working 2007 lilo configuration because the devices it refered to did not exist in the new context. But a little thought resolved that. On the other hand, it will be something I will have to sort out if I want to have a lilo based multi-boot box with an older kernel. Probably come down to editing some lilo.confs fstabs. I have managed my Linux boxes (and mostly Mandrake/Mandriva) for such a long time without any surprises, the hda/sda change looked worse than it actually is. Thanks for the link, I had never seen that. A long standing problem from the looks of it! I have a couple of boxes that are still dual boot W2K/Linux, but I had not realized I had never done a multi-boot with different Linuxes on the same drive, and that is actually the problem isn't it? It comes down to which kernel 'owns' the boot process. If you update the boot loader config in one install, all others become invalid. Nasty little problem when you look at it! My first thought is to resolve it by a sysadmin method, simply deciding "this kernel owns the boot on this box" and when changes are necessary, do it using the boot owner. That might get messy if you installed new distros on it very often, each of which would want to install it's own bootloader, but not too bad if you are expecting it. But my usage and admin methods probably aren't for everyone! But as I mentioned above, there does appear to be a problem with how UUIDs are passed as lilo parameters. First, I tried to add a UUID based record to the lilo.conf of my 2007 install to boot to my 2009 install, using the lines found in the 2009 lilo.conf. But when I run lilo it fails on the root="UUID=blahblahblah" line. Lilo can't use that syntax, so this appears to be an error. I had my brother try to change from grub to lilo on his working 2009 install using MCC and it failed with the same error. So there does seem to be a problem with lilo on the 2009 rc1, and it seems to be related to how the UUIDs are passed. It may be possible to pass them using a different syntax in an "append" line, I hope to play with that later. Anyway, thanks for tips and the reply, hope this is all helpful to others - it sure jarred my brain cell, but I am getting over it now!
  11. Hello everyone. I am longtime Mandriva user, fan promoter - happy camper! First time to post here though. I have several systems, personal and production, all 'standardized' on Mandriva since Mandrake 7.1. I run 2007 Power Pack on my main systems, except still 2006 on my #1 laptop/development/mobile system. I have decided to change most things to 2009 when it is released and decided to have a first look at it after my brother installed it and said he was suitably impressed. I do not have a free system to dedicate to it at this time, but I have an unused 100GB partition on an HP system that runs 2007 PP. It is also the main repository on my network for local urpmi source, a few apache virtual hosts and my online library. My confidence based on past experience with Mandriva led me to decide to just install to the empty partition and have a quick look... BAD MOVE! The installation went smoothly as far as I could tell, and I used custom disk partitioning to format the unused 100GB space as ext3. At this point I did not notice that it also refered to the device as 'sda' instead of 'hda' - should have been a clue. I was also disappointed that it installed GRUB and did not ask (at least that I noticed) whether to use GRUB or LILO (my favorite). So after it finished I clicked the bootloader configure button and changed it to LILO. At this point I noticed that it did not list the pre-existing 2007 installation... hmmm... I went on to the reboot... which failed with 99.99.99.99.99.99.9.... displayed on my screen! No LILO menu, no nothing! I booted to a rescue CD and had a look around. What had been 'hda' was now apparently 'sda', there was no MBR record as far as I could tell (single 250GB IDE hard drive). It has been a while since I looked closely at disk partitioning - it usually just works - and I do not claim to be expert, so I did some research for a few hours (as my much needed system was down!). What I found was there was no MBR record - 2009 had failed to write one as far as I can tell, even though I had no such indication. I was able to mount my existing partitions using a rescue cd, but the names did not correspond to the lilo.conf or fstab entries in my 2007 filesystem. Everything 'hda' was now 'sda', and I could not easily figure out how to fix that (suggestions or explanation please, anyone?). And when I looked in the 2009 partition at lilo.conf and fstab I got my first introduction to this mess - root="UUID=ddee4f6c-7dac-11dd-90ce-c7961ac25dfa"! I now get the sense that using UUID in lilo and fstab is the default in current kernels - but that has got to be a MISTAKE! I know I can get the UUIDs for devices easily enough, but the complete loss of human readability is a disaster! I routinely edit fstab and lilo.conf to add devices and change configurations on all my systems. Simple, easy, I always know what I have and if I am in question a quick peek answers the question. That is impossible with UUIDs in these critical configs! Please, please, please... rethink this before 2009 is released... Anyway, back to my problem. I was able, after some effort, to restore my MBR from my 2007 lilo.conf and recover to where I was before I started this exercise. I see that the current kernel assigns IDE/ATA devices as 'sda' instead of 'hda', which is not a problem on a single boot system, but sure was a problem in trying to recover to a working system. If anyone can tell me a quick way to do any of the following, would be much appreciated, and certainly of help to more people than just myself who might try to install 2009 to an existing system: 1. Tell the installer to use existing block device names (ie, hda) 2. Tell the installer/ system to NOT use UUID in fstab and lilo.conf (probably other places). 3. Get Grub/Lilo installer to recognize existing boot records. Anyway, I spent an entire afternoon trying to understand and fix this, and consider myself reasonably competent with Linux, Mandriva in particular. I think many people would not have been able to recover to a bootable system without losing existing data. As it is I am none the worse for the experience other than loss of time, but I still do not have a bootable 2009 install. Now I know, this is 'beta', or 'release candidate', but the problems I encountered were not evidently related to a 'bug' or 'problem', this appears to be the way it is going to work. I think that simply not changing device names (hda to sda), or at least warning about it - would be a big help. Giving a choice whether to use UUIDs or human readable device names would sure comfort old-timers like myself! We get a little slow to pick up new fangled ideas at this age... Anyway, thanks for reading - I'll write again after I get my thoughts collected and try again...
×
×
  • Create New...