Jump to content

2009 rc1 install problems


astronomer
 Share

Recommended Posts

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...

Link to comment
Share on other sites

Hi Welcome to MUB :D ,

 

Tell the installer/ system to NOT use UUID in fstab and lilo.conf (probably other places).

 

In the 2008.1 release notes there was a remark on how to use device nodes instead of uuid, maybe you can use it for 2009 too: http://wiki.mandriva.com/en/2008.1_Notes#U...tition_mounting

 

I used to hate those uuid's too but come to like them, though they are unreadable it makes booting far more reliable before uuid every time I removed/added a (removable/fixed) disk booting would fail because the drives would be enumated differently but with uuid this doesn't matter anymore.

 

Tell the installer to use existing block device names (ie, hda)

 

the change from hdX to sdX is inevitable though because of kernel driver changes (new libata) with every kernel >2.6.16

 

 

 

3. Get Grub/Lilo installer to recognize existing boot records.

 

it should...in theory...there is a lenghty bugreport though, see https://qa.mandriva.com/show_bug.cgi?id=16604#c56 on what to send if it fails for you

Link to comment
Share on other sites

Not much to add to ffis post.

 

UUID has is advantages and disadvantages, that's for sure. From a system-stability point of view, UIIDs are better than devicenode hda or sda entries. But - as you realised - they are not as easy to manage and really user-unfriendly.

 

I am getting a bit off-topic here, but another thing that turns me off even more than UUIDs is the new xorg which leaves the xorg.conf pretty empty as it tries to automatically detect the graphical devices at each boot. Yes, it has some advantages too, but ... how shall I fix an xorg.conf file if there is nothing written in it? :wall:

 

Lately I get the impression that Linux-development has taken the wrong path...

Link to comment
Share on other sites

UUID's are a complete pain. I always change my fstab and menu.lst to mount by label which gets around all difficulties (dev/disk/by-label/.... and root=LABEL=....... respectively). Of course this cannot be done by default as devices don't have labels by default you have to add them manually (see man e2label) but once you have done it you can read the labels easily and it overcomes the partition renumbering problem.

 

NB if you want to label your swapfile you need mkswap -L .....

Link to comment
Share on other sites

I am getting a bit off-topic here, but another thing that turns me off even more than UUIDs is the new xorg which leaves the xorg.conf pretty empty as it tries to automatically detect the graphical devices at each boot. Yes, it has some advantages too, but ... how shall I fix an xorg.conf file if there is nothing written in it? :wall:

xorg.conf overrides the autodetection (some entries at least) but I have seen far more times that xorg.conf was unuseable and x was unablt to start than auto detection being wrong...

Link to comment
Share on other sites

The point of UUIDs is to avoid problems like the hda -> sda switch. That is caused by an upstream kernel change that we have no control over. Using UUIDs avoids it being a problem. It also solves problems like the /sd* enumeration changing if you boot with a USB drive connected, which happens on many motherboards.

 

Sorry, but we're not going to change it. There's already a comment above each UUID line to make it obvious which device it was initially created for, and as you noted it's easy to find the UUID of any given drive. If you don't like UUIDs you can switch back to /dev names or switch to labels, but we won't change the default.

Link to comment
Share on other sites

Hi Welcome to MUB :D ,

Thanks ffi, glad to be here!

 

In the 2008.1 release notes there was a remark on how to use device nodes instead of uuid, maybe you can use it for 2009 too: http://wiki.mandriva.com/en/2008.1_Notes#U...tition_mounting

I had not seen that before, will try it out as I explore the 2009 candidate(s) in coming days.

 

I used to hate those uuid's too but come to like them, though they are unreadable it makes booting far more reliable before uuid every time I removed/added a (removable/fixed) disk booting would fail because the drives would be enumated differently but with uuid this doesn't matter anymore.

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...

 

the change from hdX to sdX is inevitable though because of kernel driver changes (new libata) with every kernel >2.6.16

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.

 

it should...in theory...there is a lenghty bugreport though, see https://qa.mandriva.com/show_bug.cgi?id=16604#c56 on what to send if it fails for you

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!

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Lately I get the impression that Linux-development has taken the wrong path...

 

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.

Edited by astronomer
Link to comment
Share on other sites

Hi viking777,

 

UUID's are a complete pain. I always change my fstab and menu.lst to mount by label which gets around all difficulties...

 

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.

Link to comment
Share on other sites

The point of UUIDs is to avoid problems like the hda -> sda switch. That is caused by an upstream kernel change that we have no control over. Using UUIDs avoids it being a problem. It also solves problems like the /sd* enumeration changing if you boot with a USB drive connected, which happens on many motherboards.

 

Sorry, but we're not going to change it. There's already a comment above each UUID line to make it obvious which device it was initially created for, and as you noted it's easy to find the UUID of any given drive. If you don't like UUIDs you can switch back to /dev names or switch to labels, but we won't change the default.

 

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!

Link to comment
Share on other sites

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!

 

 

 

Sadly, those are very true words indeed :sad: 

Link to comment
Share on other sites

For what it's worth, I have a few observations that you may find useful. First with UUID, there are definitely pluses and minuses involved in using that system. UUID is pretty much standard on debian and all debian based distros now, including ubuntu. It was originally adopted when libata was undergoing rapid development in the linux kernel and no one could be sure how hard drive device files were going to be designated from one kernel release to the next. UUID should be invariant regardless of how the kernel designates the drive device file. However, unlike partition labels, UUID is embedded at the filesystem level. As a result, if you reformat or resize a partition, the UUID will change which can lead to a whole host of problems if you are not aware of that fact. For example, a lot of distros will reformat an existing swap partition during an installation. If you are dual or multi booting several distros all using the same swap partition, this will cause the swap partition to disappear because the reformat caused swap's UUID to change.

 

Re lilo vs grub. I was a lilo guy from way back and always preferred lilo to grub basically because I knew lilo and didn't want to learn a new bootloader. However, lilo is not being actively developed any more and every distro except slackware and some slack derviatives is now using grub. It's really time to take the plunge and learn grub. Once you do, you will find grub is much easier to use in situations where device file names are changing because you don't need to write changes to the mbr every time you make a configuration change in the bootloader. This can become a real problem with lilo where your root partition has gone from hda to sda in a kernel upgrade but you can only boot with the old kernel that still uses hda. You can edit lilo.conf to go from hda to sda in the old kernel but you can't write that change to the mbr because sda doesn't exist when the old kernel is booted. You'll just get an error message if you try to run lilo -v.

Link to comment
Share on other sites

I think possibly lilo / UUID has not been properly tested. It would be fruitful to file a bug on this.

 

I also think people are overstating the readability issue. A UUID-based grub or lilo config or fstab is not at all unreadable. It's just not what you're used to. UUIDs are not that exotic, they're just a random identifier. I use the same technique for identifying them as I do when manually checking md5sums - just look at the last three characters and remember those. You're very unlikely to have two disks whose UUIDs end in the exact same three characters.

 

Any time you actually need to *enter* the string you can just copy / paste it. There are several tools or just commands (look in /dev/disk/by-uuid ) you can use to identify drives by their UUIDs.

 

There's nothing about UUIDs that makes them non-readable or impossible to manipulate using your brain and a text editor, just like the old hd*/sd*.

Link to comment
Share on other sites

...with UUID, there are definitely pluses and minuses involved in using that system. UUID is pretty much standard...

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...

 

Re lilo vs grub. I was a lilo guy from way back and always preferred lilo to grub basically because I knew lilo...

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.

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...