| Summary: | 2007.0 GUI installer uses labels in fstab but doesn't set them on disk | ||
|---|---|---|---|
| Product: | Gentoo Release Media | Reporter: | Jack <ostroffjh> |
| Component: | Installer | Assignee: | Gentoo Linux Installer <gli-bugs> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | dhp_gentoo, marklinux, ostroffjh |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jack
2007-09-18 23:49:41 UTC
One of the reasons it needs to do this is because of the kernel that the user selects. When you are using the live cd, you are using THAT kernel.... say 2.6.13. Now, on 2.6.13 if it detects my SATA hard drive as /dev/hda1, thats because its not using the right chipset for my drive. When I go to install a new kernel for my local system and configure it, im going to use the new chipset and my new drive is going to be detected and boot as /dev/sda1. This is why gentoo will always leave it as /dev/ROOT and so on, and expect the user to change it themselves depending upon how their system is set up and how they configure and compile the kernel. I believe it is more efficient this way, and solves a lot of confusion as well. I'd Close the bug. -MKT *** Bug 193002 has been marked as a duplicate of this bug. *** I'm not sure that fully makes sense. I can understand there would be a different confusion if it uses /dev/hda1 and on reboot it would need /dev/sda1, but by using /dev/ROOT it guarantees to fail on reboot unless it actually sets the label. If nothing else, it should at least be more explicit about warning the user, and giving instructions on how to change it either before the reboot or on how to remount after the reboot. I suppose this could be called a documentation bug rather than a bug in the installer, but folks who try the GUI installer probably don't read the complete handbook (and while they may get what they deserve for not doing so - it doesn't help Gentoo's reputation.) some initrd scripts also automatically set a symlink in /dev to ROOT from ${realroot} (from memory). So, if initrd is set up according to tutos, /dev/ROOT should exist in most systems. *should*. (not even the case for me).
Read about initrd, pivotroot, or google for ${ROOT} and ${REALROOT} or ${REAL_ROOT} .
So, no /dev/ROOT is not guarantied to fail at all; from initrd tutos, it's in fact nearly warantied to work ! See how Debian manages initrd on RAID/LVM machines; they have very cute scripts.
Assuming labels would be in fact the most stupid thing: imagine I install gentoo twince on the same disk, different partitions, or even worse: I got a working Gentoo, and clod-plug a disk with an other Gentoo also using labelled ROOT ... how the hell can I be sure /dev/ROOT set by labels will point to the right partition, slice, or disk ???
Install Gentoo on 3 computers, put all 3 disks in the same machine, and guess what your /dev/disk/by-label/ would look like ... now, you understand why autolabelling is a bad idea, and why initrd sets /dev/ROOT according to the root= kernel argument, preferably over the partition labelled with this name.
That's fine - but the GUI installer does not do any of those things. If initrd actually did the right thing, that would be great. I agree that labels aren't the best answer, although an installer could check if there are already any labels and use ROOT1 (I think that's what Fedrda does or did in a previous version). If the user moves a disk into a different machine, he should know enough that fstab probably has to be changed - and probably the grub or lilo menu also. My only point is that right now, the installer uses ROOT in fstab, and doesn't do anything to make sure that it will work on boot. At minimum, it should warn the user so it isn't a surprise. The installer writes its own /etc/fstab, so the /dev/ROOT and similar entries in the default /etc/fstab should not be left. Please reopen if you can provide more information about how this happened. Are you saying that what I had was the default /etc/fstab, and that had the installer completed successfully, it would have done something different? The problem with that is that the entries matched the disks I have, so they didn't look generic enough to be default, unless the "default" is at least a bit customized. Perhaps the main issue is that the install did not run fully to completion. It was close enough that I chose to complete the remaining steps manually, but initially got tripped up on this one. So - the steps to repeat are to have the install fail close to the end, such as on one of the last emerges - probably of a non-critical package. I would find any of the following four options an acceptable solution 1) use /dev/hda1 instead of /dev/ROOT - but I realize this may actually not be a good choice based on the comment from Mark Tuttle. 2) actually put the /dev/ROOT labels on the disk - but this would be restricted to those filesystem types that have labels. 3) create the symlinks in /dev mentioned by DoubleHP 4) change the documentation to make the problem more obvious. This might include adding a comment just before or after the partitioning step. I suspect that 4 might be the most realistic, whether or not actually the best. I'm going to leave status unchanged for now, but hopefully it would be reasonable to reopen and consider it a documentation bug? option 2 would also fail when you boot with 2 Gentoo disks, or worse, try to install 2 Gentoos on the same disk. 3 is quiet trivial to implement. It should not expect ramdisk. Using /dev/ROOT as link to the argument passed to the kernel will also fail on very complex systems where people use pivotroot to manage complex RAID/LVM or net-boot (where the / is on the network), but, it should be safe for 99% newbies people. The last 1% doing complex things is expected to have knowledge and time to take care of fstab on their own. 4 is of course the easiest way to fix, and also the most universal one :) A simple new paragraph in the doc costs nothing, and fixes everything. Andrew, I can not bring more info since I did not reinstall Gentoo since 2005. Except once when I did it all closed eyes, by heart, and fixed my fstab before it could cause me any trouble, because I had no time to loose on reproducing this bug. To reproduce, I would need several days, and perform 4 installs on the same disk, two CLI, plus two GUI to make sure ... |
