3:42 p.m.
On Saturday 07 August 2004 10:57, Arjan van de Ven wrote:
always mount by label, and we need to add a "add all swap
automatic"
thing....
It's a problem in that SATA is going to be driven by /dev/sdX for now,
but that some cards happen to work mostly kinda via the older legacy
driver. It's a bit of a pain during the migration, but it the pain
should be finite and limited due to mount-by-label, udev etc etc
On Saturday 07 August 2004 12:38, Jesse Keating wrote:
Perhaps, but it seems like a rather painful change to make midstream.
What about introducing a kudzu hack that detects this change and does
something accordingly? Is something like that possible?
Is this change due to using the correct device driver from SIL?
Previous kernels have been using a generic driver rather than the one
recommended by SIL.
I haven't installed this kernel yet but if it changes to the correct
driver I'd say that it is a good thing!
Joe
6:27 p.m.
New subject: Device change for Sil 3112 in latest kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 07 August 2004 13:42, Joe Robertson wrote:
I haven't installed this kernel yet but if it changes to the
correct
driver I'd say that it is a good thing!
Sure, changing to the 'correct' driver is good, but not when it changes
the device structure. Quite a lot can break, especially if the system
in question already has some SCSI devices. This sort of change should
have been either held off until the next version release of FC, or more
work should have been done to detect this situation and handle it the
least painfull way possible.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBFWVP4v2HLvE71NURAp12AJsH4ku4OKBdcMBBV/iplxV3EfhzlwCgitV+
X2plX2/xAw7I1MmeXL6vhVc=
=kIIJ
-----END PGP SIGNATURE-----
3:30 a.m.
New subject: Device change for Sil 3112 in latest kernel
On Sun, 2004-08-08 at 01:27, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 07 August 2004 13:42, Joe Robertson wrote:
> I haven't installed this kernel yet but if it changes to the correct
> driver I'd say that it is a good thing!
Sure, changing to the 'correct' driver is good, but not when it changes
the device structure. Quite a lot can break, especially if the system
in question already has some SCSI devices. This sort of change should
have been either held off until the next version release of FC, or more
work should have been done to detect this situation and handle it the
least painfull way possible.
this is why we use mount-by-label for everything.
The fact that swap seems not to migrate automatic is a bug in swapon.
9:59 a.m.
New subject: Device change for Sil 3112 in latest kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 08 August 2004 01:30, Arjan van de Ven wrote:
this is why we use mount-by-label for everything.
The fact that swap seems not to migrate automatic is a bug in swapon.
If swapon is used to mount swap, why do we reference swap in /etc/fstab?
It's still listed by device name.
Sure, a basic install does mount most by label, but not every single FC
install will have all partitions mounted by label. If nothing else,
this information should be posted to FedoraFAQ as to 'why did my swap
stop working when I updated my kernel' or other mounts failed.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBFj/L4v2HLvE71NURAorFAJ94pdzBLP5UojyaT+60zUa4n5B4XACfc9xr
Utf/3YioK7IXwC23fvtjsiQ=
=kB1V
-----END PGP SIGNATURE-----
2:31 p.m.
New subject: Device change for Sil 3112 in latest kernel
arjanv(a)redhat.com wrote:
On Sun, 2004-08-08 at 01:27, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 07 August 2004 13:42, Joe Robertson wrote:
> > I haven't installed this kernel yet but if it changes to the correct
> > driver I'd say that it is a good thing!
>
> Sure, changing to the 'correct' driver is good, but not when it changes
> the device structure. Quite a lot can break, especially if the system
> in question already has some SCSI devices. This sort of change should
> have been either held off until the next version release of FC, or more
> work should have been done to detect this situation and handle it the
> least painful way possible.
this is why we use mount-by-label for everything.
The fact that swap seems not to migrate automatic is a bug in swapon.
Mount by label is not the panacea you make it out to be. Ever accidentally
add a disk to a machine that has the same labels as the existing disks?
At the very least it confuses things. As Jesse previously stated it would
be nice if changes like this were done in conjunction with the next release
AND documented. At least then we know what is going on.
Tom
2:59 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Sun, 8 Aug 2004 15:31:35 -0400 (EDT), Tom Diehl <tdiehl(a)rogueind.com> wrote:
As Jesse previously stated it would
be nice if changes like this were done in conjunction with the next release
AND documented. At least then we know what is going on.
Personally I'd settle for getting Core developers to actually use the
updates-testing repo
for all proposed updates. Even if the maintainers pushing the
update...in their infinite wisdom..know there are absolutely no
packaging bugs or other problems inherent in the package, having it
available for a few days (even just 1 day) in testing for competent
people in the userbase to use before its pushed for general
consumption wouldn't hurt.
If the newest kernel update had hit updates-testing first... maybe we
could have had fedorafaq.org and fedoranews.org updated BEFORE the
kernel hit updates-released with preventative and recovery steps and
we could have had a note about this change incorporated in the update
annoucement text.
There have also been cases of updates being released that have
dependancy conflicts with other Core packages, making sure updates get
into updates-testing first for feedback should help avoid these
situations as well. In fact, i should stress that in a future where
Fedora Extras will be more integrated with Core in terms of
development process, its going to be even more important that proposed
updates make it into updates-testing first so users can check for this
sort of dep problem across Core+Extras so packages can be rebuilt in a
consistent manner.
-jef
5:56 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Sun, 2004-08-08 at 21:59, Jeff Spaleta wrote:
On Sun, 8 Aug 2004 15:31:35 -0400 (EDT), Tom Diehl
<tdiehl(a)rogueind.com> wrote:
> As Jesse previously stated it would
> be nice if changes like this were done in conjunction with the next release
> AND documented. At least then we know what is going on.
Personally I'd settle for getting Core developers to actually use the
updates-testing repo
for all proposed updates. Even if the maintainers pushing the
update...in their infinite wisdom..know there are absolutely no
packaging bugs or other problems inherent in the package, having it
available for a few days (even just 1 day) in testing for competent
people in the userbase to use before its pushed for general
consumption wouldn't hurt.
it's a balancing act; do we delay the serious security hole fixes a day
or not..... it's not an easy question. Right now the severity of the
security problem made me decide against a day in testing but instead go
live right away (based on a kernel that has been in rawhide for over a
week). I hope you understand that that is a judgement call on a case by
case basis (yes I know lame argument), but the fact that this security
issue was going public with an exploit made me and Dave decide to go
live instantly and not after 24 or 48 hours.
6:27 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, 09 Aug 2004 00:56:54 +0200, Arjan van de Ven <arjanv(a)redhat.com> wrote:
it's a balancing act; do we delay the serious security hole fixes
a day
or not..... it's not an easy question. Right now the severity of the
security problem made me decide against a day in testing but instead go
live right away (based on a kernel that has been in rawhide for over a
week). I hope you understand that that is a judgement call on a case by
case basis (yes I know lame argument), but the fact that this security
issue was going public with an exploit made me and Dave decide to go
live instantly and not after 24 or 48 hours.
I understand its case by case and i also understand that anything
security related adds layers of complexity when trying to discuss the
ramifications. But I'm not so sure the current way fedora is handling
crisis updates is really in balance at all. The move away from
security backporting and a loss of a coherent way to get people update
notices they can read before the updates become available for install
throws the balance off a great deal from what has come before. And
frankly, the change in how upstream kernel development is going to
process new features into the stable tree isn't going to make
situations like this any better.
Perhaps you can find a compromise here for the kernel, and release a
weekly test kernel to updates-testing. Not with the intent of
definitely releasing that kernel as updates-released. But so people
can get a heads-up on changes of kernel features and document them in
a faq so if you do have to push a crisis update major changes in how
the kernel deals with hardware the faq can be referenced in the
notice.
-jef
7:20 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
Jeff Spaleta wrote:
crisis updates is really in balance at all. The move away from
security backporting and a loss of a coherent way to get people update
notices they can read before the updates become available for install
Do you mean RHEL? This is Fedora, and I don't like to have a perpetual
kernel in the distribucion as RHEL has. Mainly because upstream kernel
is moving _very_ fast(and stable) and in Fedora there is no enough
'hacker power' to do backports of _all_ new features/fixes/... that
upstream brings.
I can *not* understand how FC-1 still has a 2.4.22 kernel, released
*ONE* year ago.
throws the balance off a great deal from what has come before. And
frankly, the change in how upstream kernel development is going to
process new features into the stable tree isn't going to make
situations like this any better.
2.6.x kernel.org is the stablest and the highest quality kernel
that Torvalds has released. To get anything similar to this
with any 2.4.x, you had to get a 2.4.2x and a -ac patch.
--
x86-64 GenuineIntel
8:03 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, 09 Aug 2004 02:20:58 +0200, Xose Vazquez Perez
<xose(a)astures.jazztel.es> wrote:
Do you mean RHEL? This is Fedora, and I don't like to have a
perpetual
kernel in the distribucion as RHEL has.
I was referring to the distribution which must not be named... RHL.
Mainly because upstream kernel
is moving _very_ fast(and stable) and in Fedora there is no enough
'hacker power' to do backports of _all_ new features/fixes/... that
upstream brings.
I understand things are moving faster in upstream kernel. At no point
did i suggest that focusing on security backports like RHL did in the
past was the right way
to proceed. I was reinterpreting Arjan's comment about 'balance' to my
benefit to suggest that we need something else to offset the damange
done by feature creep. And that something else.. is effective use of
the updates-testing repository to give people running a current
release of FC2 a headsup about feature creep issues before a mustfix
security issue forces a kernel to be released as an update.
Arjan is right everything ...sadly... is case-by-case with regard to
how package maintainers use updates-testing. Updates-testing is very
ill-defined. And that is a good and bad thing.
The kernel is a very sensitive package because of its close
association with hardware issues, and I think that as upstream kernel
development speeds up we are going to see feature creep breakage be a
continual annoying problem with some hardware in updated kernels. So
if we can't prevent it, my suggestion is.. keep updates-testing
populated so community can keep a faq document detailing feature creep
issues and workarounds/recovery steps.
-jef
1:40 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, 2004-08-09 at 02:20, Xose Vazquez Perez wrote:
I can *not* understand how FC-1 still has a 2.4.22 kernel, released
*ONE* year ago.
It's just 3 weeks of work by an engineer experienced in this to go to a
newer 2.4 for FC1 due to the extreme complexity of the NPTL patch. If FC1
is to get a newer kernel it will be a 2.6 kernel. Which isn't going to
happen realistically unless the Fedora Legacy project wants to be really brave.
10:04 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 08 August 2004 23:40, Arjan van de Ven wrote:
It's just 3 weeks of work by an engineer experienced in this to
go to a
newer 2.4 for FC1 due to the extreme complexity of the NPTL patch. If
FC1 is to get a newer kernel it will be a 2.6 kernel. Which isn't going
to happen realistically unless the Fedora Legacy project wants to be
really brave.
We're not that brave, plus it flies in the face of our goals.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBF5Kg4v2HLvE71NURApw6AJ4wwXl0Zbob2JM9sjBJl6uvBKiF2QCdHzfM
6skpXBWNQPxhf4k1yKTz0Ik=
=EA7y
-----END PGP SIGNATURE-----
5:48 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, Aug 09, 2004 at 02:20:58AM +0200, Xose Vazquez Perez wrote:
is moving _very_ fast(and stable) and in Fedora there is no enough
'hacker power' to do backports of _all_ new features/fixes/... that
upstream brings.
I can *not* understand how FC-1 still has a 2.4.22 kernel, released
*ONE* year ago.
There is a lot in the 2.4.22 FC-1 kernel that makes this kind of rolling
forward movement hard. In essence 2.4.22 FC-1 was defined by what was in
RH9 2.4.x (NPTL etc) and that in turn wasn't defined for the Fedora like
goals.
The only sane way to really update the FC1 kernel is 2.6.x
1:19 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Sun, Aug 08, 2004 at 07:27:08PM -0400, Jeff Spaleta wrote:
Perhaps you can find a compromise here for the kernel, and release a
weekly test kernel to updates-testing. Not with the intent of
definitely releasing that kernel as updates-released. But so people
can get a heads-up on changes of kernel features and document them in
a faq so if you do have to push a crisis update major changes in how
the kernel deals with hardware the faq can be referenced in the
notice.
hmmm but... we have that kindof with rawhide and the kernel on
http://people.redhat.com/arjanv/2.6
I have no problem with semi-automatically pushing that weekly to testing as
well...
5:52 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
08/09/2004 08:19 AM, Arjan van de Ven wrote:
hmmm but... we have that kindof with rawhide and the kernel on
http://people.redhat.com/arjanv/2.6
Yes, but these kernels are compiled with gcc 3.4.1 (or I missed
something?) which is not available in FC2. I like using your repository,
but I'm not able to use external drivers :( I couldn't make NVIDIA
driver working using gcc34. (If there is only a problem with NVIDIA, not
with all external kernel modules - sorry for bothering you).
I have no problem with semi-automatically pushing that weekly to
testing as
well...
That would be great - now I'm forced to use kernel from
http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
in official ones. Of course I could recompile your kernel from Rawhide
with gcc 3.3.3, but it's some kind of wasting time (for me of course :P)
----------------------------------------------------------------------
Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f17cb
6:03 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
That would be great - now I'm forced to use kernel from
http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
I wonder what the fix is atrpms applied....
6:12 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
08/09/2004 01:03 PM, Arjan van de Ven :
>That would be great - now I'm forced to use kernel from
>http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
I wonder what the fix is atrpms applied....
Well, I don't know, but I have to add that kernels from your repository
also works for me. Only these from official updates are broken :/
----------------------------------------------------------------------
Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f17cb
6:17 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote:
> That would be great - now I'm forced to use kernel from
> http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
I wonder what the fix is atrpms applied....
The only thing that qualifies as a "fix" are the 8kstacks. The rest is
v4l2 and uml, don't believe there will be fixes coming from that
corner ...
--
Axel.Thimm at ATrpms.net
6:18 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, Aug 09, 2004 at 01:17:55PM +0200, Axel Thimm wrote:
On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote:
> > That would be great - now I'm forced to use kernel from
> > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
>
> I wonder what the fix is atrpms applied....
The only thing that qualifies as a "fix" are the 8kstacks. The rest is
v4l2 and uml, don't believe there will be fixes coming from that
corner ...
kdskbent isn't a 8k-vs-4k thing though...
maybe just a newer version than the last one the reporter tried and it got
fixed since or something
6:27 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, Aug 09, 2004 at 01:18:51PM +0200, Arjan van de Ven wrote:
On Mon, Aug 09, 2004 at 01:17:55PM +0200, Axel Thimm wrote:
> On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote:
> > > That would be great - now I'm forced to use kernel from
> > > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug
> >
> > I wonder what the fix is atrpms applied....
>
> The only thing that qualifies as a "fix" are the 8kstacks. The rest is
> v4l2 and uml, don't believe there will be fixes coming from that
> corner ...
kdskbent isn't a 8k-vs-4k thing though...
maybe just a newer version than the last one the reporter tried and it got
fixed since or something
ATrpms bases its kernel on the FC kernels and takes over the
nomenclature adding a subrelease tag with an underscore like
2.6.7-1.499_7.rhfc2.at (so that would be based off 2.6.7-1.499).
Dawid, please post the uname -r of your kernel, the matching rawhide
kernel should then have the fix.
BTW I have withdrawn the 499-503 kernels from
http://atrpms.net/dist/fc2/kernel-experimental/ as there were issues
with smp on HT systems. 509 seems to work fine though.
--
Axel.Thimm at ATrpms.net
2:36 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
Sorry, that it took me so long, but I had small problem with my system.
I tried to install all available kernels with:
rpm -ivh kernel-*.rpm --oldpackage
but only few of them had installed. I had to repeat this command with
every single kernel. Unfortunatelly with the latest one I got error -990
from rpm (cpio couldn't extract some files). I downloaded rpm package
once again and tried to install it once more. Well, error -990 also
appeared but at this try db4 (?) told me about sync and input/output
errors :/
At this moment I lost control over my system: bash could not have found
any program (ps, df, mc, etc.). I thought that it was KDE problem, so I
switched to the console where I was previously logged in. Situation
hadn't have changed, so I tried to log in to the next terminal. I saw only
mingetty respawning to fast, disabling for 5 minutes (or something)
After that I pressed SysRq+ALT+U and SysRq+ALT+B
Hmm... I lost /etc/fstab. In /var/log/messages I found this:
http://gajownik.fm.interia.pl/xfs_error.txt
My / is on XFS filesystem and this bug happend with
2.6.7-1.494_6.rhfc2.at kernel. I tried to reproduce it but with no
results :(
08/09/2004 01:27 PM, Axel Thimm wrote:
Dawid, please post the uname -r of your kernel, the matching rawhide
kernel should then have the fix.
I checked all available kernels and here are results:
2.6.5-1.358 OK
2.6.6-1.427 OK
2.6.6-1.435 OK
2.6.6-1.435.2.1 OK
2.6.6-1.435.2.3 OK
2.6.7-1.494.2.2 BROKEN
2.6.7-1.494.2.2.root OK (in SPEC file I only disabled building SMP kernel)
2.6.7-1.494_6.rhfc2.at OK
2.6.7-1.499_7.rhfc2.at OK
2.6.7-1.509 OK
I don't understand one thing - previously kernel-2.6.6-1.427 was broken
:() Value shown on the console has also changed - from 2707 to 1273.
----------------------------------------------------------------------
To moze byc ekscytujace lato... >>> http://link.interia.pl/f181c
6:04 a.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
On Mon, 2004-08-09 at 12:52, Dawid Gajownik wrote:
08/09/2004 08:19 AM, Arjan van de Ven wrote:
> hmmm but... we have that kindof with rawhide and the kernel on
> http://people.redhat.com/arjanv/2.6
Yes, but these kernels are compiled with gcc 3.4.1 (or I missed
something?) which is not available in FC2. I like using your repository,
but I'm not able to use external drivers :( I couldn't make NVIDIA
driver working using gcc34. (If there is only a problem with NVIDIA, not
with all external kernel modules - sorry for bothering you).
except that such 'testing' with nvidia modules voids the testing value
and is, besides being entirely uninteresting to me, besides the current
topic of this thread...
2:45 p.m.
New subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel]
08/09/2004 01:04 PM, Arjan van de Ven wrote:
except that such 'testing' with nvidia modules voids the
testing
value and is, besides being entirely uninteresting to me, besides the
current topic of this thread...
OK. I understand. I just wanted to check why KDE menu is so slow. I
thought it was caused by nv driver. Unfortunatelly NVIDIA driver didn't
help.
-------------------------------------------------------------------
Czy Twoja domena jest jeszcze wolna?
Sprawdz: http://link.interia.pl/f182a
2:48 a.m.
New subject: Device change for Sil 3112 in latest kernel
On Mon, 9 Aug 2004 05:31, Tom Diehl <tdiehl(a)rogueind.com> wrote:
>this is why we use mount-by-label for everything.
>The fact that swap seems not to migrate automatic is a bug in swapon.
Mount by label is not the panacea you make it out to be. Ever accidentally
add a disk to a machine that has the same labels as the existing disks?
Maybe what we need is a UUID for the machine so that it won't automatically
mount the disks from another machine. This could be done in one of two ways.
One is for the system to know the UUID, the other is for the configuration
system to just append a UUID when creating labels for mount-by-label.
It would be really good if we could have something similar for software RAID
(it would be a real bummer if you booted with a new disk installed only to
find that it had the same RAID-1 device as your root file system but with a
higher access count).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
5:58 a.m.
New subject: Device change for Sil 3112 in latest kernel
On Mon, Aug 09, 2004 at 05:48:48PM +1000, Russell Coker wrote:
Maybe what we need is a UUID for the machine so that it won't
automatically
mount the disks from another machine. This could be done in one of two ways.
Your UUID needs to be per install - you can have multiple installs on one
box quite sanely (or could if it wasnt for labels 8))
7:26 a.m.
New subject: Device change for Sil 3112 in latest kernel
On Mon, 2004-08-09 at 03:48, Russell Coker wrote:
On Mon, 9 Aug 2004 05:31, Tom Diehl <tdiehl(a)rogueind.com>
wrote:
> >this is why we use mount-by-label for everything.
> >The fact that swap seems not to migrate automatic is a bug in swapon.
>
> Mount by label is not the panacea you make it out to be. Ever accidentally
> add a disk to a machine that has the same labels as the existing disks?
Maybe what we need is a UUID for the machine so that it won't automatically
mount the disks from another machine. This could be done in one of two ways.
One is for the system to know the UUID, the other is for the configuration
system to just append a UUID when creating labels for mount-by-label.
It would be really good if we could have something similar for software RAID
(it would be a real bummer if you booted with a new disk installed only to
find that it had the same RAID-1 device as your root file system but with a
higher access count).
I suppose using the UUID alone in /etc/fstab would be unnecessarily
obtuse. I work in a laboratory environment that does digital media
forensics, sometimes on evidence in criminal cases. Therefore we need to
be absolutely certain we aren't writing to any partitions that don't
"belong" to us.
I always reconfigure /etc/fstab on my workstation, after installation,
to reference UUID= instead of LABEL= for all my system partitions. The
only problem with that approach is that I can't simply do the same thing
in GRUB. Appending the UUID to the LABEL would take care of the problem
without having to make more than a trivial change; is this something to
propose for anaconda perhaps?
--
Paul W. Frields, RHCE
3:07 p.m.
New subject: Device change for Sil 3112 in latest kernel
On Mon, 2004-08-09 at 08:26 -0400, Paul W. Frields wrote:
I always reconfigure /etc/fstab on my workstation, after
installation,
to reference UUID= instead of LABEL= for all my system partitions. The
only problem with that approach is that I can't simply do the same thing
in GRUB. Appending the UUID to the LABEL would take care of the problem
without having to make more than a trivial change; is this something to
propose for anaconda perhaps?
The problem is that the label has a max length (filesystem dependent,
it's 15 chars for ext[23] iirc). So appending the UUID isn't really
doable.
Switching to mount by UUID instead of by label has been proposed a few
times, but I find it to be a fairly disgusting thing to have to expose
at all and thus have resisted the suggestion.
Jeremy
1:40 p.m.
New subject: Device change for Sil 3112 in latest kernel
Le Sun, 08 Aug 2004 10:30:22 +0200
Arjan van de Ven <arjanv(a)redhat.com> a écrit :
this is why we use mount-by-label for everything.
The fact that swap seems not to migrate automatic is a bug in swapon.
Have you think about LVM stuff ? (just been caught by the mysterious
SATA device renaming after latest kernel update in FC2 and now looking
for a clean solution that will do the trick)
Bye.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : E371 42C8 CE2C B24B 820D 7BDD 9403 A408 F15D 4B5D
3:10 p.m.
New subject: Device change for Sil 3112 in latest kernel
On Mon, 2004-08-09 at 20:40 +0200, Jerome Benoit wrote:
Le Sun, 08 Aug 2004 10:30:22 +0200
Arjan van de Ven <arjanv(a)redhat.com> a écrit :
> this is why we use mount-by-label for everything.
> The fact that swap seems not to migrate automatic is a bug in swapon.
Have you think about LVM stuff ? (just been caught by the mysterious
SATA device renaming after latest kernel update in FC2 and now looking
for a clean solution that will do the trick)
It shouldn't be a problem with LVM, afaik. The LVM volume group name is
stored as part of the metadata in the PV and similar with the logical
volumes. vgscan should then find them no matter what device they happen
to be on.
Jeremy
4:50 a.m.
New subject: Device change for Sil 3112 in latest kernel
Le Mon, 09 Aug 2004 16:10:37 -0400
Jeremy Katz <katzj(a)redhat.com> a écrit :
On Mon, 2004-08-09 at 20:40 +0200, Jerome Benoit wrote:
> Le Sun, 08 Aug 2004 10:30:22 +0200
> Arjan van de Ven <arjanv(a)redhat.com> a écrit :
> > this is why we use mount-by-label for everything.
> > The fact that swap seems not to migrate automatic is a bug in
> > swapon.
> Have you think about LVM stuff ? (just been caught by the mysterious
> SATA device renaming after latest kernel update in FC2 and now
> looking for a clean solution that will do the trick)
It shouldn't be a problem with LVM, afaik. The LVM volume group name
is stored as part of the metadata in the PV and similar with the
logical volumes. vgscan should then find them no matter what device
they happen to be on.
Hi,
Sorry for the late reply but i've been busy lately ...
Bad luck, it's not working flawlessly. The LVM2 internal seems to flag
Physical Volume with UUID and with the updated kernel switching, the new
one with the SATA device renaming seems to look for a non existant PV in
my data VG (some kind of 'ghost PV') ... Anyway, i can 'fix' that by
redoing the VG from scratch for example.
I don't have time currently to dig further sorry ..
Bye.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : E371 42C8 CE2C B24B 820D 7BDD 9403 A408 F15D 4B5D
3:09 p.m.
New subject: Device change for Sil 3112 in latest kernel
On Sun, 2004-08-08 at 10:30 +0200, Arjan van de Ven wrote:
this is why we use mount-by-label for everything.
The fact that swap seems not to migrate automatic is a bug in swapon.
There's label support in the current swapon code in util-linux, I just
need to make the appropriate changes to anaconda so that we reference
swaps by label. There's a bug with the details if anyone is interested
in taking a look at it and providing the relevant patch (#127892)
Jeremy
7232
days inactive
7246
days old
30 comments
13 participants
participants (13)
-
Alan Cox -
Arjan van de Ven -
Axel Thimm -
Dawid Gajownik -
Jef Spaleta -
Jeremy Katz -
Jerome Benoit -
Jesse Keating -
Joe Robertson -
Paul W. Frields -
Russell Coker -
Tom Diehl -
Xose Vazquez Perez