10:03 a.m.
In the latest Linux Journal in the etc/rant column the author makes an
interesting suggestion that I think the Fedora people should consider.
He points out the problem of associating entries in the fstab file with
a LABEL-/. If one runs more than one Linux version more than one
partition might have this label.
I would like to make the suggestion that the Default Label be more
descriptive. The author suggests something like FC%32ROOT.
Where would be the correct list to send such a suggestion?
The fedora-developers-list maybe.
--
Aaron Konstam <akonstam(a)sbcglobal.net>
10:40 a.m.
On Fri, 2006-05-05 at 10:03 -0500, Aaron Konstam wrote:
In the latest Linux Journal in the etc/rant column the author makes
an
interesting suggestion that I think the Fedora people should consider.
He points out the problem of associating entries in the fstab file with
a LABEL-/. If one runs more than one Linux version more than one
partition might have this label.
I would like to make the suggestion that the Default Label be more
descriptive. The author suggests something like FC%32ROOT.
Where would be the correct list to send such a suggestion?
The fedora-developers-list maybe.
It should be noted that this is only a problem when you move disks from
one system to another.
When you already have disks with those labels, anaconda sees them - and
does not use them.
I will pick up the latest Linux Journal and see what the article says -
but to be honest, it sounds like he is ranting without even having tried
it.
If I recall, anaconda allows you to specify the label as well. At least
I think it use to. Using the mount point for the label only happens by
default when another partition does not already have that label.
3:31 p.m.
On Fri, 2006-05-05 at 08:40 -0700, Michael A. Peters wrote:
On Fri, 2006-05-05 at 10:03 -0500, Aaron Konstam wrote:
> In the latest Linux Journal in the etc/rant column the author makes an
> interesting suggestion that I think the Fedora people should consider.
> He points out the problem of associating entries in the fstab file with
> a LABEL-/. If one runs more than one Linux version more than one
> partition might have this label.
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
>
> Where would be the correct list to send such a suggestion?
> The fedora-developers-list maybe.
It should be noted that this is only a problem when you move disks from
one system to another.
Of course people do that. Move disk that is.
When you already have disks with those labels, anaconda sees them - and
does not use them.
I am not sure I believe that but I cna't prove it.
I will pick up the latest Linux Journal and see what the article says -
but to be honest, it sounds like he is ranting without even having tried
it.
If I recall, anaconda allows you to specify the label as well. At least
I think it use to. Using the mount point for the label only happens by
default when another partition does not already have that label.
I can't remeber that hte label can be specified separate from the mount
point. But maybe it can be in FC5. I will be installing FC5 again next
week so I will check that.
BUt I wasn't trying to start an argument . I just asked on what list
coulod this question be raised. If it shot down it will be shot down.
--
=======================================================================
There is a natural hootchy-kootchy to a goldfish. -- Walt Disney
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
3:39 p.m.
On Fri, 2006-05-05 at 15:31, Aaron Konstam wrote:
>
> If I recall, anaconda allows you to specify the label as well. At least
> I think it use to. Using the mount point for the label only happens by
> default when another partition does not already have that label.
>
I can't remeber that hte label can be specified separate from the mount
point. But maybe it can be in FC5. I will be installing FC5 again next
week so I will check that.
BUt I wasn't trying to start an argument . I just asked on what list
coulod this question be raised. If it shot down it will be shot down.
Another bug that I thought was supposed to be fixed but still seems
to be there is that if you try to set up raid partitions
manually in disk druid they are re-arranged before being
created. I always like to make raid1 partitions for
/boot swap and / in that order on the 1st 2 drives and
have had to use fdisk to create them so the positions stick.
I didn't have much time on the only RAID FC5 I've done so
far and when it looked like it was going to re-order to / swap /boot
I went back and used fdisk. Has anyone else seen this?
Then the other annoying thing was that after fdisk'ing the
first drive I couldn't use the 'clone partition' option to
duplicate to the 2nd drive. I got some kind of error message
about 'partition is not constrained to one drive', which of
course isn't really possible.
--
Les Mikesell
lesmikesell(a)gmail.com
11:12 p.m.
On Fri, 2006-05-05 at 15:31 -0500, Aaron Konstam wrote:
>
> It should be noted that this is only a problem when you move disks from
> one system to another.
Of course people do that. Move disk that is.
Interestingly - I have a disk that has a partition with LABEL=/ and it
isn't a problem when attached via USB after a system with LABEL=/ has
booted.
It's only a problem when fstab is mounting a mount point with the
specified label - IE the disk is there when the system boots.
The fix in that case is to edit /etc/fstab and change LABEL=/
to /dev/whatever (you should be able to boot into maintenance mode to do
that)
>
> When you already have disks with those labels, anaconda sees them - and
> does not use them.
I am not sure I believe that but I cna't prove it.
One of my system always has at least two installs - FC4 and devel, and
sometimes an additional.
root on the second is LABEL=/2 or something like that.
Well, now I use LVM which does things a little differently, but it too
detects existing volume groups and their name.
But yes - anaconda reads disk labels that exist, and if a disk label
exists that it wants to use for creating a partition - it uses a
different label.
>
I can't remeber that hte label can be specified separate from the mount
point. But maybe it can be in FC5. I will be installing FC5 again next
week so I will check that.
I'm pretty sure it can in the manual partitioning mode.
Almost positive it can.
11:16 a.m.
On Fri, 2006-05-05 at 10:03, Aaron Konstam wrote:
In the latest Linux Journal in the etc/rant column the author makes
an
interesting suggestion that I think the Fedora people should consider.
He points out the problem of associating entries in the fstab file with
a LABEL-/. If one runs more than one Linux version more than one
partition might have this label.
Or if you have more than one machine and ever move disks around...
I would like to make the suggestion that the Default Label be more
descriptive. The author suggests something like FC%32ROOT.
What does that mean and how does it make it unique? If you are
going to change it, make it work for people who have dozens/hundreds
of machines with swappable drives. As it is, you can't even
boot a machine that has duplicate labeled disks to get to a
point where you can fix it.
--
Les Mikesell
lesmikesell(a)gmail.com
11:25 a.m.
On 5/5/06, Aaron Konstam <akonstam(a)sbcglobal.net> wrote:
In the latest Linux Journal in the etc/rant column the author makes
an
interesting suggestion that I think the Fedora people should consider.
He points out the problem of associating entries in the fstab file with
a LABEL-/. If one runs more than one Linux version more than one
partition might have this label.
I would like to make the suggestion that the Default Label be more
descriptive. The author suggests something like FC%32ROOT.
I question if this necessary. You can have entries in fstab with or
without labels. I've had 3 single Fedora installations on single drive
across multiple partitions and never have run into a problem in the
installer or usage nor have I had to manually edit fstab for this. I
think in Anaconda the labels will start shifting to /1, /2, /home1
etc. Since at runtime you don't deal with partition labels, just their
mount points, it really is not a serious concern.
Just my opinion.
-Mauriat
1 p.m.
On 5/5/06, Mauriat Miranda <mirandam(a)gmail.com> wrote:
On 5/5/06, Aaron Konstam <akonstam(a)sbcglobal.net> wrote:
> In the latest Linux Journal in the etc/rant column the author makes an
> interesting suggestion that I think the Fedora people should consider.
> He points out the problem of associating entries in the fstab file with
> a LABEL-/. If one runs more than one Linux version more than one
> partition might have this label.
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
I question if this necessary. You can have entries in fstab with or
without labels. I've had 3 single Fedora installations on single drive
across multiple partitions and never have run into a problem in the
installer or usage nor have I had to manually edit fstab for this. I
think in Anaconda the labels will start shifting to /1, /2, /home1
etc. Since at runtime you don't deal with partition labels, just their
mount points, it really is not a serious concern.
Just my opinion.
-Mauriat
Your horizon is too narrow, i.e. Fedora centric. Try installing other
distros on your system to appreciate the problem.
1:49 p.m.
On 5/5/06, Kam Leo <kam.leo(a)gmail.com> wrote:
>
> I question if this necessary. You can have entries in fstab with or
> without labels. I've had 3 single Fedora installations on single drive
> across multiple partitions and never have run into a problem in the
> installer or usage nor have I had to manually edit fstab for this. I
> think in Anaconda the labels will start shifting to /1, /2, /home1
> etc. Since at runtime you don't deal with partition labels, just their
> mount points, it really is not a serious concern.
Your horizon is too narrow, i.e. Fedora centric. Try installing other
distros on your system to appreciate the problem.
You assume too much. That was one example of many configurations I've
tried. I've had Gentoo, Fedora, Suse and Slackware mixes.
-Mauriat
1:04 p.m.
On Fri, 2006-05-05 at 11:25, Mauriat Miranda wrote:
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
I question if this necessary. You can have entries in fstab with or
without labels. I've had 3 single Fedora installations on single drive
across multiple partitions and never have run into a problem in the
installer or usage nor have I had to manually edit fstab for this. I
think in Anaconda the labels will start shifting to /1, /2, /home1
etc. Since at runtime you don't deal with partition labels, just their
mount points, it really is not a serious concern.
Assume you are in the IT dept for some group and you are used
to being able to re-use disks in different machines and to
recover data from any disk by installing/mounting in any working
machine. Now you find that any combination of disks from
default fedora/RH/Centos installs won't boot... It is a
problem.
--
Les Mikesell
lesmikesell(a)gmail.com
1:56 p.m.
On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> I question if this necessary. You can have entries in fstab with
or
> without labels. I've had 3 single Fedora installations on single drive
> across multiple partitions and never have run into a problem in the
> installer or usage nor have I had to manually edit fstab for this. I
> think in Anaconda the labels will start shifting to /1, /2, /home1
> etc. Since at runtime you don't deal with partition labels, just their
> mount points, it really is not a serious concern.
Assume you are in the IT dept for some group and you are used
to being able to re-use disks in different machines and to
recover data from any disk by installing/mounting in any working
machine. Now you find that any combination of disks from
default fedora/RH/Centos installs won't boot... It is a
problem.
So you boot with a LiveCD or some Rescue disk/media and fix it - use
the device ID or relabel it. Isn't that the way to fix it? I don't
understand the problem. Your assumed scenario is too vague.
-Mauriat
2:14 p.m.
One command man:
e2label /dev/hd# <new label>
I understand your problem, had a similar one in fact when installed FC5 on
to of WinXP but wanted
to keep the old FC4 partition for data storage. It showed as '/' while the
original root showed as /1.
e2label will fix this for you! But remember to edit /boot/grub/grub.conf and
change the kernel arguments
as well! :-)
Filippos
On 5/5/06, Mauriat Miranda <mirandam(a)gmail.com> wrote:
On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> > I question if this necessary. You can have entries in fstab with or
> > without labels. I've had 3 single Fedora installations on single drive
> > across multiple partitions and never have run into a problem in the
> > installer or usage nor have I had to manually edit fstab for this. I
> > think in Anaconda the labels will start shifting to /1, /2, /home1
> > etc. Since at runtime you don't deal with partition labels, just their
> > mount points, it really is not a serious concern.
>
> Assume you are in the IT dept for some group and you are used
> to being able to re-use disks in different machines and to
> recover data from any disk by installing/mounting in any working
> machine. Now you find that any combination of disks from
> default fedora/RH/Centos installs won't boot... It is a
> problem.
So you boot with a LiveCD or some Rescue disk/media and fix it - use
the device ID or relabel it. Isn't that the way to fix it? I don't
understand the problem. Your assumed scenario is too vague.
-Mauriat
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
2:36 p.m.
On Fri, 2006-05-05 at 14:14, Filippos Klironomos wrote:
One command man:
e2label /dev/hd# <new label>
I understand your problem, had a similar one in fact when installed
FC5 on to of WinXP but wanted
to keep the old FC4 partition for data storage. It showed as '/' while
the original root showed as /1.
e2label will fix this for you! But remember to edit
/boot/grub/grub.conf and change the kernel arguments
as well! :-)
Note that the machine won't boot to allow you to do this
command... You have to dig out some kind of rescue boot
media. And apparently this was someone's idea of making
things easier.
--
Les Mikesell
lesmikesell(a)gmail.com
11:27 p.m.
On Fri, 2006-05-05 at 14:36 -0500, Les Mikesell wrote:
On Fri, 2006-05-05 at 14:14, Filippos Klironomos wrote:
> One command man:
>
> e2label /dev/hd# <new label>
>
> I understand your problem, had a similar one in fact when installed
> FC5 on to of WinXP but wanted
> to keep the old FC4 partition for data storage. It showed as '/' while
> the original root showed as /1.
>
> e2label will fix this for you! But remember to edit
> /boot/grub/grub.conf and change the kernel arguments
> as well! :-)
Note that the machine won't boot to allow you to do this
command... You have to dig out some kind of rescue boot
media. And apparently this was someone's idea of making
things easier.
Oh come on.
This happened to me when I was a n00b.
I figured out rather quickly that all I had to do was:
a) power off
b) disconnect the IDE cable to the added drive causing the conflict
c) boot
d) edit /etc/fstab - use /dev/hdan instead of LABEL=/ and LABEL=/home
e) shutdown
f) reconnect cable
g) boot
You don't need to dig up rescue media or anything silly like that.
If this is something you want to be able to do - then it is user error
to use the same LABEL on multiple systems.
But really - just put the drive in a USB2 case, attach it, and recover
away. There is no LABEL problem then. That's safer than opening up your
good box anyway.
Sorry if I'm a tad grumpy.
I'm off to see if they have the current Linux Journal at the local
supermarket (yes, they carry it).
2:29 p.m.
On Fri, 2006-05-05 at 13:56, Mauriat Miranda wrote:
> > I question if this necessary. You can have entries in fstab
with or
> > without labels. I've had 3 single Fedora installations on single drive
> > across multiple partitions and never have run into a problem in the
> > installer or usage nor have I had to manually edit fstab for this. I
> > think in Anaconda the labels will start shifting to /1, /2, /home1
> > etc. Since at runtime you don't deal with partition labels, just their
> > mount points, it really is not a serious concern.
>
> Assume you are in the IT dept for some group and you are used
> to being able to re-use disks in different machines and to
> recover data from any disk by installing/mounting in any working
> machine. Now you find that any combination of disks from
> default fedora/RH/Centos installs won't boot... It is a
> problem.
So you boot with a LiveCD or some Rescue disk/media and fix it - use
the device ID or relabel it. Isn't that the way to fix it? I don't
understand the problem. Your assumed scenario is too vague.
My assumed scenario is that you move two disks with fedora
already installed into the same machine for any number of
reasons. I move disks around all the time so the situation
is not at all unusual. But if you need help imagining why
this would happen, assume that one of the computers breaks and
you want to salvage the contents of the disk by adding it
to your own PC. Or you just want to re-format and re-use the
disk as an added filesystem.
Yes, you can work around the problem with quite a lot of
extra trouble, assuming you understand what the problem
is in the first place. Now remind me why I want to have
this extra trouble in the first place. Why should a machine
refuse to boot just because you add an extra drive?
--
Les Mikesell
lesmikesell(a)gmail.com
3:11 p.m.
On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
My assumed scenario is that you move two disks with fedora
already installed into the same machine for any number of
reasons. I move disks around all the time so the situation
is not at all unusual. But if you need help imagining why
this would happen, assume that one of the computers breaks and
you want to salvage the contents of the disk by adding it
to your own PC. Or you just want to re-format and re-use the
disk as an added filesystem.
Yes, you can work around the problem with quite a lot of
extra trouble, assuming you understand what the problem
is in the first place. Now remind me why I want to have
this extra trouble in the first place. Why should a machine
refuse to boot just because you add an extra drive?
I see now, 2 drives at the same time is key point. I agree with your
point, booting should be possible. Curious: why not just make the grub
configuration use device ID's instead of labels?
-Mauriat
3:23 p.m.
On Fri, 2006-05-05 at 15:11, Mauriat Miranda wrote:
> Yes, you can work around the problem with quite a lot of
> extra trouble, assuming you understand what the problem
> is in the first place. Now remind me why I want to have
> this extra trouble in the first place. Why should a machine
> refuse to boot just because you add an extra drive?
I see now, 2 drives at the same time is key point. I agree with your
point, booting should be possible. Curious: why not just make the grub
configuration use device ID's instead of labels?
The problem that labels were supposed to fix is that scsi drives
are named in the order that they are detected. If you add or
remove drives, or one fails, all the ones with higher ID's change
names and if you add a controller that is detected before your old
one they can all change. Labels sort-of fix this if you only
have one installation on one machine and never swap parts (but
then you didn't have much of a problem in the first place). The
real solution is that if you are going to use labels they should
be unique to the installation. Or, scsi devices could be named
so they are identified by their controller/ID/LUN instead of
detection order.
--
Les Mikesell
lesmikesell(a)gmail.com
3:36 p.m.
On Fri, 2006-05-05 at 16:11 -0400, Mauriat Miranda wrote:
On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> My assumed scenario is that you move two disks with fedora
> already installed into the same machine for any number of
> reasons. I move disks around all the time so the situation
> is not at all unusual. But if you need help imagining why
> this would happen, assume that one of the computers breaks and
> you want to salvage the contents of the disk by adding it
> to your own PC. Or you just want to re-format and re-use the
> disk as an added filesystem.
>
> Yes, you can work around the problem with quite a lot of
> extra trouble, assuming you understand what the problem
> is in the first place. Now remind me why I want to have
> this extra trouble in the first place. Why should a machine
> refuse to boot just because you add an extra drive?
I see now, 2 drives at the same time is key point. I agree with your
point, booting should be possible. Curious: why not just make the grub
configuration use device ID's instead of labels?
-Mauriat
That is naother one of the suggestions of the author in the LJ article.
--
=======================================================================
1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
11:19 p.m.
On Fri, 2006-05-05 at 16:11 -0400, Mauriat Miranda wrote:
I see now, 2 drives at the same time is key point. I agree with your
point, booting should be possible. Curious: why not just make the grub
configuration use device ID's instead of labels?
Because they can change.
Move the disks around etc. and the /dev node may not be the same
anymore.
3:34 p.m.
On Fri, 2006-05-05 at 14:56 -0400, Mauriat Miranda wrote:
On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> > I question if this necessary. You can have entries in fstab with or
> > without labels. I've had 3 single Fedora installations on single drive
> > across multiple partitions and never have run into a problem in the
> > installer or usage nor have I had to manually edit fstab for this. I
> > think in Anaconda the labels will start shifting to /1, /2, /home1
> > etc. Since at runtime you don't deal with partition labels, just their
> > mount points, it really is not a serious concern.
>
> Assume you are in the IT dept for some group and you are used
> to being able to re-use disks in different machines and to
> recover data from any disk by installing/mounting in any working
> machine. Now you find that any combination of disks from
> default fedora/RH/Centos installs won't boot... It is a
> problem.
So you boot with a LiveCD or some Rescue disk/media and fix it - use
the device ID or relabel it. Isn't that the way to fix it? I don't
understand the problem. Your assumed scenario is too vague.
-Mauriat
We are tying to produce a distribution, are we not, that the uninitiated
can install and it will just work. A lot of things can be fixed but we
want to avoid that.
--
Aaron Konstam <akonstam(a)sbcglobal.net>
4:17 p.m.
On Fri, 2006-05-05 at 15:34 -0500, Aaron Konstam wrote:
On Fri, 2006-05-05 at 14:56 -0400, Mauriat Miranda wrote:
> On 5/5/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> > > I question if this necessary. You can have entries in fstab with or
> > > without labels. I've had 3 single Fedora installations on single
drive
> > > across multiple partitions and never have run into a problem in the
> > > installer or usage nor have I had to manually edit fstab for this. I
> > > think in Anaconda the labels will start shifting to /1, /2, /home1
> > > etc. Since at runtime you don't deal with partition labels, just
their
> > > mount points, it really is not a serious concern.
> >
> > Assume you are in the IT dept for some group and you are used
> > to being able to re-use disks in different machines and to
> > recover data from any disk by installing/mounting in any working
> > machine. Now you find that any combination of disks from
> > default fedora/RH/Centos installs won't boot... It is a
> > problem.
>
> So you boot with a LiveCD or some Rescue disk/media and fix it - use
> the device ID or relabel it. Isn't that the way to fix it? I don't
> understand the problem. Your assumed scenario is too vague.
>
> -Mauriat
We are tying to produce a distribution, are we not, that the uninitiated
can install and it will just work. A lot of things can be fixed but we
want to avoid that.
The uninitiated will not likely be moving drives between machines. They
would do an install on already existing drives and as such the Fedora
install/labeling scheme works well. The conflicts occur when previously
labeled drives are mixed in a machine as mentioned above.
I agree that it needs to be more capable of recovering but the problem
conditions do not appear to be with the new/uninitiated but rather with
the users who are moving hardware between machines after the
installation has completed for whatever reason.
Some OSes write a PVID on the physical device that is unique (similar to
the way identifiers on LVM logical volumes and volume groups are
unique). This may be a better way since a unique identifier of this
sort (physical volume plus logical volume/partition) is guaranteed to
not conflict the way the current labels do.
5:03 p.m.
On Fri, 2006-05-05 at 16:17, Jeff Vian wrote:
The uninitiated will not likely be moving drives between machines.
They
would do an install on already existing drives and as such the Fedora
install/labeling scheme works well.
So the idea is to stay uninitiated forever?
The conflicts occur when previously
labeled drives are mixed in a machine as mentioned above.
Note that the prior scheme of using partition names did not
have any problems unless you moved them either and then they
were predictable according to drive positions. With this
scheme the problem depends on the disk contents that you aren't
likely to know ahead of time.
Some OSes write a PVID on the physical device that is unique (similar
to
the way identifiers on LVM logical volumes and volume groups are
unique). This may be a better way since a unique identifier of this
sort (physical volume plus logical volume/partition) is guaranteed to
not conflict the way the current labels do.
If someone is going to re-think this, they should also come up
with a scheme that works when you do a backup and restore to
a different machine. There are so many things you have to fix
by hand (grub, fstab, the NIC hardware addresses) when you
copy a working machine that I'd be surprised if anyone is rolling
them out in any volume.
--
Les Mikesell
lesmikesell(a)gmail.com
6:17 p.m.
On Fri, 2006-05-05 at 17:03 -0500, Les Mikesell wrote:
On Fri, 2006-05-05 at 16:17, Jeff Vian wrote:
> The uninitiated will not likely be moving drives between machines. They
> would do an install on already existing drives and as such the Fedora
> install/labeling scheme works well.
So the idea is to stay uninitiated forever?
No, they move to the next category, as expected.
> The conflicts occur when previously
> labeled drives are mixed in a machine as mentioned above.
Note that the prior scheme of using partition names did not
have any problems unless you moved them either and then they
were predictable according to drive positions. With this
scheme the problem depends on the disk contents that you aren't
likely to know ahead of time.
You can easily fall back to that method, and I am sure many of us do
when we encounter this problem. I surely do.
> Some OSes write a PVID on the physical device that is unique
(similar to
> the way identifiers on LVM logical volumes and volume groups are
> unique). This may be a better way since a unique identifier of this
> sort (physical volume plus logical volume/partition) is guaranteed to
> not conflict the way the current labels do.
If someone is going to re-think this, they should also come up
with a scheme that works when you do a backup and restore to
a different machine. There are so many things you have to fix
by hand (grub, fstab, the NIC hardware addresses) when you
copy a working machine that I'd be surprised if anyone is rolling
them out in any volume.
agreed.
--
Les Mikesell
lesmikesell(a)gmail.com
11:15 p.m.
On Fri, 2006-05-05 at 13:04 -0500, Les Mikesell wrote:
Assume you are in the IT dept for some group and you are used
to being able to re-use disks in different machines and to
recover data from any disk by installing/mounting in any working
machine. Now you find that any combination of disks from
default fedora/RH/Centos installs won't boot... It is a
problem.
Put it in a USB2 housing.
Then it doesn't matter - FC5 doesn't use fstab when mounting a USB disk
(well, I haven't tried connected at boot). It doesn't use the LABEL
either.
Mounts just fine - even if another disk with that LABEL exists -
allowing you to do all the recovery you want.
Yes, I've done this.
11:45 a.m.
On Fri, 2006-05-05 at 23:15, Michael A. Peters wrote:
>
> Assume you are in the IT dept for some group and you are used
> to being able to re-use disks in different machines and to
> recover data from any disk by installing/mounting in any working
> machine. Now you find that any combination of disks from
> default fedora/RH/Centos installs won't boot... It is a
> problem.
Put it in a USB2 housing.
Then it doesn't matter - FC5 doesn't use fstab when mounting a USB disk
(well, I haven't tried connected at boot). It doesn't use the LABEL
either.
Mounts just fine - even if another disk with that LABEL exists -
allowing you to do all the recovery you want.
Yes, I've done this.
Most of the ones I swap are SCA (scsi w/hot swap connector).
But, the other quirk is that I very often clone these
machines by dd'ing the entire drive, so no matter how
clever you are about creating unique labels there will
be duplicates when the raw disk is copied. What we
need are some management tools so you have standard
procedures to clone machines across linux distributions
instead of every distro re-inventing its own quirky
workaround for the scsi device naming problem and
hiding MAC addresses in obscure config files.
Unfortunately no one seems to be interested in that kind
of cooperation. If a disto does add something it wants it
to be unique to their version and a reason to use only
that version. However, I'm not interested in being married
to only one distribution so I stick to dd / tar and the
things that work everywhere and simply complain about
the way different unix flavors have always kept their
differences to the detriment of acceptance.
--
Les Mikesell
lesmikesell(a)gmail.com
1:56 p.m.
On Sat, 2006-05-06 at 11:45 -0500, Les Mikesell wrote:
Unfortunately no one seems to be interested in that kind
of cooperation.
how about LABEL=/-`date +%s`
Ugly as hell - but the user doesn't have to see that unless they look at
the label.
It has the intended mount point in the label, and precisely when the
label was created.
3:38 p.m.
On Sat, 2006-05-06 at 13:56, Michael A. Peters wrote:
On Sat, 2006-05-06 at 11:45 -0500, Les Mikesell wrote:
>
> Unfortunately no one seems to be interested in that kind
> of cooperation.
how about LABEL=/-`date +%s`
Ugly as hell - but the user doesn't have to see that unless they look at
the label.
It still doesn't work when you clone the whole disk with dd
and then try to reboot with the disk still in place - or back
again for some other reason. What it needs is a hint about
the partition name that it will use/prefer if it finds the
label in the original place even if other matching labels are
found elsewhere.
--
Les Mikesell
lesmikesell(a)gmail.com
3:56 p.m.
On Sat, 2006-05-06 at 15:38 -0500, Les Mikesell wrote:
On Sat, 2006-05-06 at 13:56, Michael A. Peters wrote:
> On Sat, 2006-05-06 at 11:45 -0500, Les Mikesell wrote:
>
> >
> > Unfortunately no one seems to be interested in that kind
> > of cooperation.
>
> how about LABEL=/-`date +%s`
>
> Ugly as hell - but the user doesn't have to see that unless they look at
> the label.
It still doesn't work when you clone the whole disk with dd
and then try to reboot with the disk still in place - or back
again for some other reason. What it needs is a hint about
the partition name that it will use/prefer if it finds the
label in the original place even if other matching labels are
found elsewhere.
Sounds like what you need is a tool that will change the label to host
specific labels. IE a shell script that will append -`hostname` to the
existing disk labels, and update /etc/fstab and /boot/grub/grub.conf
accordingly. Then you can run that shell script after setting the
hostname, and forever after that - the disk labels will be unique.
In fact - that would be useful since HAL mounts USB disks showing the
label on the desktop. IE if your hostname is enterprise :
/-enterprise
/boot-enterprise
/home-enterprise
/usr/local-enterprise
would be easily human recognizable - and hell, would be swell mount
points in /media for recovery.
cp -ar /media/home-enterprise/foo /home/
is a lot easier than trying to figure out if it
is /media/disk1 /media/disk2 etc.
I might start doing that manually - set up volume groups to have the
hostname in the Volume Group - IE
VolGrpEnterprise00
VolGrpEnterprise01
etc.
and appended to the label for non LVM - IE
/boot-enterprise
(/boot and swap are the only non LVM volumes I currently create)
6:29 p.m.
Les Mikesell wrote:
Most of the ones I swap are SCA (scsi w/hot swap connector).
But, the other quirk is that I very often clone these
machines by dd'ing the entire drive, so no matter how
clever you are about creating unique labels there will
be duplicates when the raw disk is copied. What we
need are some management tools so you have standard
procedures to clone machines across linux distributions
instead of every distro re-inventing its own quirky
workaround for the scsi device naming problem and
hiding MAC addresses in obscure config files.
Unfortunately no one seems to be interested in that kind
of cooperation. If a disto does add something it wants it
to be unique to their version and a reason to use only
that version. However, I'm not interested in being married
to only one distribution so I stick to dd / tar and the
things that work everywhere and simply complain about
the way different unix flavors have always kept their
differences to the detriment of acceptance
Les -
If you use dd, that means you have two disks in a functioning system.
After the fact why don't you re-label
the one you will moving?
Thomas
10:34 p.m.
On Sat, 2006-05-06 at 18:29, Thomas Cameron wrote:
>
> Unfortunately no one seems to be interested in that kind
> of cooperation. If a disto does add something it wants it
> to be unique to their version and a reason to use only
> that version. However, I'm not interested in being married
> to only one distribution so I stick to dd / tar and the
> things that work everywhere and simply complain about
> the way different unix flavors have always kept their
> differences to the detriment of acceptance
Les -
If you use dd, that means you have two disks in a functioning system.
After the fact why don't you re-label
the one you will moving?
Then you have to also adjust grub and /etc/fstab to match on
every box with opportunities for typos. Normally I just change
the one I'm going to use as the master to use partition names
instead of labels and then it doesn't matter whether the copy
operation is by dd'ing the whole disk or tar/cp/rsync by
filesystem. It isn't that difficult to work around, but it
seems like everyone who works with more than a few machines is
going to be surprised by this issue eventually.
--
Les Mikesell
lesmikesell(a)gmail.com
12:57 a.m.
On Sat, 2006-05-06 at 22:34 -0500, Les Mikesell wrote:
On Sat, 2006-05-06 at 18:29, Thomas Cameron wrote:
> >
> > Unfortunately no one seems to be interested in that kind
> > of cooperation. If a disto does add something it wants it
> > to be unique to their version and a reason to use only
> > that version. However, I'm not interested in being married
> > to only one distribution so I stick to dd / tar and the
> > things that work everywhere and simply complain about
> > the way different unix flavors have always kept their
> > differences to the detriment of acceptance
> Les -
>
> If you use dd, that means you have two disks in a functioning system.
> After the fact why don't you re-label
> the one you will moving?
Then you have to also adjust grub and /etc/fstab to match on
every box with opportunities for typos. Normally I just change
Scripting can handle both the labels and making grub and fstab match
without the typos causing mismatching between the different points.
the one I'm going to use as the master to use partition names
instead of labels and then it doesn't matter whether the copy
operation is by dd'ing the whole disk or tar/cp/rsync by
filesystem. It isn't that difficult to work around, but it
seems like everyone who works with more than a few machines is
going to be surprised by this issue eventually.
Part of any disk copy plan should take labeling into account in the
planning. If it does not then it is a poor sys admin who gets caught by
surprise.
Tom made the suggestion that the labels can be changed after the copy is
complete (and before the reboot) which will easily handle the conflicts
by eliminating them before you get bit.
Yes, everyone may get caught by it. So what? Everything we overcome is
a learning experience that helps us. I got hit by it once. The result?
-- I learned, and have never missed this in my planning since.
I think it is time for this long thread about a tiny molehill to
disappear (but that will happen only if the attempts to make it into a
crusade will go away).
--
Les Mikesell
lesmikesell(a)gmail.com
8:49 a.m.
I'm surprised no-one in this thread seems to share my view,
which is that the whole label= idea is a dreadful mistake,
as the occasions where it causes confusion
vastly outnumber the occasions where it could possibly help.
The only concrete example I have seen put forward
of a case where it might help
is if one has two or more SCSI disks, and one fails,
so that the others are re-named (eg /dev/sdb -> /dev/sda).
Has this ever happened to anyone?
I've been using SCSI disks for some time,
and never known one to fail
and simply be ignored by the SCSI controller.
[Incidentally, I have noticed one persistent problem
with SCSI disks, which came in with RedHat 9, IIRC.
Anaconda seems to get in a tizzy if you have 15 partitions,
ie up to /dev/sda15 .]
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
12:12 p.m.
On Sun, 2006-05-07 at 08:49, Timothy Murphy wrote:
The only concrete example I have seen put forward
of a case where it might help
is if one has two or more SCSI disks, and one fails,
so that the others are re-named (eg /dev/sdb -> /dev/sda).
Has this ever happened to anyone?
I've been using SCSI disks for some time,
and never known one to fail
and simply be ignored by the SCSI controller.
It isn't just when it fails. They move when you add
or remove other disks with lower scsi ID's or on
a controller that is detected earlier. I have seen
that, but the reason - and fix - was always obvious
since it was a direct result of hardware changes, unlike
the failure to boot that may or may not happen depending
on the prior contents of a disk you are adding in a
non-boot position.
--
Les Mikesell
lesmikesell(a)gmail.com
1:31 p.m.
On Sun, 2006-05-07 at 12:12 -0500, Les Mikesell wrote:
It isn't just when it fails. They move when you add
or remove other disks with lower scsi ID's or on
a controller that is detected earlier. I have seen
that, but the reason - and fix - was always obvious
since it was a direct result of hardware changes, unlike
the failure to boot that may or may not happen depending
on the prior contents of a disk you are adding in a
non-boot position.
Put an RFE in bugzilla - that's the only way to get it changed if you
really want the behavior changed.
12:05 p.m.
On Sun, 2006-05-07 at 00:57, Jeff Vian wrote:
>
> Then you have to also adjust grub and /etc/fstab to match on
> every box with opportunities for typos. Normally I just change
Scripting can handle both the labels and making grub and fstab match
without the typos causing mismatching between the different points.
It would, if a tested script came that either worked identically
with all distributions or adapted to the quirks of each.
Otherwise the script becomes another place you can make
the typos.
>
Part of any disk copy plan should take labeling into account in the
planning. If it does not then it is a poor sys admin who gets caught by
surprise.
Yes, but the point of a distribution should be to save the
sys admin's time, not invent new quirks he has to work around.
Tom made the suggestion that the labels can be changed after the copy
is
complete (and before the reboot) which will easily handle the conflicts
by eliminating them before you get bit.
Eliminating the labels and using the partition device names that
are always unique gets rid of the whole messy concept.
Yes, everyone may get caught by it. So what?
Beg you pardon? Can you imagine a commercial product vendor
saying that causing problems is to be expected? Yet you
probably think that Linux distributions should be usable in
most of the same situations.
Everything we overcome is
a learning experience that helps us.
Learning to compensate for unique quirks is never a good
thing for anyone. It was a waste of everyone's time and
will be meaningless when you find a better distribution
or this one finds some other quirky way to compensate for
barely-deterministic scsi device names.
I got hit by it once. The result?
-- I learned, and have never missed this in my planning since.
But you learned something that will soon be useless to know. And
how to you know you've found all the quirks yet? Did you run
across where the MAC addresses are stuffed so they screw up
systems after you move the disks? Maybe there's more that
we haven't hit yet.
I think it is time for this long thread about a tiny molehill to
disappear (but that will happen only if the attempts to make it into a
crusade will go away).
The crusade is for a philosophy of making a distribution that
can actually be used in any scale. I just have a hard time
believing that whoever came up with idea of putting labels
in fstab actually maintains an assortment of machines. And
the same crusade should apply to whoever is deciding to move
a random assortment of files to new and equally arbitrarily
different locations in each release. Either get all the
distributions to agree on a standard and do it at once or
leave things alone. And please document everything under
/etc/sysconfig - something that hasn't been done since
RH9 even though it is vastly different now.
Surprises aren't fun for anyone.
--
Les Mikesell
lesmikesell(a)gmail.com
2:32 p.m.
Les Mikesell wrote:
On Sat, 2006-05-06 at 18:29, Thomas Cameron wrote:
>> Unfortunately no one seems to be interested in that kind
>> of cooperation. If a disto does add something it wants it
>> to be unique to their version and a reason to use only
>> that version. However, I'm not interested in being married
>> to only one distribution so I stick to dd / tar and the
>> things that work everywhere and simply complain about
>> the way different unix flavors have always kept their
>> differences to the detriment of acceptance
> Les -
>
> If you use dd, that means you have two disks in a functioning system.
> After the fact why don't you re-label
> the one you will moving?
Then you have to also adjust grub and /etc/fstab to match on
every box with opportunities for typos. Normally I just change
the one I'm going to use as the master to use partition names
instead of labels and then it doesn't matter whether the copy
operation is by dd'ing the whole disk or tar/cp/rsync by
filesystem. It isn't that difficult to work around, but it
seems like everyone who works with more than a few machines is
going to be surprised by this issue eventually.
Well, if you are using dd to copy a working disk image, you are
going to have to make more changes anyway. You may have problems
with the host name, depending on how it is set. You may also have a
problem in that the MAC address of the NIC will not match the one in
the ifcfg-eth? script and/or /etc/iftab (Depending on the
distribution.) The use of labels was started because there were too
many newbies that would move the drive, and then not be able to boot
it. One common problem was where they would have two drives, in the
machine, one with Windows and one with Linux with Linux on a drive
other then the Windows drive. Then they would decide to move the
Linux drive to its own machine, and it would not work. When using
labels, all you have to do is re-install the boot loader, and maybe
tweak the config for it. When using the actual devices, you have to
edit /etc/fstab as well.
Then you have the problem of moving things on a SCSI controller, or
adding another SCSI controller. Or even better, using a SCSI
controller on something like a Sparc Station where the mapping of
the SCSI drives changes when you add an external drive. (The
internal drive has an id of 3 after boot, but is the boot drive.)
Correct me if I am wrong, but if I remember right, you can decide
what system you want to use in the advanced section of the install.
If you are going to install a bunch of systems by cloning the drive
from an installed system, you should look into things like that. The
installer defaults to what will work for most people. If you plan on
doing something other then a standard install, you have to expect to
tweak some of the advanced settings.
I feel that the default install should make things as easy as
possible for a newbie, doing a normal install, and have the advanced
options for when you are not doing a standard install. If you are
not doing a standard install, expect to have to use some of the
advanced options. Installing on one machine, and cloning the install
is NOT a standard install!
Now, one change that would help is the way duplicate labels are
handled. Right now, the last label found of the duplicates found is
used. It would be better if the first one were used, with the
scanning starting on the first drive. If the same label is found on
a later drive, it should be ignored. That would take care the
problem of taking a drive from another machine and adding it to a
working machine. (If you make the drive from the other machine the
boot drive, you may have problems, but you will have problems any way.)
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
4:16 p.m.
On Sun, 2006-05-07 at 14:32, Mikkel L. Ellertson wrote:
>
Well, if you are using dd to copy a working disk image, you are
going to have to make more changes anyway. You may have problems
with the host name, depending on how it is set.
Normally I clone a machine set for DHCP so it can be
brought up anywhere and an appropriate name address
assigned later (the destination may not be known at
the time it is copied).
You may also have a
problem in that the MAC address of the NIC will not match the one in
the ifcfg-eth? script and/or /etc/iftab (Depending on the
distribution.)
Yes, burying the MAC address in an obscure config file is
a bad idea as well, and the way it was handled could have
caused me some serious trouble if I hadn't caught on
by accident. I've forgotten the version and update level
but at some point the network-config program started
squirreling away the MAC address but not paying much attention
to it. So, I deployed a bunch of machines where the
last step after cloning was to boot the disk locally
to set the hostname and IP address, then the SCA disks
and carriers were shipped to remote locations and swapped
into the machines where they were intended to run. Everything
worked fine, time passed, updates happened, and then after some
update, a machine falls off the network. Turns out that the
update changed the init script behavior so that those config
files with mismatching MAC addresses were ignored.
Fun stuff... And of course I couldn't duplicate the problem
on my local box which was an exact copy of what was deployed.
I was just lucky that the first one updated was at a nearby
location and I went over and hooked up a monitor to find that
refusing to start the network was intentional.
The use of labels was started because there were too
many newbies that would move the drive, and then not be able to boot
it. One common problem was where they would have two drives, in the
machine, one with Windows and one with Linux with Linux on a drive
other then the Windows drive. Then they would decide to move the
Linux drive to its own machine, and it would not work. When using
labels, all you have to do is re-install the boot loader, and maybe
tweak the config for it. When using the actual devices, you have to
edit /etc/fstab as well.
So as long as you only ever have one fedora/rh/centos installation
this won't break anything. What was the plan for later, when
people have more than one drive and connect them together?
I feel that the default install should make things as easy as
possible for a newbie, doing a normal install, and have the advanced
options for when you are not doing a standard install.
What is it about refusing to boot when duplicate labels are
seen that you think is newbie-friendly? An option or default
to continue, using one or the other would be friendly. Crashing
is not friendly.
If you are
not doing a standard install, expect to have to use some of the
advanced options. Installing on one machine, and cloning the install
is NOT a standard install!
It could be. There is nothing about making the machine
cloneable that makes it less useful or handy in the initial
install. Everyone, even a newbie, should be able to back up
and restore their machine which is essentially the same thing,
especially if you restore to different hardware.
Now, one change that would help is the way duplicate labels are
handled. Right now, the last label found of the duplicates found is
used.
Not unless it has recently changed. I've never been able to
boot a machine with duplicate root labels.
--
Les Mikesell
lesmikesell(a)gmail.com
2:01 a.m.
On Sun, 2006-05-07 at 16:16 -0500, Les Mikesell wrote:
I've never been able to boot a machine with duplicate root
labels.
Again, I'd mention a technique used on the old Amigas: If duplicate
volume names were discovered, the first one remains as it is (so plug
that drive into your master position as a simple way of predicting what
will happen, or select it as your boot drive from a menu), the
remainders got numbers appended to them. They were still accessible,
but didn't bugger up booting and using your computer.
It was dead easy to plug in another machines drive to fiddle with files,
without disrupting the normal operation of your machine. It was also
dead easy to boot from the newly inserted drive instead, and use it too,
if you wanted to fix up your main drive.
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:06 a.m.
Les Mikesell wrote:
On Sun, 2006-05-07 at 14:32, Mikkel L. Ellertson wrote:
> Now, one change that would help is the way duplicate labels are
> handled. Right now, the last label found of the duplicates found is
> used.
>
Not unless it has recently changed. I've never been able to
boot a machine with duplicate root labels.
Well..I have. Not intentionally; I was
direct-backing up (with dd) all
but 1 of my data partitions onto another drive, so that included the
volume labels. It still booted the correct partitions, until I used a
kernel which no longer saw the correct partitions; then it tried to use
the backup ones, didn't find the swap or the partition I didn't back up,
and kernel panicked. I was confused for a bit until I figured out it
what it was doing. But it did boot, with a duplicate root label.
-Dan
2:46 p.m.
On Fri, 2006-05-05 at 12:25 -0400, Mauriat Miranda wrote:
On 5/5/06, Aaron Konstam <akonstam(a)sbcglobal.net> wrote:
> In the latest Linux Journal in the etc/rant column the author makes an
> interesting suggestion that I think the Fedora people should consider.
> He points out the problem of associating entries in the fstab file with
> a LABEL-/. If one runs more than one Linux version more than one
> partition might have this label.
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
I question if this necessary. You can have entries in fstab with or
without labels. I've had 3 single Fedora installations on single drive
across multiple partitions and never have run into a problem in the
installer or usage nor have I had to manually edit fstab for this. I
think in Anaconda the labels will start shifting to /1, /2, /home1
etc. Since at runtime you don't deal with partition labels, just their
mount points, it really is not a serious concern.
Just my opinion.
-Mauriat
I agre and your and I and everyone else resorts to changing the labels,
but with a little planning that would not have to be done.
--
=======================================================================
If a man has talent and cannot use it, he has failed. -- Thomas Wolfe
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
3:52 p.m.
On Fri, 2006-05-05 at 12:25 -0400, Mauriat Miranda wrote:
On 5/5/06, Aaron Konstam <akonstam(a)sbcglobal.net> wrote:
> In the latest Linux Journal in the etc/rant column the author makes an
> interesting suggestion that I think the Fedora people should consider.
> He points out the problem of associating entries in the fstab file with
> a LABEL-/. If one runs more than one Linux version more than one
> partition might have this label.
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
I question if this necessary. You can have entries in fstab with or
without labels. I've had 3 single Fedora installations on single drive
across multiple partitions and never have run into a problem in the
installer or usage nor have I had to manually edit fstab for this. I
think in Anaconda the labels will start shifting to /1, /2, /home1
Yes, IF you
have the earlier installed drives in place when you do the
new install.
But if you move drives between machines the change in labels does not
happen so you wind up with conflicts.
etc. Since at runtime you don't deal with partition labels, just
their
mount points, it really is not a serious concern.
Just my opinion.
-Mauriat
3:34 a.m.
Aaron Konstam wrote:
In the latest Linux Journal in the etc/rant column the author makes
an
interesting suggestion that I think the Fedora people should consider.
He points out the problem of associating entries in the fstab file with
a LABEL-/. If one runs more than one Linux version more than one
partition might have this label.
I would like to make the suggestion that the Default Label be more
descriptive. The author suggests something like FC%32ROOT.
Where would be the correct list to send such a suggestion?
The fedora-developers-list maybe.
Enter a Request for Enhancement in http://bugzilla.redhat.com.
Incidentally, what you might want is to request "mount by UUID". See man
mount and man tune2fs for details. The result would be less descriptive,
but should be unique (unless someone has replicated a computer by
copying filesystems from one drive to another...)
Hope this helps,
James.
--
E-mail address: james | "In these troubled times, it's always refreshing to
@westexe.demon.co.uk | see a major company concentrating on vital issues.
| It would be even more refreshing if Compaq tried it
| for once." -- The Inquirer
8:49 a.m.
On Sat, 2006-05-06 at 09:34 +0100, James Wilkinson wrote:
Aaron Konstam wrote:
> In the latest Linux Journal in the etc/rant column the author makes an
> interesting suggestion that I think the Fedora people should consider.
> He points out the problem of associating entries in the fstab file with
> a LABEL-/. If one runs more than one Linux version more than one
> partition might have this label.
>
> I would like to make the suggestion that the Default Label be more
> descriptive. The author suggests something like FC%32ROOT.
>
> Where would be the correct list to send such a suggestion?
> The fedora-developers-list maybe.
Enter a Request for Enhancement in http://bugzilla.redhat.com.
Incidentally, what you might want is to request "mount by UUID". See man
mount and man tune2fs for details. The result would be less descriptive,
but should be unique (unless someone has replicated a computer by
copying filesystems from one drive to another...)
Hope this helps,
James.
I can't find any request for enhancement at :
http://bugzilla.redhat.com
Where exactly is it?
--
Aaron Konstam <akonstam(a)sbcglobal.net>
2:01 p.m.
For what it's worth, add my voice to the "disk labels in /etc/fstab is
retarded" chorus. Who ever made this design decision had to have been
smoking some quality South American weed to have thought this was a
good idea.
--
Chris
"I trust the Democrats to take away my money, which I can afford. I
trust the Republicans to take away my freedom, which I cannot."
2:44 p.m.
On Sun, 2006-05-07 at 14:01 -0500, Christofer C. Bell wrote:
For what it's worth, add my voice to the "disk labels in
/etc/fstab is
retarded" chorus. Who ever made this design decision had to have been
smoking some quality South American weed to have thought this was a
good idea.
It was a good idea.
I can remember scsi devices changing just because I loaded SCSI
emulation (no longer necessary) to burn a CD-R.
I've moved disks around on IDE bus because certain operating system
insisted in being installed to the master - with disk labels, all I had
to do was tell the bios to boot from the slave and not the master - and
everything just worked.
It's a great idea.
I think a unique identifier (such as a time stamp) as part of the string
put into the LABEL would make it more user friendly (and it would solve
the problem), but I like having the mount point as part of the string
too.
But discussing here is not going to result in anything done - someone
who feels that it needs to be done needs to file an RFE so that the
appropriate Red Hat people can see the request.
6572
days inactive
6575
days old
44 comments
14 participants
participants (14)
-
Aaron Konstam -
Christofer C. Bell -
Dan Book -
Filippos Klironomos -
James Wilkinson -
Jeff Vian -
Kam Leo -
Les Mikesell -
Mauriat M -
Michael A. Peters -
Mikkel -
thomas cameron -
Tim -
Timothy Murphy