Imagine if you will...a vision of tomorrow..where the rescue mode on the cd offered not just a commandline, but a graphical environment that offered users an indexed troubleshooting guide to help them through common rescue mode scenarios like reinstall grub into mbr and fixing partition labels problems when trying to run a multiple fedora/redhat boot system and multiple partitions have the same label string.
-jef"or maybe this 102F fever is making me hallucinate"spaleta
On Wed, 2003-12-17 at 11:54, Jef Spaleta wrote:
Imagine if you will...a vision of tomorrow..where the rescue mode on the cd offered not just a commandline, but a graphical environment that offered users an indexed troubleshooting guide to help them through common rescue mode scenarios like reinstall grub into mbr and fixing partition labels problems when trying to run a multiple fedora/redhat boot system and multiple partitions have the same label string.
This isn't unreasonable, but it's a fair bit of work. It's been on the long list of "someday" features for quite a while now :/
Jeremy
On Wednesday 17 December 2003 12:11, Jeremy Katz wrote:
On Wed, 2003-12-17 at 11:54, Jef Spaleta wrote:
Imagine if you will...a vision of tomorrow..where the rescue mode on the cd offered not just a commandline, but a graphical environment that offered users an indexed troubleshooting guide to help them through common rescue mode scenarios like reinstall grub into mbr and fixing partition labels problems when trying to run a multiple fedora/redhat boot system and multiple partitions have the same label string.
This isn't unreasonable, but it's a fair bit of work. It's been on the long list of "someday" features for quite a while now :/
I would think that this should almost be a separate endevor (perhaps handled outside of Red Hat by community developers). To some extent this sounds a bit like the rescue cd which was part of earlier Red Hat Linux or KNOPPIX or BBC or ...
On Wed, 2003-12-17 at 12:43, Gene C. wrote:
I would think that this should almost be a separate endevor (perhaps handled outside of Red Hat by community developers). To some extent this sounds a bit like the rescue cd which was part of earlier Red Hat Linux or KNOPPIX or BBC or ...
And reproduce all of the hardware and root detection that's already in anaconda? There's a reason why the rescue CD was moved to be anaconda's rescue mode... having it as completely separate just means that it never gets looked at and has odd weird brokenness.
Jeremy
On Wednesday 17 December 2003 12:55, Jeremy Katz wrote:
On Wed, 2003-12-17 at 12:43, Gene C. wrote:
I would think that this should almost be a separate endevor (perhaps handled outside of Red Hat by community developers). To some extent this sounds a bit like the rescue cd which was part of earlier Red Hat Linux or KNOPPIX or BBC or ...
And reproduce all of the hardware and root detection that's already in anaconda? There's a reason why the rescue CD was moved to be anaconda's rescue mode... having it as completely separate just means that it never gets looked at and has odd weird brokenness.
I had not thought of that aspect. But, maybe it can still be something that "others" do ... like the current effort to create FC1-x86_64 (or are those really Red Hat contractors/consultants).
Can't we change the default partition labels from "/", "/home", ... to something like "mces:/", "mces:/home", ... where "mces" is the machine name? It would reduce the glitch when connecting two hard disks both with FC installed to a single machine.
behdad
On Wed, 17 Dec 2003, Jef Spaleta wrote:
Imagine if you will...a vision of tomorrow..where the rescue mode on the cd offered not just a commandline, but a graphical environment that offered users an indexed troubleshooting guide to help them through common rescue mode scenarios like reinstall grub into mbr and fixing partition labels problems when trying to run a multiple fedora/redhat boot system and multiple partitions have the same label string.
-jef"or maybe this 102F fever is making me hallucinate"spaleta
On Wed, Dec 17, 2003 at 03:45:56PM -0500, Behdad Esfahbod wrote:
Can't we change the default partition labels from "/", "/home", ... to something like "mces:/", "mces:/home", ... where "mces" is the machine name? It would reduce the glitch when connecting two hard disks both with FC installed to a single machine.
We have only 16 characters in the label. That can be tight even without the hostname. Mirek
Am Do, den 18.12.2003 schrieb Miloslav Trmac um 16:29:
On Wed, Dec 17, 2003 at 03:45:56PM -0500, Behdad Esfahbod wrote:
Can't we change the default partition labels from "/", "/home", ... to something like "mces:/", "mces:/home", ... where "mces" is the machine name? It would reduce the glitch when connecting two hard disks both with FC installed to a single machine.
We have only 16 characters in the label. That can be tight even without the hostname. Mirek
Nevertheless this is an issue. Some days ago I installed the hd of another pc into my own. But fc mounts the last "/" partition it finds - ie on the highest drive. That is obviously always the wrong in the case when there are two. The only way to avoid mounting the wrong partition was to remove all that labeling stuff and use plain /dev/hda1 style entries in the fstab.
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
-Thomas-
On Fri, 19 Dec 2003 13:50:10 +0100 Thomas Hille thomas.hille@nightsabers.org wrote:
Nevertheless this is an issue. Some days ago I installed the hd of another pc into my own. But fc mounts the last "/" partition it finds - ie on the highest drive. That is obviously always the wrong in the case when there are two. The only way to avoid mounting the wrong partition was to remove all that labeling stuff and use plain /dev/hda1 style entries in the fstab.
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
Hi Thomas,
The problem is sticking with only the default labels. Making your own label names will stop conflicts like this. Different drive, different label. In anticipation of adding the second drive into your machine you could have relabelled one of the drives.
Labels are rather handy to have when you swap drives between machines in keeping everything straight and having drives mounted properly easily.
$0.02 Sean
Labels are fine. I had a run in with them the other day and figured out what to do pretty easily (with some help from #fedora). Next time I will be better prepared.
Although I think the installer should be aware of the case where the primary disk (with old install) is moved to the secondary and a new disk is added. Then install on new disk. I had "weird" problems until I disconnected the second disk. I put something in bugzilla, but the system is going now, and I don't feel like trying to figure out how to report the problem because that would mean busting everything again.
Philip
On Fri, Dec 19, 2003 at 08:34:39AM -0500, Sean Estabrooks wrote:
On Fri, 19 Dec 2003 13:50:10 +0100 Thomas Hille thomas.hille@nightsabers.org wrote:
Nevertheless this is an issue. Some days ago I installed the hd of another pc into my own. But fc mounts the last "/" partition it finds - ie on the highest drive. That is obviously always the wrong in the case when there are two. The only way to avoid mounting the wrong partition was to remove all that labeling stuff and use plain /dev/hda1 style entries in the fstab.
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
Hi Thomas,
The problem is sticking with only the default labels. Making your own label names will stop conflicts like this. Different drive, different label. In anticipation of adding the second drive into your machine you could have relabelled one of the drives.
Labels are rather handy to have when you swap drives between machines in keeping everything straight and having drives mounted properly easily.
$0.02 Sean
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2003-12-19 at 04:50, Thomas Hille wrote:
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
Already possible. Every filesystem has a UUID (universally unique identifier) which is a big ugly random hex string. You can mount based on the UUID by putting 'UUID=xxx' in the first column of the fstab file.
Personally, I prefer the label for human-friendliness, but if you're going to be moving drives around between systems, you should probably make a switch to UUIDs part of your preparations.
Wil
On Fri, 19 Dec 2003, Wil Cooley wrote:
On Fri, 2003-12-19 at 04:50, Thomas Hille wrote:
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
Already possible. Every filesystem has a UUID (universally unique identifier) which is a big ugly random hex string. You can mount based on the UUID by putting 'UUID=xxx' in the first column of the fstab file.
Personally, I prefer the label for human-friendliness, but if you're going to be moving drives around between systems, you should probably make a switch to UUIDs part of your preparations.
you could use devlabel, and get the best of both approaches.
later, chris
On Fri, 2003-12-19 at 15:24 -0500, Chris Ricker wrote:
you could use devlabel, and get the best of both approaches.
We're looking at using udev with 2.6, but I think I would still prefer to use labels on the filesystem for device mounting in general. For one thing, mounting root via label instead of via device name means I don't have to redo the fun root= parsing for "odd" devices :)
Cheers,
Jeremy
On Fri, Dec 19, 2003 at 05:31:01PM -0500, Jeremy Katz wrote:
On Fri, 2003-12-19 at 15:24 -0500, Chris Ricker wrote:
you could use devlabel, and get the best of both approaches.
We're looking at using udev with 2.6, but I think I would still prefer to use labels on the filesystem for device mounting in general. For one thing, mounting root via label instead of via device name means I don't have to redo the fun root= parsing for "odd" devices :)
udev can handle labels on filesystems. It can just callout to a separate program to read the label, and then udev will match on it.
Hm, need to dig up that program that reads labels and add it to the udev tree someday soon...
thanks,
greg k-h
On Fri, 2003-12-19 at 13:50 +0100, Thomas Hille wrote:
Maybe we should drop using labels at all? To be honest I don't know what they are good for anyway. Or instead of using the hostname use a random number? Other suggestions maybe?
Labels allow your disks to change naming without requiring changes to your fstab, etc. This is really handy on boxes with lots of SCSI devices, less so if you're just using IDE.
Alternatively to labels, there are also UUIDs for most filesystems. But I'd rather have "LABEL=/" in my fstab than "UUID=c96d9cfa-f2fd-49d2- b6e6-c70f2885bab9" :-)
That said, there is the potential to do some things to help the cases where duplicate labels exist, both in anaconda and in the rest of userspace.
Cheers,
Jeremy