10:54 a.m.
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
11:11 a.m.
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
11:43 a.m.
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 ...
--
Gene
11:55 a.m.
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
12:21 p.m.
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).
--
Gene
2:45 p.m.
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
9:29 a.m.
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
6:50 a.m.
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-
7:34 a.m.
New subject: Drive labels (was: Yet another futuristic wishlist item)
On Fri, 19 Dec 2003 13:50:10 +0100
Thomas Hille <thomas.hille(a)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
7:51 a.m.
New subject: Drive labels (was: Yet another futuristic wishlist item)
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(a)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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
1:31 p.m.
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
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
2:24 p.m.
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
4:31 p.m.
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
6:06 p.m.
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
4:28 p.m.
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
7485
days inactive
7488
days old
14 comments
11 participants
participants (11)
-
Behdad Esfahbod -
Chris Ricker -
Gene C. -
Greg KH -
Jef Spaleta -
Jeremy Katz -
Miloslav Trmač -
Philip Balister -
Sean Estabrooks -
Thomas Hille -
Wil Cooley