10:35 a.m.
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)
Things I know of so far:
* systemd
* gnome3 / gnome-shell default
* removing a bunch of suid stuff in favor of capabilities
* xfce 4.8 (with any luck).
Things that are out there, but no idea if anyone is working on them or
if they might be ready by f15:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
any luck).
* Will NM finally be able to do bridging?
* Some kind of packaged wayland to play with, even if it doesn't do
much?
Any other exciting work in progress that might land in F15 that people
are actively working on?
kevin
10:46 a.m.
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
I don't think we are quite ready for this yet. I do have "btrfs
strategy" on my todo list, though. I'm hoping we can start talking at
FUDCon about what we want btrfs to do for us, possibly taking the place
of LVM.
- Chris
10:54 a.m.
On 11/12/2010 11:46 AM, Chris Lumens wrote:
> * btrfs (Is this ready to be default? :) If so, would that
warrant a
> change in our lvm by default setup?
I don't think we are quite ready for this yet. I do have "btrfs
strategy" on my todo list, though. I'm hoping we can start talking at
FUDCon about what we want btrfs to do for us, possibly taking the place
of LVM.
- Chris
We have been spending a lot of time and thought trying to scheme about how to
accelerate btrfs. At this point, it is actually fairly stable but still missing
key things (most notably a fsck that can fix the file system!).
Last week at plumbers, we did get a large chunk of the btrfs developers together
for a few hours and have been working to make sure that we have sufficient
people working to get this done...
Ric
11:03 a.m.
We have been spending a lot of time and thought trying to scheme
about how to accelerate btrfs. At this point, it is actually fairly
stable but still missing key things (most notably a fsck that can
fix the file system!).
Last week at plumbers, we did get a large chunk of the btrfs
developers together for a few hours and have been working to make
sure that we have sufficient people working to get this done...
This is good information, and makes me feel even better about removing
the need for a btrfs command line option.
What I mean about "we're not quite there yet" is that I don't really
want to change over to it as the default in anaconda until we (1) have a
release or two with it as a non-hidden option to get some feedback, and
(2) know what our strategy with it in a greater sense is. If it's going
to allow us to do all sorts of crazy new things, I'd like to enable the
crazy new things at the same time as we switch it in as the default.
- Chris
11:09 a.m.
On Fri, Nov 12, 2010 at 12:03 PM, <clumens(a)redhat.com> wrote:
> We have been spending a lot of time and thought trying to scheme
> about how to accelerate btrfs. At this point, it is actually fairly
> stable but still missing key things (most notably a fsck that can
> fix the file system!).
>
> Last week at plumbers, we did get a large chunk of the btrfs
> developers together for a few hours and have been working to make
> sure that we have sufficient people working to get this done...
This is good information, and makes me feel even better about removing
the need for a btrfs command line option.
What I mean about "we're not quite there yet" is that I don't really
want to change over to it as the default in anaconda until we (1) have a
release or two with it as a non-hidden option to get some feedback, and
(2) know what our strategy with it in a greater sense is. If it's going
to allow us to do all sorts of crazy new things, I'd like to enable the
crazy new things at the same time as we switch it in as the default.
Agreed, my plan was to take away the option for F15 (I sent the
anaconda patch already right?) and leave it as an optional thing for
at least 2 releases until we even begin to discuss setting it as
default.
Another criteria I have for making it default is I want grub support,
specifically grub2. So until grub2 is in Fedora and we have btrfs
patches upstream in grub2 I have no intention of making it the default
in Fedora. Thanks,
Josef
12:23 p.m.
Agreed, my plan was to take away the option for F15 (I sent the
anaconda patch already right?) and leave it as an optional thing for
at least 2 releases until we even begin to discuss setting it as
default.
Yep, it's been in for quite a while now:
commit 8f4340dc86f515cd2f6571c06b790ab420f719b2
Author: Chris Lumens <clumens(a)redhat.com>
Date: Fri Sep 24 15:52:18 2010 -0400
btrfs will be a supported filesystem in F15 (josef).
Overall, this sounds like a fine plan to me.
- Chris
2:55 p.m.
On 11/12/2010 12:09 PM, Josef Bacik wrote:
Another criteria I have for making it default is I want grub
support,
specifically grub2. So until grub2 is in Fedora and we have btrfs
patches upstream in grub2 I have no intention of making it the default
in Fedora. Thanks,
Grub2 has been in Fedora for some time now:
http://koji.fedoraproject.org/koji/packageinfo?packageID=6684
~spot
2:58 p.m.
On 11/12/2010 02:55 PM, Tom "spot" Callaway wrote:
On 11/12/2010 12:09 PM, Josef Bacik wrote:
> Another criteria I have for making it default is I want grub support,
> specifically grub2. So until grub2 is in Fedora and we have btrfs
> patches upstream in grub2 I have no intention of making it the default
> in Fedora. Thanks,
Grub2 has been in Fedora for some time now:
http://koji.fedoraproject.org/koji/packageinfo?packageID=6684
~spot
But not default right? That'd be the kicker.
-Eric
3 p.m.
On 11/12/2010 03:58 PM, Eric Sandeen wrote:
On 11/12/2010 02:55 PM, Tom "spot" Callaway wrote:
> On 11/12/2010 12:09 PM, Josef Bacik wrote:
>> Another criteria I have for making it default is I want grub support,
>> specifically grub2. So until grub2 is in Fedora and we have btrfs
>> patches upstream in grub2 I have no intention of making it the default
>> in Fedora. Thanks,
>
> Grub2 has been in Fedora for some time now:
>
> http://koji.fedoraproject.org/koji/packageinfo?packageID=6684
>
> ~spot
But not default right? That'd be the kicker.
No, not the default, but he didn't say that, he said "until grub2 is in
Fedora and we have btrfs patches upstream in grub2...". I was merely
pointing out that the first half of that conditional is already TRUE. ;)
~spot
3:07 p.m.
On Fri, Nov 12, 2010 at 4:00 PM, Tom "spot" Callaway
<tcallawa(a)redhat.com> wrote:
On 11/12/2010 03:58 PM, Eric Sandeen wrote:
> On 11/12/2010 02:55 PM, Tom "spot" Callaway wrote:
>> On 11/12/2010 12:09 PM, Josef Bacik wrote:
>>> Another criteria I have for making it default is I want grub support,
>>> specifically grub2. So until grub2 is in Fedora and we have btrfs
>>> patches upstream in grub2 I have no intention of making it the default
>>> in Fedora. Thanks,
>>
>> Grub2 has been in Fedora for some time now:
>>
>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6684
>>
>> ~spot
>
> But not default right? That'd be the kicker.
No, not the default, but he didn't say that, he said "until grub2 is in
Fedora and we have btrfs patches upstream in grub2...". I was merely
pointing out that the first half of that conditional is already TRUE. ;)
I should say that I'm going to focus on grub2 for Btrfs support, so if
Fedora wants to move to Btrfs as the default then either
1) Fedora will have to keep /boot around with ext*
2) Fedora will have to move to grub2
3) Fedora will have to maintain the btrfs filesystem support for grub1
So really the grub2 thing isn't that big of a deal for me, because one
way or the other I'm not doing the work to make sure it's working in
Fedora, beyond making sure it works in grub2. Thanks,
Josef
7:57 p.m.
On Fri, 12.11.10 12:09, Josef Bacik (josef(a)toxicpanda.com) wrote:
Another criteria I have for making it default is I want grub
support,
specifically grub2. So until grub2 is in Fedora and we have btrfs
patches upstream in grub2 I have no intention of making it the default
in Fedora. Thanks,
Some folks at LPC suggested we should switch from grub to syslinux
rather than grub2. Meego uses syslinux. I have little clue how both
compare, but maybe it's worth considering syslinux given that we already
use it for the cd booting and maybe we should consolidate our options
and use syslinux everywhere?
Supposedly syslinux already has btrfs support.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:15 p.m.
Hi,
2010/11/13 Lennart Poettering <mzerqung(a)0pointer.de>:
On Fri, 12.11.10 12:09, Josef Bacik (josef(a)toxicpanda.com) wrote:
> Another criteria I have for making it default is I want grub support,
> specifically grub2. So until grub2 is in Fedora and we have btrfs
> patches upstream in grub2 I have no intention of making it the default
> in Fedora. Thanks,
Some folks at LPC suggested we should switch from grub to syslinux
rather than grub2.
No objection as long as it supports Windows :)
Meego uses syslinux. I have little clue how both
compare, but maybe it's worth considering syslinux given that we already
use it for the cd booting and maybe we should consolidate our options
and use syslinux everywhere?
Supposedly syslinux already has btrfs support.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kind regards,
Michal
9 p.m.
Some folks at LPC suggested we should switch from grub to syslinux
rather than grub2. Meego uses syslinux. I have little clue how both
compare, but maybe it's worth considering syslinux given that we already
use it for the cd booting and maybe we should consolidate our options
and use syslinux everywhere?
I imagine the benefits of grub2 in OLPC are needless. However, for
Fedora in general -I must say I am a fan of grub2, but this is for
another thread.
5:50 p.m.
On Fri, 12 Nov 2010 12:09:35 -0500, Josef Bacik wrote:
Another criteria I have for making it default is I want grub
support,
specifically grub2. So until grub2 is in Fedora and we have btrfs
patches upstream in grub2 I have no intention of making it the default
in Fedora. Thanks,
That seems overly restrictive -- DragonFly BSD ships with their Hammer
filesystem as default, even though they still need a UFS /boot partition.
Regards,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12:26 p.m.
On 11/12/2010 05:03 PM, clumens(a)redhat.com wrote:
> We have been spending a lot of time and thought trying to scheme
> about how to accelerate btrfs. At this point, it is actually fairly
> stable but still missing key things (most notably a fsck that can
> fix the file system!).
>
> Last week at plumbers, we did get a large chunk of the btrfs
> developers together for a few hours and have been working to make
> sure that we have sufficient people working to get this done...
This is good information, and makes me feel even better about removing
the need for a btrfs command line option.
What I mean about "we're not quite there yet" is that I don't really
want to change over to it as the default in anaconda until we (1) have a
release or two with it as a non-hidden option to get some feedback, and
(2) know what our strategy with it in a greater sense is. If it's going
to allow us to do all sorts of crazy new things, I'd like to enable the
crazy new things at the same time as we switch it in as the default.
Sounds like a good plan to me.
Remove the need for the command line option for F15+
Gather feedback for F15 and F16
Consider switching the default to BTRFS in F17.
*DE could consider switching the default to use EXT4 directly without
LVM. [1]
I would think that users would love to experience the work that Theodore
Tso has been doing [2] and what better way is it for them to do other
then experiencing it first hand in F15 when it goes out the door..
JBG
1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
2. http://free.linux.hp.com/~enw/ext4/2.6.36-rc6/
5:41 p.m.
On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B. Guðmundsson" wrote:
*DE could consider switching the default to use EXT4 directly without
LVM. [1]
1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
The "Detailed Description" seems contradictory:
| LVM provides very little benefit for most Fedora users, at the cost of
| performance and complexity:
|
| * Certain filesystem features (ext3 barriers) are unavailable when run
| on top of LVM.
Isn't this just a bug which should be fixed? (I actually thought this
had been fixed already)
| * Software RAID performance is greatly reduced when layered on LVM.
But the stated task is to get rid of LVM except for "experts in
storage administration" (from the next section of the same document).
Who will presumably be the only ones wanting Software RAID. The
non-experts won't know anything about Software RAID, so they won't be
affected by this performance problem with LVM.
| * LVM partitions are not automatically assembled by the desktop systems.
I'm not sure what this one means. "assembled" as in what happens when
you spread a VG over multiple block devices?
Anyway, I think LVM is jolly useful:
- You can expand the root filesystem (eg. into spare space or
across block devices).
- You can live pvmove filesystems from one device to another.
It may be that the tooling is not there to make these features
available for non-experts, but that's a problem with lack of tools,
not with LVM. Partition tables are horrible and inflexible in
comparison to LVM.
Can we at the very least have some numbers backing up the supposed
performance problems?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
6:14 p.m.
On Sat, 13.11.10 23:41, Richard W.M. Jones (rjones(a)redhat.com) wrote:
On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B. Guðmundsson" wrote:
> *DE could consider switching the default to use EXT4 directly without
> LVM. [1]
> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
Anyway, I think LVM is jolly useful:
- You can expand the root filesystem (eg. into spare space or
across block devices).
- You can live pvmove filesystems from one device to another.
It may be that the tooling is not there to make these features
available for non-experts, but that's a problem with lack of tools,
not with LVM. Partition tables are horrible and inflexible in
comparison to LVM.
Well, there's no doubt that LVM has its uses, but that doesn't mean we
should install it by default on every Fedora installation.
LVM actually slows down boot considerably. Not primarily because its
code was slow or anything, but simply because it isn't really written in
the way that things are expected to work these days. The LVM assembly at
boot is expected to be run at a time where all disks have been found by
the kernel and identified. However, the idea that such a time exists is
out-of-date on modern systems. There is simply no point in time where
all disks have been enumerated, because they can always come and go and
on many busses (for example USB), you never know whether you have
enumerated all devices, because the bus doesn't support a notion like
that. The right way how to implement a logic like this is to wait
exactly until all disks actually *needed* have shown up and at that time
assemble LVM. Currently, to make LVM work, we however try to wait until
*everything* thinkable is enumerated, not only the disks that are
actually needed. The fact that on many busses this point in time doesn't
really exist is ignored, and awful hacks such as "modprobe
scsi_wait_scan" are used to work around this out-of-date design on the
other busses. To get to a fast system however, you should minimize the
time you waste and continue withthe next step of booting the moment you
have collected all devices you need for assembly.
We definitely should stop setting up LVM by default on Fedora, because
it allows us to disable these unnecessary enumeration delays that are
broken by design anyway.
If we don't have LVM on default installs, we also don't need
scsi_wait_scan anymore, and that would be great.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:56 p.m.
On Sun, 2010-11-14 at 01:14 +0100, Lennart Poettering wrote:
LVM actually slows down boot considerably. Not primarily because its
code was slow or anything, but simply because it isn't really written in
the way that things are expected to work these days.
This is true and all. But it's easily worked around by keeping /boot on
a non-LVM partition.
I use a LVM setup and it works flawlessly. /boot on ext2, and / on LVM
ext4. And you can't really complain at a 5-6 second boot time with the
aforementioned setup.
There's absolutely no reason to remain on old style DOS partitioning
setups on Linux.
Regards
--
Chris Jones
PHOTO RESOLUTIONS - Photo - Graphic - Web
ABN: 98 317 740 240
@: chrisjones(a)comcen.com.au
WWW: http://photoresolutions.freehostia.com
7:58 p.m.
On Sun, 2010-11-14 at 10:56 +1000, Chris Jones wrote:
On Sun, 2010-11-14 at 01:14 +0100, Lennart Poettering wrote:
> LVM actually slows down boot considerably. Not primarily because its
> code was slow or anything, but simply because it isn't really written in
> the way that things are expected to work these days.
This is true and all. But it's easily worked around by keeping /boot on
a non-LVM partition.
I use a LVM setup and it works flawlessly. /boot on ext2, and / on LVM
ext4. And you can't really complain at a 5-6 second boot time with the
aforementioned setup.
There's absolutely no reason to remain on old style DOS partitioning
setups on Linux.
As I read lennart's post, he's talking about regular old init, after the
kernel and initrd have come up. so what you do with /boot is irrelevant.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:15 a.m.
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote:
LVM actually slows down boot considerably. Not primarily because its
code was slow or anything, but simply because it isn't really written in
the way that things are expected to work these days. The LVM assembly at
boot is expected to be run at a time where all disks have been found by
the kernel and identified. However, the idea that such a time exists is
out-of-date on modern systems. There is simply no point in time where
all disks have been enumerated, because they can always come and go and
on many busses (for example USB), you never know whether you have
enumerated all devices, because the bus doesn't support a notion like
that. The right way how to implement a logic like this is to wait
exactly until all disks actually *needed* have shown up and at that time
assemble LVM. Currently, to make LVM work, we however try to wait until
*everything* thinkable is enumerated, not only the disks that are
actually needed. The fact that on many busses this point in time doesn't
really exist is ignored, and awful hacks such as "modprobe
scsi_wait_scan" are used to work around this out-of-date design on the
other busses. To get to a fast system however, you should minimize the
time you waste and continue withthe next step of booting the moment you
have collected all devices you need for assembly.
Thanks for explaining what the "assembly" issue is all about.
I'd really like to hear from an LVM expert or two about this, because
I can't believe that it's impossible to make this work better for the
common single-disk-is-boot-disk single-PV case. The LVM metadata
(which I've written code to read and decode in the past) contains the
information needed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
10:37 a.m.
On Sun, Nov 14, 2010 at 10:15:20AM +0000, Richard W.M. Jones wrote:
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote:
> LVM actually slows down boot considerably. Not primarily because its
> code was slow or anything, but simply because it isn't really written in
> the way that things are expected to work these days.
Almost - the delays are not any fundamental part of LVM2 itself, but
come about from the simplistic way it is called by scripts during
startup.
"Wait a long time for things to settle, then see what storage we can
assemble and hope we can see all the bits we need."
If instead you defined rules about what to activate and when, you could
switch to an event-driven mechanism hooked into udev:
"When you see the whole of the Volume Group called rootvg, activate it."
I once had a discussion about how we would incorporate this into upstart,
but it was never a priority and I don't think anything happened about
it.
> The LVM assembly at
> boot is expected to be run at a time where all disks have been found by
> the kernel and identified.
(Again, that's just a constraint imposed by the current scripts, not
anything fundamental to LVM.)
> The right way how to implement a logic like this is to wait
> exactly until all disks actually *needed* have shown up and at that time
> assemble LVM.
Absolutely! (On a VG-by-VG basis.)
> Currently, to make LVM work, we however try to wait until
> *everything* thinkable is enumerated, not only the disks that are
> actually needed.
A convenience - it makes the scripts simpler - but not a necessity.
(And lvm2 can be - and is being slowly - improved to make it easier for
such scripts.)
I'd really like to hear from an LVM expert or two about this,
because
I can't believe that it's impossible to make this work better for the
common single-disk-is-boot-disk single-PV case. The LVM metadata
(which I've written code to read and decode in the past) contains the
information needed.
It's just about differing priorities not helped by responsibilities
being split between developers of different packages.
An example of the way I see it working is like this:
Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing Logical
Volume LV1 containing the root filesystem.
You have a trigger rule saying "When you see the whole of VG1, activate LV1
inside it" and another saying "When you see the filesystem with UUID X, mount
it." (Default rules can be generic of course, like 'activate any VG when you
see it' and 'activate any LV when you see it' and 'mount any filesystem
when
you see it'.)
Device containing PV1 appears on system.
Kernel sends uevent.
udev rules ask each storage subsystem in turn "Is this yours?"
- lvm2 subsystem spots the PV signature and claims ownership of it. It
caches the LVM metadata from it.
- Rule check performed but no rules match.
Device containing PV2 appears on system.
Kernel sends uevent.
udev rules ask each storage subsystem in turn "Is this yours?"
- lvm2 subsystem spots the PV signature and claims ownership of it. It caches the LVM
metadata from it.
- The rule to activate LV1 when the whole of VG1 is seen is triggered.
LV1 is activated.
Kernel sends uevent for arrival of the new VG1-LV1 block device on the system.
udev rules ask each storage subsystem in turn "Is this yours?"
- lvm2 subsystem finds no signature and answers "No."
- filesystem subsystem spots the filesystem signature and claims ownership.
- The rule to mount the (root) filesystem is triggered.
In summary:
Each block device on the system has (at most) one owning subsystem
recorded in a single database. (perhaps based around libblkid)
Storage subsystems may support actions like "scan" and "activate".
Udev rules trigger "scan".
The exact nature of the abstractions used by the triggers would need
further exploration. (Storage-subsystem-specific handling - central
'blob' cache, general triggers vs. private caches, private triggers.)
Alasdair
2:26 a.m.
Alasdair G Kergon wrote:
An example of the way I see it working is like this:
Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing Logical
Volume LV1 containing the root filesystem.
You have a trigger rule saying "When you see the whole of VG1, activate LV1
inside it" and another saying "When you see the filesystem with UUID X, mount
it." (Default rules can be generic of course, like 'activate any VG when you
see it' and 'activate any LV when you see it' and 'mount any filesystem
when
you see it'.)
Nice.
You still need a timeout to avoid waiting for ever for the root filesystem
to appear when one of the PV has been disconnected from the system.
But this "lost hope" timeout is a lot better than the current "wait in any
case"
one.
--
Roberto Ragusa mail at robertoragusa.it
8:34 a.m.
Hi.
On Sun, 21 Nov 2010 09:26:58 +0100, Roberto Ragusa wrote
You still need a timeout to avoid waiting for ever for the root
filesystem to appear when one of the PV has been disconnected from
the system.
If you cannot assemble the root file system, what is init supposed to
do instead of waiting forever?
9:27 a.m.
Ralf Ertzinger wrote:
Hi.
On Sun, 21 Nov 2010 09:26:58 +0100, Roberto Ragusa wrote
> You still need a timeout to avoid waiting for ever for the root
> filesystem to appear when one of the PV has been disconnected from
> the system.
If you cannot assemble the root file system, what is init supposed to
do instead of waiting forever?
Print some kind of error "unable to find root (UUID=xxxxx)" and/or reboot
or give you some kind of shell if there is enough rescue environment
to let a prompt to be in some way useful.
--
Roberto Ragusa mail at robertoragusa.it
6:14 a.m.
Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a écrit :
Well, there's no doubt that LVM has its uses, but that
doesn't mean we
should install it by default on every Fedora installation.
LVM actually slows down boot considerably. Not primarily because its
code was slow or anything, but simply because it isn't really written in
the way that things are expected to work these days.
But wasn"t systemd supposed to fix this kind of problem (dumping things
overboard is not fixing) ? LVM may not be very useful on single-hdd
laptops, but on desktops it makes adding/changing disks really easy.
--
Nicolas Mailhot
7:57 a.m.
On Sun, 14.11.10 13:14, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:
Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a
écrit :
> Well, there's no doubt that LVM has its uses, but that doesn't mean we
> should install it by default on every Fedora installation.
>
> LVM actually slows down boot considerably. Not primarily because its
> code was slow or anything, but simply because it isn't really written in
> the way that things are expected to work these days.
But wasn"t systemd supposed to fix this kind of problem (dumping things
overboard is not fixing) ? LVM may not be very useful on single-hdd
laptops, but on desktops it makes adding/changing disks really easy.
systemd is definitely not going into the realms of storage assembly.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:48 p.m.
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote:
We definitely should stop setting up LVM by default on Fedora,
because
it allows us to disable these unnecessary enumeration delays that are
broken by design anyway.
If we don't have LVM on default installs, we also don't need
scsi_wait_scan anymore, and that would be great.
Wow.
LVM is important and useful for managing storage. If, in the future, we have
ZFS-like features in btrfs or whatever, okay, we can talk about getting rid
of it. But a few-second gain in boot time is really, really, really not
worth it. And yeah, I mean the desktop/laptop case, not just servers. (In
fact, with suspend/hibernate working so well these days, I think I reboot my
servers more often than my laptop.)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:41 p.m.
On Sun, Nov 14, 2010 at 07:48:36PM -0500, Matthew Miller wrote:
LVM is important and useful for managing storage. If, in the future,
we have
ZFS-like features in btrfs or whatever, okay, we can talk about getting rid
of it. But a few-second gain in boot time is really, really, really not
worth it. And yeah, I mean the desktop/laptop case, not just servers. (In
fact, with suspend/hibernate working so well these days, I think I reboot my
servers more often than my laptop.)
LVM's a fantasically useful tool in a wide range of cases, but I don't
think that in the *typical* laptop/desktop install any of that
functionality ever gets used. The question is really whether there's
enough people that know nothing about LVM at install time but will make
use of it later that doing it by default is beneficial - if not, there's
a reasonable argument for it being a well-tested optional feature at
least, although it would obviously be preferable to address its
shortcomings to the point where there's no desire to do so. But that
would involve someone who understands the issues sufficiently to be
doing the work.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:53 a.m.
On 11/15/2010 02:41 AM, Matthew Garrett wrote:
LVM's a fantasically useful tool in a wide range of cases, but I
don't
think that in the*typical* laptop/desktop install any of that
functionality ever gets used.
That's the essence of what's being discussed here
laptop/desktop/workstation installs default to ext4 and experienced
users/sysadmins those that generally know what lvm is with all it's
bells and whistles and want to use it will choose it during installation.
Those that claim that novice end users have no problem using LVM I want
them to perform just this very simple case of two person sharing what
ever data between themselves could be family photo music video and what not.
Partition an external connected HD that you got laying around with LVM.
Hand that drive to the novice end user running GNU/Linux on
laptop/desktop/workstation ( if he's not you can just insert a live cd
and boot from it ) and ask him to copy a single file to that drive no
more no less.
Take note on how many obstacle are in the users way from performing this
simple yet commonly used test case.
Repeate process this time with ext4 only for comparison.
After performing this simple test case and you have gathered the
necessary data revisit the topic of how easy it is for the novice end
user to use LVM and if he will ever use what ever tools we provide him
with to take advantage of all the features LVM brings and if it makes
sense to default to it.
JBG
5:29 a.m.
On Mon, Nov 15, 2010 at 08:53:03AM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/15/2010 02:41 AM, Matthew Garrett wrote:
>LVM's a fantasically useful tool in a wide range of cases, but I don't
>think that in the*typical* laptop/desktop install any of that
>functionality ever gets used.
That's the essence of what's being discussed here
laptop/desktop/workstation installs default to ext4 and experienced
users/sysadmins those that generally know what lvm is with all it's
bells and whistles and want to use it will choose it during
installation.
Those that claim that novice end users have no problem using LVM I
want them to perform just this very simple case of two person
sharing what ever data between themselves could be family photo
music video and what not.
Partition an external connected HD that you got laying around with LVM.
Hand that drive to the novice end user running GNU/Linux on
laptop/desktop/workstation ( if he's not you can just insert a live
cd and boot from it ) and ask him to copy a single file to that
drive no more no less.
Take note on how many obstacle are in the users way from performing
this simple yet commonly used test case.
Repeate process this time with ext4 only for comparison.
After performing this simple test case and you have gathered the
necessary data revisit the topic of how easy it is for the novice
end user to use LVM and if he will ever use what ever tools we
provide him with to take advantage of all the features LVM brings
and if it makes sense to default to it.
This is a silly straw-man. No one[1] formats external HDs with
anything other than MS-DOS FAT. Fedora changing the default for the
main hard disk will not make any difference to this case of your
contrarian user giving away LVM-formatted USB drives.
Rich.
[1] for a sufficiently small value
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
6:04 a.m.
On 11/15/2010 11:29 AM, Richard W.M. Jones wrote:
This is a silly straw-man. No one[1] formats external HDs with
anything other than MS-DOS FAT. Fedora changing the default for the
main hard disk will not make any difference to this case of your
contrarian user giving away LVM-formatted USB drives.
Agreed kinda bad example on my behalf since I based it on real live
scenario in which I had been approached by a not so experienced Linux
user which actually had formatting and partition his external drive as
LVM ( and was having trouble with it ) and when I asked why he choose to
format and partition with LVM he said and I quote " I just took look at
how it was setup on my desktop so I decided to create the same since I
expected it would just work if I plugged it to another Linux box I had
setup at home".
I'll have it in mind next time I mention a simple test case that it
should be targeted against mixed OS environments instead of having it
solely focusing on easy of use and interoperability between Linux
implementations.
JBG
7:54 a.m.
On Mon, Nov 15, 2010 at 11:29:06AM +0000, Richard W.M. Jones wrote:
This is a silly straw-man. No one[1] formats external HDs with
anything other than MS-DOS FAT. Fedora changing the default for the
main hard disk will not make any difference to this case of your
contrarian user giving away LVM-formatted USB drives.
Rich.
[1] for a sufficiently small value
there are very good reasons to use anything but DOS-FAT. For example
F10 and F12 automount said filesystems with drastically different options
by default (filename downcasing), using any other FS avoids this trap
and many other issues.
Richard
8:03 a.m.
New subject: External HD fs was: Re: Fedora 15, new and exciting plans
On 15/11/10 13:54, Richard Zidlicky wrote:
<snip>
there are very good reasons to use anything but DOS-FAT. For example
F10 and F12 automount said filesystems with drastically different options
by default (filename downcasing), using any other FS avoids this trap
and many other issues.
Richard
What would you reccomend?
That would attched itself nicely
to Win <=7, and Mac <=Leopard
out of the box (so to speak)
Without being expelled from College.
(we're talking Linux is evil incarnate territory)
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of Fedora
8:39 a.m.
New subject: External HD fs was: Re: Fedora 15, new and exciting plans
On 11/15/2010 02:03 PM, Frank Murphy wrote:
On 15/11/10 13:54, Richard Zidlicky wrote:
<snip>
> there are very good reasons to use anything but DOS-FAT. For example
> F10 and F12 automount said filesystems with drastically different options
> by default (filename downcasing), using any other FS avoids this trap
> and many other issues.
>
> Richard
>
What would you reccomend?
That would attched itself nicely
to Win<=7, and Mac<=Leopard
out of the box (so to speak)
Without being expelled from College.
(we're talking Linux is evil incarnate territory)
I think you got things backwards which is perhaps because we have gotten
so used to chasing other OSes that we have lost focus on the fact we are
trying to create good usable desktop on GNU/Linux and we should turn our
focus on Linux and start by fixing all interoperability issues and
improve the ease of use and sharing between 2 Linux desktops ( and
various *DE ) when we have done that we can start looking at
interoperability issues with other OSes.
To my knowledge there is nothing preventing other OS to support all the
LinuxFS out there and until they choose to do so users of such OS will
simply have to install tools like ext2read [1] ( Windows 7 ) if they
want to access files on devices that have LinuxFS on them.
I assume that OS-X has not trouble with mounting various LinuxFS given
that it is a *nix breed.
JBG
1. http://ext2read.blogspot.com/
2. http://sourceforge.net/projects/ext2read/
9:55 a.m.
New subject: External HD fs was: Re: Fedora 15, new and exciting plans
On 11/15/10 8:39 AM, "Jóhann B. Guðmundsson" wrote:
I assume that OS-X has not trouble with mounting various LinuxFS
given
that it is a *nix breed.
Being unix-ish doesn't really help, you need an actual filesystem driver
for the OS. There is an ext2/ext3 driver for osx (based on the bsd driver
I think) but that's about as far as it goes.
-Eric
11:39 a.m.
New subject: External HD fs was: Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 02:03:03PM +0000, Frank Murphy wrote:
On 15/11/10 13:54, Richard Zidlicky wrote:
<snip>
>
> there are very good reasons to use anything but DOS-FAT. For example
> F10 and F12 automount said filesystems with drastically different options
> by default (filename downcasing), using any other FS avoids this trap
> and many other issues.
>
> Richard
>
What would you reccomend?
That would attched itself nicely
to Win <=7, and Mac <=Leopard
out of the box (so to speak)
ironically, a few months ago I really needed interoperability with some kind
of Windows. So I formatted 2 USB sticks using fdisk and mkdosfs taking special
care to make it look as close as possible as the normal USB stick partition
table - the other users windows did not read it anyway.
So Fedora is definitely evil and perhaps if I had used ext2 the interoperability
would have been better - the user would just download the fs driver or one of the
userspace windows solutions and it would work.
Richard
8:09 a.m.
On Monday, 15 November 2010 at 12:29, Richard W.M. Jones wrote:
[...]
This is a silly straw-man. No one[1] formats external HDs with
anything other than MS-DOS FAT. Fedora changing the default for the
main hard disk will not make any difference to this case of your
contrarian user giving away LVM-formatted USB drives.
I'd think NTFS would be much more common, if only for its ability
to store files larger than 4GB.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:35 p.m.
On 11/18/2010 8:09, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 15 November 2010 at 12:29, Richard W.M. Jones wrote:
[...]
> This is a silly straw-man. No one[1] formats external HDs with
> anything other than MS-DOS FAT. Fedora changing the default for the
> main hard disk will not make any difference to this case of your
> contrarian user giving away LVM-formatted USB drives.
I'd think NTFS would be much more common, if only for its ability
to store files larger than 4GB.
UDF can be a useful alternative since Windows >= Vista, RHEL >= 5, and
Fedora handle it perfectly. Windows XP can read it. OS X can also use
it read/write, but you have to manually mount it first.
8:15 a.m.
On Mon, Nov 15, 2010 at 08:53:03AM +0000, "Jóhann B. Guðmundsson" wrote:
That's the essence of what's being discussed here
laptop/desktop/workstation installs default to ext4 and experienced
users/sysadmins those that generally know what lvm is with all it's bells
and whistles and want to use it will choose it during installation.
Strongly no to this. We need to have fewer choices during the installation
and more flexibility later. LVM provides this.
Those that claim that novice end users have no problem using LVM I
want
them to perform just this very simple case of two person sharing what ever
data between themselves could be family photo music video and what not.
Partition an external connected HD that you got laying around with LVM.
This case not install-time, and so is completely irrelevant.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:03 a.m.
On 11/15/2010 02:15 PM, Matthew Miller wrote:
On Mon, Nov 15, 2010 at 08:53:03AM +0000, "Jóhann B.
Guðmundsson" wrote:
> > That's the essence of what's being discussed here
> > laptop/desktop/workstation installs default to ext4 and experienced
> > users/sysadmins those that generally know what lvm is with all it's bells
> > and whistles and want to use it will choose it during installation.
Strongly no to this. We need to have fewer choices during the installation
and more flexibility later. LVM provides this.
So we agree on disagreeing.
Let's go the middle path here what about we default to ext4 but on the
partition scene in Anaconda you can choose to partition with LVM and
even btrfs for that matter if it is doable that is? ( User still has to
select/confirm "partitioning" adding these option to choose from there
should not be a burden to him )
JBG
11:30 a.m.
On Mon, Nov 15, 2010 at 03:03:28PM +0000, "Jóhann B. Guðmundsson" wrote:
> Strongly no to this. We need to have fewer choices during the
installation
> and more flexibility later. LVM provides this.
So we agree on disagreeing.
Let's go the middle path here what about we default to ext4 but on the
partition scene in Anaconda you can choose to partition with LVM and
even btrfs for that matter if it is doable that is? ( User still has to
select/confirm "partitioning" adding these option to choose from there
should not be a burden to him )
How is that a middle path? That's doing it exactly wrong.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
1:14 p.m.
On 11/15/2010 05:30 PM, Matthew Miller wrote:
On Mon, Nov 15, 2010 at 03:03:28PM +0000, "Jóhann B.
Guðmundsson" wrote:
>> Strongly no to this. We need to have fewer choices during the installation
>> and more flexibility later. LVM provides this.
> So we agree on disagreeing.
>
> Let's go the middle path here what about we default to ext4 but on the
> partition scene in Anaconda you can choose to partition with LVM and
> even btrfs for that matter if it is doable that is? ( User still has to
> select/confirm "partitioning" adding these option to choose from there
> should not be a burden to him )
How is that a middle path? That's doing it exactly wrong.
Depends on how you look at it.
I mean if users are incapable of actually using the already provided
custom partition layout and choose there to use lvm but they are
experienced user and would be taking advantage of all the bells and
whistle lvm provides there would be an option for them to choose it
right in front of them and we still could default to ext4 only install...
JBG
3:27 p.m.
On Mon, Nov 15, 2010 at 07:14:53PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/15/2010 05:30 PM, Matthew Miller wrote:
> On Mon, Nov 15, 2010 at 03:03:28PM +0000, "Jóhann B. Guðmundsson" wrote:
>>> Strongly no to this. We need to have fewer choices during the installation
>>> and more flexibility later. LVM provides this.
>> So we agree on disagreeing.
>>
>> Let's go the middle path here what about we default to ext4 but on the
>> partition scene in Anaconda you can choose to partition with LVM and
>> even btrfs for that matter if it is doable that is? ( User still has to
>> select/confirm "partitioning" adding these option to choose from
there
>> should not be a burden to him )
> How is that a middle path? That's doing it exactly wrong.
Depends on how you look at it.
I mean if users are incapable of actually using the already provided
custom partition layout and choose there to use lvm but they are
experienced user and would be taking advantage of all the bells and
whistle lvm provides there would be an option for them to choose it
right in front of them and we still could default to ext4 only install...
Nobody has yet proven that LVM is a problem, and you just provided
some sort of weird case involving USB drives that has nothing to do
with the matter at hand. There's no "middle path" here (yet), just
the wrong path.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
5:15 p.m.
On 11/15/2010 09:27 PM, Richard W.M. Jones wrote:
Nobody has yet proven that LVM is a problem
Well if you don't consider what Lennart mentioned [1] as a con against
usage of lvm by default what pros do you see for having lvm by default
for the novice end user?
JBG
1. http://lists.fedoraproject.org/pipermail/devel/2010-November/145472.html
5:26 p.m.
On Mon, Nov 15, 2010 at 11:15:38PM +0000, "Jóhann B. Guðmundsson" wrote:
Well if you don't consider what Lennart mentioned [1] as a con
against
usage of lvm by default what pros do you see for having lvm by default
for the novice end user?
When the novice end user realizes that they made some poor storage decisions
initially, they can, with a little learning, fix it without much hassle.
I have a system which, for silly reasons, I did not use LVM, and then ended
up having change a separately-mounted /usr, and now (in a sort of irony,
considering this thread) can't shut down cleanly under systemd. Awesome.
I'm not particularly attached to LVM as a specific technology, but we need
something with equivalent functionality before we ditch it.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:21 a.m.
On Mon, Nov 15, 2010 at 06:26:27PM -0500, Matthew Miller wrote:
On Mon, Nov 15, 2010 at 11:15:38PM +0000, "Jóhann B.
Guðmundsson" wrote:
> Well if you don't consider what Lennart mentioned [1] as a con against
> usage of lvm by default what pros do you see for having lvm by default
> for the novice end user?
When the novice end user realizes that they made some poor storage decisions
initially, they can, with a little learning, fix it without much hassle.
I have a system which, for silly reasons, I did not use LVM, and then ended
up having change a separately-mounted /usr, and now (in a sort of irony,
considering this thread) can't shut down cleanly under systemd. Awesome.
I'm not particularly attached to LVM as a specific technology, but we need
something with equivalent functionality before we ditch it.
It also takes a decision out of the mix when a user buys a new drive. They can
just dump it in the volume group rather than having to learn how to place it at
a mountpoint and migrate data (the actual commands are no big deal. Learning to
weigh the costs and benefits of applying your new 1TB disk to /usr vs /home
isn't).
Its a usecase that matters to an interesting class of user: the petty power
user. They help Aunt Tillie with her computer. They built their own computer.
They think of themselves as quite tech-savvy. They are also liable to say
things like "If linux is so great why can't it even run normal programs?"
LVM is nice in that it accomodates this generally unpleasent sort of person
(who is much improved by education and has the potential to become a great
contributor once humbled and made willing to learn) though it does this by
offering a temporary crutch.
--CJD
4:08 a.m.
Le Mar 16 novembre 2010 00:15, "Jóhann B. Guðmundsson" a écrit :
On 11/15/2010 09:27 PM, Richard W.M. Jones wrote:
> Nobody has yet proven that LVM is a problem
Well if you don't consider what Lennart mentioned [1] as a con against
usage of lvm by default
The con was the assumption that LVM init could not be fixed.
And this was completely disproved later
http://lists.fedoraproject.org/pipermail/devel/2010-November/145554.html
LVM can and should be fixed at the init level (brtfs is only going to overlap
with a little part of was LVM does, so taking it as an excuse to avoid fixing
lvm init is wrong)
--
Nicolas Mailhot
8:23 p.m.
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote:
On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B.
Guðmundsson" wrote:
> *DE could consider switching the default to use EXT4 directly without
> LVM. [1]
> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
The "Detailed Description" seems contradictory:
| LVM provides very little benefit for most Fedora users, at the cost of
| performance and complexity:
|
| * Certain filesystem features (ext3 barriers) are unavailable when run
| on top of LVM.
Isn't this just a bug which should be fixed? (I actually thought this
had been fixed already)
| * Software RAID performance is greatly reduced when layered on LVM.
But the stated task is to get rid of LVM except for "experts in
storage administration" (from the next section of the same document).
Who will presumably be the only ones wanting Software RAID. The
non-experts won't know anything about Software RAID, so they won't be
affected by this performance problem with LVM.
Can someone point to specific details about this? I did some benchmarking a
while ago of raid-1 vs. raid-5, raid-1 plain vs. raid-1 with lvm, etc. and
LVM didn't really show up as a performance issue at all.
| * LVM partitions are not automatically assembled by the desktop
systems.
I'm not sure what this one means. "assembled" as in what happens when
you spread a VG over multiple block devices?
Anyway, I think LVM is jolly useful:
I've used plain partitions for a long time because lvm always looked weird
to me but then I looked into it and nowadays I don't want to live without
it. The ability to have the logical partitioning indepedent of the physical
storage is a must-have for me.
- You can expand the root filesystem (eg. into spare space or
across block devices).
- You can live pvmove filesystems from one device to another.
That one actually saved my ass once on a 48 disk 30TB storage system
because the controller was acting up.
It may be that the tooling is not there to make these features
available for non-experts, but that's a problem with lack of tools,
not with LVM. Partition tables are horrible and inflexible in
comparison to LVM.
Can we at the very least have some numbers backing up the supposed
performance problems?
Yeah, in my benchmarking I couldn't really confirm this so if there is a
problem I'd like to see some specifics too.
Regards,
Dennis
6:18 a.m.
Return to GRUB2 topic, I wish that GRUB2 landed in Anaconda and become an
option for user. Some Linux fans install two Linux distros, one is rpm-based
distro, another is deb-based distro. Most of deb-based distros has moved to
GRUB2. however, rpm-based distros still stays at GRUB legacy. I can feel
there are some problems on compatibility.
Does anyone know something about GRUB2 on mapper devices? Half a year ago, I
tried to install Debian on my Intel RAID0 but failed. At that time, Debian
installer does not support that users directly install GRUB2. You need extra
steps to do it manually. I think the maintainers should consider it and
find out the best solution for users.
The other topic is about Xen. As we know, Xen Dom0 pv_ops are merged into
the upstream kernel since 2.6.37. Fedora 15 will use kernel-2.6.38. Should
community bring Xen Dom0 to Fedora 15 since Fedora 8 though Red Hat does no
longer support Xen? Because Xen Dom0 pv_ops is a part of upstream kernel,
Debian has a plan to drop specified kernel for Xen and directly support it
in generic kernel. Does Fedora has some plans to do it? I know Xen is still
maintained by myong in Fedora.
On Sun, Nov 14, 2010 at 10:23 AM, Dennis Jacobfeuerborn <
dennisml(a)conversis.de> wrote:
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote:
> On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B. Guðmundsson" wrote:
>> *DE could consider switching the default to use EXT4 directly without
>> LVM. [1]
>> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
>
> The "Detailed Description" seems contradictory:
>
> | LVM provides very little benefit for most Fedora users, at the cost of
> | performance and complexity:
> |
> | * Certain filesystem features (ext3 barriers) are unavailable when run
> | on top of LVM.
>
> Isn't this just a bug which should be fixed? (I actually thought this
> had been fixed already)
>
> | * Software RAID performance is greatly reduced when layered on LVM.
>
> But the stated task is to get rid of LVM except for "experts in
> storage administration" (from the next section of the same document).
> Who will presumably be the only ones wanting Software RAID. The
> non-experts won't know anything about Software RAID, so they won't be
> affected by this performance problem with LVM.
Can someone point to specific details about this? I did some benchmarking a
while ago of raid-1 vs. raid-5, raid-1 plain vs. raid-1 with lvm, etc. and
LVM didn't really show up as a performance issue at all.
> | * LVM partitions are not automatically assembled by the desktop
systems.
>
> I'm not sure what this one means. "assembled" as in what happens
when
> you spread a VG over multiple block devices?
>
> Anyway, I think LVM is jolly useful:
I've used plain partitions for a long time because lvm always looked weird
to me but then I looked into it and nowadays I don't want to live without
it. The ability to have the logical partitioning indepedent of the physical
storage is a must-have for me.
> - You can expand the root filesystem (eg. into spare space or
> across block devices).
>
> - You can live pvmove filesystems from one device to another.
That one actually saved my ass once on a 48 disk 30TB storage system
because the controller was acting up.
> It may be that the tooling is not there to make these features
> available for non-experts, but that's a problem with lack of tools,
> not with LVM. Partition tables are horrible and inflexible in
> comparison to LVM.
>
> Can we at the very least have some numbers backing up the supposed
> performance problems?
Yeah, in my benchmarking I couldn't really confirm this so if there is a
problem I'd like to see some specifics too.
Regards,
Dennis
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
6:31 a.m.
On 14/11/10 12:18, Liang Suilong wrote:
Return to GRUB2 topic, I wish that GRUB2 landed in Anaconda and
become
an option for user. Some Linux fans install two Linux distros, one is
rpm-based distro, another is deb-based distro. Most of deb-based distros
has moved to GRUB2. however, rpm-based distros still stays at GRUB
legacy. I can feel there are some problems on compatibility.
Have been testing on bare and vm's, have been haing trouble with it.
with grub1 you edit /boot/grub/menu.lst to get some tweaks set
permanently, or enter on the fly during bootup.
with grub2, tested both chainloaded with grub1, and with yum erase grub.
Though it found updated kernels', it never booted them unless
"grub2-mkconfig -o /boot/grub2/grub.cfg" was run manually.
It also requires edits in a number of files,
to get permanent tweaks instead of one simple file.
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of Fedora
9:57 a.m.
On Sun, Nov 14, 2010 at 12:41 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B.
Guðmundsson" wrote:
> *DE could consider switching the default to use EXT4 directly without
> LVM. [1]
> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
The "Detailed Description" seems contradictory:
| LVM provides very little benefit for most Fedora users, at the cost of
| performance and complexity:
|
| * Certain filesystem features (ext3 barriers) are unavailable when run
| on top of LVM.
Isn't this just a bug which should be fixed? (I actually thought this
had been fixed already)
| * Software RAID performance is greatly reduced when layered on LVM.
But the stated task is to get rid of LVM except for "experts in
storage administration" (from the next section of the same document).
Who will presumably be the only ones wanting Software RAID. The
non-experts won't know anything about Software RAID, so they won't be
affected by this performance problem with LVM.
| * LVM partitions are not automatically assembled by the desktop systems.
I'm not sure what this one means. "assembled" as in what happens when
you spread a VG over multiple block devices?
Anyway, I think LVM is jolly useful:
- You can expand the root filesystem (eg. into spare space or
across block devices).
- You can live pvmove filesystems from one device to another.
It may be that the tooling is not there to make these features
available for non-experts, but that's a problem with lack of tools,
not with LVM. Partition tables are horrible and inflexible in
comparison to LVM.
Can we at the very least have some numbers backing up the supposed
performance problems?
Something else to add to the list: Does not support discard (aka TRIM)
when using SSDs which hurts performance and lifetime of said drives.
10:41 a.m.
On 11/14/2010 09:57 AM, drago01 wrote:
Something else to add to the list: Does not support discard (aka
TRIM)
when using SSDs which hurts performance and lifetime of said drives.
I have a btrfs file system inside of a LVM inside of a software RAID0
array on two Intel SSDs mounted with "discard" enabled. Am I being lied
to about discard being enabled?
10:42 a.m.
On Sun, Nov 14, 2010 at 5:41 PM, Michael Cronenworth <mike(a)cchtml.com> wrote:
On 11/14/2010 09:57 AM, drago01 wrote:
> Something else to add to the list: Does not support discard (aka TRIM)
> when using SSDs which hurts performance and lifetime of said drives.
I have a btrfs file system inside of a LVM inside of a software RAID0
array on two Intel SSDs mounted with "discard" enabled. Am I being lied
to about discard being enabled?
Yes unless something changed recently the filesystem's discard command
never reaches the drive.
3:07 p.m.
On 11/14/2010 05:44 PM, Michael Cronenworth wrote:
On 11/14/2010 10:42 AM, drago01 wrote:
> Yes unless something changed recently the filesystem's discard command
> never reaches the drive.
Looks like I'm reformatting and dumping the LVM. Thanks.
You should also file a bug against the tool that told you that discard
support is available.
Regards,
Dennis
3:11 p.m.
On Sun, 14 Nov 2010 10:41:00 -0600, Michael Cronenworth wrote:
On 11/14/2010 09:57 AM, drago01 wrote:
I have a btrfs file system inside of a LVM inside of a software RAID0
array on two Intel SSDs mounted with "discard" enabled. Am I being lied
to about discard being enabled?
You probably want to use btrfs's own soft RAID rather than md-raid.
Regards,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12:38 p.m.
On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
Anyway, I think LVM is jolly useful:
[stated advantages
snipped]
One design error is that you cannot "carve out" an ordinary partition
from an LVM. Once a portion of the drive is LVM, then that portion of
the drive is LVM forever until the LVM is completely gone.
This makes LVM a bad neighbor in a consulting environment where
flexibility is king: multiple systems per drive, and many of
the systems do not understand LVM.
--
1:07 p.m.
On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote:
On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
> Anyway, I think LVM is jolly useful:
[stated advantages snipped]
One design error is that you cannot "carve out" an ordinary partition
from an LVM. Once a portion of the drive is LVM, then that portion of
the drive is LVM forever until the LVM is completely gone.
That's not true. You can shrink the PV with pvresize and then create
any desired partitions in the resulting space. Or did you mean
something different?
--
Matt
1:14 p.m.
On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote:
On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote:
> On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
>
> > Anyway, I think LVM is jolly useful:
> [stated advantages snipped]
>
> One design error is that you cannot "carve out" an ordinary partition
> from an LVM. Once a portion of the drive is LVM, then that portion of
> the drive is LVM forever until the LVM is completely gone.
That's not true. You can shrink the PV with pvresize and then create
any desired partitions in the resulting space.
Oops, that's not completely true: pvresize currently is not smart enough
to move allocated data out of the area to be freed, according to its man
page. But you have other options, e.g., you can attach another disk,
create a PV on it, move the data there, rearrange the first disk as
desired, and move the data back, all while the system is running.
That's what's so fun about LVM.
--
Matt
2:59 p.m.
Matt McCutchen wrote:
On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote:
Oops, that's not completely true: pvresize currently is not smart enough
to move allocated data out of the area to be freed, according to its man
page. But you have other options, e.g., you can attach another disk,
create a PV on it, move the data there, rearrange the first disk as
desired, and move the data back, all while the system is running.
That's what's so fun about LVM.
Even if pvresize doesn't move allocated data, you can do that
with pvmove, and you do not need to move everything out of the PV,
just the part you are going to truncate (PEs can be specified).
I don't remember if pvmove can use the same PV as src and dest;
in that case you could avoid the need of an extra disk
when your PV is just "fragmented".
--
Roberto Ragusa mail at robertoragusa.it
3:45 p.m.
Once upon a time, Roberto Ragusa <mail(a)robertoragusa.it> said:
I don't remember if pvmove can use the same PV as src and dest;
in that case you could avoid the need of an extra disk
when your PV is just "fragmented".
You can; you have to specify manually the source and destination PEs,
and IIRC there's an extra option required to force it.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:07 p.m.
On 11/14/2010 11:07 AM, Matt McCutchen wrote:
On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote:
> On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
>
>> Anyway, I think LVM is jolly useful:
> [stated advantages snipped]
>
> One design error is that you cannot "carve out" an ordinary partition
> from an LVM. Once a portion of the drive is LVM, then that portion of
> the drive is LVM forever until the LVM is completely gone.
That's not true. You can shrink the PV with pvresize and then create
any desired partitions in the resulting space. Or did you mean
something different?
When I created 14 partitions using a DOS partition label
(3 primaries, plus extended containing 10 logical partitions)
and gave 6 of the partitions to an LVM setup,
then I could not remove one of the partitions from the clutches
of the LVM, and use the removed partition for some other purpose
(keeping the rest of the LVM going), unless I removed all the LVM
from that drive.
--
3:13 p.m.
New subject: Fedora 15, new and exciting plans (LVM issues)
On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote:
When I created 14 partitions using a DOS partition label
(3 primaries, plus extended containing 10 logical partitions)
and gave 6 of the partitions to an LVM setup,
then I could not remove one of the partitions from the clutches
of the LVM, and use the removed partition for some other purpose
(keeping the rest of the LVM going), unless I removed all the LVM
from that drive.
vgreduce + pvremove? Did something go wrong when you tried?
--
Matt
5 p.m.
New subject: Fedora 15, new and exciting plans (LVM issues)
On 11/14/2010 01:13 PM, Matt McCutchen wrote:
On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote:
> When I created 14 partitions using a DOS partition label
> (3 primaries, plus extended containing 10 logical partitions)
> and gave 6 of the partitions to an LVM setup,
> then I could not remove one of the partitions from the clutches
> of the LVM, and use the removed partition for some other purpose
> (keeping the rest of the LVM going), unless I removed all the LVM
> from that drive.
vgreduce + pvremove? Did something go wrong when you tried?
vgreduce would not let go of the partition that I wanted to take back,
claiming that the partition was still in use.
-----
DESCRIPTION
vgreduce allows you to remove one or more *unused* physical volumes
from a volume group. [emphasis added]
-----
I could not find a way to evict any usage of that partition (transparently
move the information somewhere else in the same LVM) as a prelude to applying
vgreduce. In theory I could have moved all of the LVM onto another drive,
but I wanted to keep the LVM going on that drive, with the same user-visible
information content [there was enough free space], but without using one
particular partition that I had given [loaned] to LVM some time before.
--
7:45 p.m.
New subject: Fedora 15, new and exciting plans (LVM issues)
On 11/15/2010 12:00 AM, John Reiser wrote:
On 11/14/2010 01:13 PM, Matt McCutchen wrote:
> On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote:
>> When I created 14 partitions using a DOS partition label
>> (3 primaries, plus extended containing 10 logical partitions)
>> and gave 6 of the partitions to an LVM setup,
>> then I could not remove one of the partitions from the clutches
>> of the LVM, and use the removed partition for some other purpose
>> (keeping the rest of the LVM going), unless I removed all the LVM
>> from that drive.
>
> vgreduce + pvremove? Did something go wrong when you tried?
vgreduce would not let go of the partition that I wanted to take back,
claiming that the partition was still in use.
-----
DESCRIPTION
vgreduce allows you to remove one or more *unused* physical volumes
from a volume group. [emphasis added]
-----
I could not find a way to evict any usage of that partition (transparently
move the information somewhere else in the same LVM) as a prelude to applying
vgreduce. In theory I could have moved all of the LVM onto another drive,
but I wanted to keep the LVM going on that drive, with the same user-visible
information content [there was enough free space], but without using one
particular partition that I had given [loaned] to LVM some time before.
pvmove is the command you need to use before doing a vgreduce. That's
basically what I did with the 30TB system that I mentioned elsewhere in
this thread. This system was partitioned into 10 raid-5 volumes and one of
those acted up when we put the system into production (it was already
pre-filled with data). So what I did was a pvmove to clear out the physical
volume which took a few hours and then I removed the physical volume from
the volume group. The fact that I could do all of this while the system
stayed online and was being used was a real life saver.
Regards,
Dennis
4:46 p.m.
On Sun, Nov 14, 2010 at 01:07:28PM -0800, John Reiser wrote:
On 11/14/2010 11:07 AM, Matt McCutchen wrote:
> On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote:
>> On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
>>
>>> Anyway, I think LVM is jolly useful:
>> [stated advantages snipped]
>>
>> One design error is that you cannot "carve out" an ordinary partition
>> from an LVM. Once a portion of the drive is LVM, then that portion of
>> the drive is LVM forever until the LVM is completely gone.
>
> That's not true. You can shrink the PV with pvresize and then create
> any desired partitions in the resulting space. Or did you mean
> something different?
When I created 14 partitions using a DOS partition label
(3 primaries, plus extended containing 10 logical partitions)
and gave 6 of the partitions to an LVM setup,
then I could not remove one of the partitions from the clutches
of the LVM, and use the removed partition for some other purpose
(keeping the rest of the LVM going), unless I removed all the LVM
from that drive.
Quite probably the PV contained some allocated PE. As another
respondant said, you can [manually, it is a little cumbersome with the
current tools] pvmove PEs around.
In any case I have no idea why you'd be using 14 partitions with MBR.
Really you should use GPT which resolves at least that shortcoming of
MBR. MBR logical partitions are vulnerable to an error in a single
sector completely wiping out the chain of logical partitions.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
4:42 p.m.
On Sun, Nov 14, 2010 at 10:38:37AM -0800, John Reiser wrote:
On 11/13/2010 03:41 PM, Richard W.M. Jones wrote:
> Anyway, I think LVM is jolly useful:
[stated advantages snipped]
One design error is that you cannot "carve out" an ordinary partition
from an LVM. Once a portion of the drive is LVM, then that portion of
the drive is LVM forever until the LVM is completely gone.
This makes LVM a bad neighbor in a consulting environment where
flexibility is king: multiple systems per drive, and many of
the systems do not understand LVM.
This is a problem of partitions themselves being very inflexible.
Have said that I don't really understand why you'd ever want to do
this. "In a consulting environment" you're much more likely to
encounter some other mechanism for creating LUNs of the right size on
demand, ie. SANs.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
8:46 p.m.
On Sun, Nov 14, 2010 at 10:42:05PM +0000, Richard W.M. Jones wrote:
This is a problem of partitions themselves being very inflexible.
Have said that I don't really understand why you'd ever want to do
this. "In a consulting environment" you're much more likely to
encounter some other mechanism for creating LUNs of the right size on
demand, ie. SANs.
It's also a problem of our user-friendly tools being woefully poor at
dealing with LVM. I can resize a filesystem-containing partition far
more straightforwardly than I can an LVM-containing one.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:02 a.m.
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote:
Info on this page is completely obsolete!
| * Certain filesystem features (ext3 barriers) are unavailable when
run
| on top of LVM.
No longer true, barriers (resp. flush) are fully supported with LVM now.
| * Software RAID performance is greatly reduced when layered on LVM.
Not true. The main performance problem was that sometimes LVM over RAID
created misaligned devices with huge performance loss.
Because both MD/DM subsystems now respects topology info and also use default
1MB alignment if there is not topology info, this is fixed.
Applies to LUKS too for FDE (full disk encryption).
Btw LVM over MD RAID is very common configuration.
Moreover LVM will not duplicate RAID functionality in kernel but will try
to use existing MD code (see dm-devel list track patches and for more info).
| * LVM partitions are not automatically assembled by the desktop
systems.
No idea where this come from? All required volumes are assembled.
Moreover, this is not lvm problem but problem in desktop extensions like udisks.
(Also image you attach iSCSI device with LVM with hundreds of LVs.
You probably do not want to activate everything automatically - this
is job for admin to setup such configurations.
Counterexample is USB disk - most of users want to activate it automatically.)
Also note:
- Discard/TRIM is supported for linear mappings and multipath in LVM in 2.6.37.
I am not sure if LVM default is good or not for Fedora but please do not use
obsolete arguments here - almost everything you are complaining about
was fixed or there are known ways how to improve or fix it
(like move scanning of devices in lvm to udev responsibility etc.)
You can replace some functionality with btrfs, but lvm+luks+raid+artbitrary fs
is still very flexible - maybe not for you but definitely for some users.
Thanks,
Milan
1:18 p.m.
New subject: Fedora 15, new and exciting plans (NoDefaultLVM)
On Mon, 2010-11-15 at 13:02 +0100, Milan Broz wrote:
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote:
>> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
Info on this page is completely obsolete!
Yes. Note the prominent line reading:
* Last updated: December 17, 2008
The information was current and correct then.
It's pretty disappointing that this entire thread happened without
anyone bothering to correct the wiki page, or even add comments to the
Talk page. Alas.
Please use the Talk page to outline requirements, recommendations,
reasoning, etc. Rough sketches are OK. Just, jeez, make a little effort.
Actually *tell me* what you want/need/think.
-w
11:16 a.m.
On Fri, Nov 12, 2010 at 09:35:54 -0700,
Kevin Fenzi <kevin(a)scrye.com> wrote:
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Maybe for some people. Having spin stuff break before the alpha and final
releases, was neither dull nor relaxing. The beta was OK for me, but dealing
with the systemd change probably wasn't dull nor relaxing for the people
that had to deal with that.
Any other exciting work in progress that might land in F15 that
people
are actively working on?
If Phillip gets a chance to work on LZMA Squashfs for 2.6.38, it will probably
make it in as a feature (more stuff being crammed in on a live CD / DVD).
Brian Lane is being pretty active with livecd-tools, so maybe some other
goodness will happen there.
1:04 p.m.
On Fri, 12 Nov 2010, Kevin Fenzi wrote:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
I understood grub2 is much worse for serial console support. But that info might
be outdated by now. A good clean way of "boot once, fallback to failure on 2nd
boot"
woudl be nice. With grub that is tricky because of redhat patches to it.
* Will NM finally be able to do bridging?
I'd like to see L2TP/IPsec integration with NM. I know there is some work going on
there (and I need to do some of it myself as upstream)
Paul
1:07 p.m.
----- "Kevin Fenzi" <kevin(a)scrye.com> wrote:
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)
Things I know of so far:
* systemd
* gnome3 / gnome-shell default
* removing a bunch of suid stuff in favor of capabilities
* xfce 4.8 (with any luck).
Things that are out there, but no idea if anyone is working on them
or
if they might be ready by f15:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it,
although
it may be a lot of work to get it to where we need it).
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
any luck).
Lukas Tinkl (ltinkl) is finishing his KDE HALsectomy. It's not easy -
without nasty hacks (and copying code from HAL as some other DEs does ;-).
* Will NM finally be able to do bridging?
* Some kind of packaged wayland to play with, even if it doesn't do
much?
Wayland seems like long distant future but I'm looking forward to see it -
together with Plasma Desktop ported on top of Qt Scene Graph, wow - heaven
is melting ;-)
Any other exciting work in progress that might land in F15 that
people
are actively working on?
As usual - we hope for a lot of KDE Plasma Desktop features ;-)
kevin
Jaroslav
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1:13 p.m.
On Fri, Nov 12, 2010 at 9:35 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)
Things I know of so far:
* systemd
* gnome3 / gnome-shell default
* removing a bunch of suid stuff in favor of capabilities
* xfce 4.8 (with any luck).
Things that are out there, but no idea if anyone is working on them or
if they might be ready by f15:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
any luck).
* Will NM finally be able to do bridging?
* Some kind of packaged wayland to play with, even if it doesn't do
much?
Any other exciting work in progress that might land in F15 that people
are actively working on?
I just wrote a blog post somewhat relating to this which some of you
good folks may have already seen on planet.fp.o, but I'll advertise it
here briefly anyhow:
http://wordshack.wordpress.com/2010/11/12/clouds-and-jobs-and-fudcons-oh-my/
The short version: the Cloud SIG is planning on having a bunch of
goodies, including BoxGrinder, OpenStack, CloudFS, Sheepdog, and
(HOPEFULLY) Deltacloud submitted as features for F15. Most of them
are already in the works. Links / info about those projects are in
the aforementioned blog post link.
But I happen to think that having more of a set of building blocks for
cloud applications and management in Fedora is VERY, very exciting. :)
-Robyn
kevin
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2:09 p.m.
----- "Robyn Bergeron" <robyn.bergeron(a)gmail.com> wrote:
On Fri, Nov 12, 2010 at 9:35 AM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> Greetings.
>
> Fedora 14 was a pretty relaxing and stable release. I'm thinking
that
> Fedora 15 may be much more exciting. ;)
>
> Things I know of so far:
>
> * systemd
> * gnome3 / gnome-shell default
> * removing a bunch of suid stuff in favor of capabilities
> * xfce 4.8 (with any luck).
>
> Things that are out there, but no idea if anyone is working on them
or
> if they might be ready by f15:
>
> * grub2 (no one is driving for this that I know of, but has some
> advantages over our grub1 if someone is willing to run with it,
although
> it may be a lot of work to get it to where we need it).
>
> * btrfs (Is this ready to be default? :) If so, would that warrant
a
> change in our lvm by default setup?
>
> * Can we finally remove hal? (xfce4.8 shouldn't need it anymore
with
> any luck).
>
> * Will NM finally be able to do bridging?
>
> * Some kind of packaged wayland to play with, even if it doesn't do
> much?
>
> Any other exciting work in progress that might land in F15 that
people
> are actively working on?
I just wrote a blog post somewhat relating to this which some of you
good folks may have already seen on planet.fp.o, but I'll advertise
it
here briefly anyhow:
http://wordshack.wordpress.com/2010/11/12/clouds-and-jobs-and-fudcons-oh-my/
The short version: the Cloud SIG is planning on having a bunch of
goodies, including BoxGrinder, OpenStack, CloudFS, Sheepdog, and
(HOPEFULLY) Deltacloud submitted as features for F15. Most of them
are already in the works. Links / info about those projects are in
the aforementioned blog post link.
Wow,
we have Cloud SIG too? ;-) Then you can count Matahari in, merging with
FMCI (hopefully).
Jaroslav
But I happen to think that having more of a set of building blocks
for
cloud applications and management in Fedora is VERY, very exciting.
:)
-Robyn
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
3:45 p.m.
On 11/12/2010 11:35 AM, Kevin Fenzi wrote:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
I'll be glad to point people in the right direction and review patches
for grubby and booty (anaconda) to support this - so far there's just
been a lot of talk, though.
--
Peter
Computers have already beaten communists at chess. The next thing you
know, they'll be beating humans.
-- Dale
01234567890123456789012345678901234567890123456789012345678901234567890123456789
5:22 p.m.
On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote:
Kevin Fenzi writes:
> * gnome3 / gnome-shell default
And what about systems with hardware that does not support accelerated 3D?
There'll be a fallback to metacity. (Or, perhaps, you could run Shell on
LLVM...that's just me conjecturing, though, I dunno if anyone's actually
looking at that.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:45 a.m.
On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote:
Kevin Fenzi writes:
> * gnome3 / gnome-shell default
And what about systems with hardware that does not support accelerated 3D?
There will be a fallback to gnome-panel, Metacity, and
notification-daemon
* The fallback components have been adapted to work better with GNOME 3
applications; for example notification behavior is more like the
GNOME 3 behavior where notifications that time out can still be
accessed, so you don't need a status icon just so the user can
see that something happened (ABRT, PackageKit reboot notifications,
etc.)
* But there is no attempt to make it "seamless"; we won't be going to
a black panel for GNOME 2 or having a 2D-graphics Activities Overview
replacement.
* Some features may be missing as compared to GNOME 2 when running
in fallback mode. One example is that there will be no desktop
magnifier in the fallback.
- Owen
10:15 a.m.
On 11/13/2010 10:45 AM, Owen Taylor wrote:
On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote:
> Kevin Fenzi writes:
>
>> * gnome3 / gnome-shell default
>
Does anyone happen to know how to mimic the equivalent of panel
applets esp those which are not a part of fedora
e.g. I use mathematica all the time and in gnome 2.x I put an icon on
the panel.
The only way I could see so far from looking at the gnome-3 website
is to ALT-F2 to start an application - then right click to add the app
to 'favorites' ...
11:15 a.m.
On Sat, 2010-11-13 at 11:15 -0500, Genes MailLists wrote:
On 11/13/2010 10:45 AM, Owen Taylor wrote:
> On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote:
>> Kevin Fenzi writes:
>>
>>> * gnome3 / gnome-shell default
>>
Does anyone happen to know how to mimic the equivalent of panel
applets esp those which are not a part of fedora
e.g. I use mathematica all the time and in gnome 2.x I put an icon on
the panel.
The only way I could see so far from looking at the gnome-3 website
is to ALT-F2 to start an application - then right click to add the app
to 'favorites' ...
Anything installing an application on the system (whether it's part of
Fedora or not) really should be installing a desktop file. If there's no
desktop file, there's no way for the user to launch the application.
In GNOME 3, no desktop file also means that it won't behave properly as
an application.... it won't get the right name and icon in the top
panel, etc.
Once there is a desktop file, then, yes you would add it to favorites.
Favorite are very close in function to a launcher on the panel - you can
get to them with a single mouse-click using the "hot corner" activation
of the Activities Overview.
(If Mathematica has a desktop file and it's just not being picked up by
GNOME 3, then creating a symlink into ~/.local/share/applications will
work.)
Is there going to be a GUI to create a desktop file for a something that
doesn't have a desktop file? (Something like the "Add custom launcher"
dialog for gnome-panel currently.) It's not in our plans currently, and
I'm not really sure where it would neatly fit into the user interface.
One possibility is the one you mentioned - if someone starts an
application that we don't recognize and tries to make it a favorite, we
prompt them for the missing information and create a desktop file in
~/.local/share/applications. But really, it's something that ISVs have
to get right and anything else is a workaround.
- Owen
11:59 a.m.
On 11/14/2010 12:15 PM, Owen Taylor wrote:
Anything installing an application on the system (whether it's part of
Fedora or not) really should be installing a desktop file. If there's no
desktop file, there's no way for the user to launch the application.
In GNOME 3, no desktop file also means that it won't behave properly as
an application.... it won't get the right name and icon in the top
panel, etc.
Once there is a desktop file, then, yes you would add it to favorites.
Favorite are very close in function to a launcher on the panel - you can
get to them with a single mouse-click using the "hot corner" activation
of the Activities Overview.
(If Mathematica has a desktop file and it's just not being picked up by
GNOME 3, then creating a symlink into ~/.local/share/applications will
work.)
Is there going to be a GUI to create a desktop file for a something that
doesn't have a desktop file? (Something like the "Add custom launcher"
dialog for gnome-panel currently.) It's not in our plans currently, and
I'm not really sure where it would neatly fit into the user interface.
One possibility is the one you mentioned - if someone starts an
application that we don't recognize and tries to make it a favorite, we
prompt them for the missing information and create a desktop file in
~/.local/share/applications. But really, it's something that ISVs have
to get right and anything else is a workaround.
I have a lot of non-fedora applications I added via the 'custom
launcher' tool - it would be really nice to be able to do this - whether
its mathematica or sometimes its upstream versions of apps (I use test
versions of thunderbird for example) as well as a bunch of other apps.
Certainly be nice if gnome 3 made it as easy as it is in gnome 2 ...
thanks for your thoughts.
gene
3:10 p.m.
New subject: Fedora 15, new and exciting plans - BTRFS
On 11/14/2010 07:03 PM, Genes MailLists wrote:
> btfrs providing raid0 functionality.
Does BTRFS have the equivalent of raid 5 ?
Apparently that's being worked on:
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Raid5.2F6
Regards,
Dennis
3:26 p.m.
New subject: Fedora 15, new and exciting plans - BTRFS
On Sun, 2010-11-14 at 13:03 -0500, Genes MailLists wrote:
> btfrs providing raid0 functionality.
Does BTRFS have the equivalent of raid 5 ?
I implemented most of what's needed for RAID5 (and RAID6) a year or so
ago.
It's waiting on Chris to do the final bits in the upper layers which are
required to ensure we only ever write a full stripe.
That should allegedly be Real Soon Now. Although he's been saying that
for quite a long time... :)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
6:23 p.m.
New subject: Fedora 15, new and exciting plans - BTRFS
On 11/14/2010 04:26 PM, David Woodhouse wrote:
>
> Does BTRFS have the equivalent of raid 5 ?
I implemented most of what's needed for RAID5 (and RAID6) a year or so
ago.
It's waiting on Chris to do the final bits in the upper layers which are
required to ensure we only ever write a full stripe.
That should allegedly be Real Soon Now. Although he's been saying that
for quite a long time... :)
Thats really really good news ... :-)
6:39 p.m.
Kevin Fenzi <kevin(a)scrye.com> wrote:
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore
with
any luck).
Well, I've been doing this since F13, but not having to deal with it in
non-@minimal installs as well would be nice :) .
* Some kind of packaged wayland to play with, even if it doesn't
do
much?
I'd be up for helping with this (package review, testing, maybe some
porting of applications such as dmenu and other simpler ones). I'd like
to see if I can get session management and persistent applications at
every level of my setup :) .
Any other exciting work in progress that might land in F15 that
people
are actively working on?
The Haskell SIG[1] plans on getting GHC 7.0 in F15 (feature page[2])
which has LLVM support, a new I/O manager, type-checker, and a parallel
garbage collector.
--Ben
[1]https://fedoraproject.org/wiki/Haskell_SIG
[2]https://fedoraproject.org/wiki/Features/GHC70
5:56 a.m.
2010/11/12 Kevin Fenzi <kevin(a)scrye.com>:
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore
with
any luck).
For the record, you can check the current status here: [1]
Also, the tracker bug in GNOME bugzilla: [2]
Regards
[1] http://fedoraproject.org/wiki/Features/HalRemoval
[2] https://bugzilla.gnome.org/show_bug.cgi?id=593938
--
Javier Jardón Cabezas
12:14 p.m.
/*Kevin Fenzi <kevin(a)scrye.com>*/ wrote on 11/12/2010 8:05:54 PM +0350:
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)
Things I know of so far:
* systemd
* gnome3 / gnome-shell default
* removing a bunch of suid stuff in favor of capabilities
* xfce 4.8 (with any luck).
Things that are out there, but no idea if anyone is working on them or
if they might be ready by f15:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
any luck).
* Will NM finally be able to do bridging?
* Some kind of packaged wayland to play with, even if it doesn't do
much?
Any other exciting work in progress that might land in F15 that people
are actively working on?
We at Fedora Robotics SIG are working on Fedora Robotics
Spin for Fedora
15. It's a bit special purpose but it might look interesting too :)
kevin
8:34 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
Greetings.
Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)
biosdevname installed by default, used in the installer and at runtime
to rename Dell and HP server onboard NICs from non-deterministic
"ethX" to clearly labeled "lomX" matching the chassis silkscreen.
http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
Exciting, not really. Necessary, absolutely!
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
10:30 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote:
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
> Greetings.
>
> Fedora 14 was a pretty relaxing and stable release. I'm thinking that
> Fedora 15 may be much more exciting. ;)
biosdevname installed by default, used in the installer and at runtime
to rename Dell and HP server onboard NICs from non-deterministic
"ethX" to clearly labeled "lomX" matching the chassis silkscreen.
http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
Exciting, not really. Necessary, absolutely!
Feature page:
https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
12:11 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On 11/13/2010 06:34 PM, Matt Domsch wrote:
biosdevname installed by default, used in the installer and at
runtime
to rename Dell and HP server onboard NICs from non-deterministic
"ethX" to clearly labeled "lomX" matching the chassis silkscreen.
http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
In that message I see:
** No rename for all others "ethX" (no change for NICs in PCI
slots/USB/others)
I'd like an option to assign "ethX" to NICs in /sys/devices/pci* order.
This matches chassis PCI slot order on many, many motherboards.
I get confused when ethX is assigned in a different order.
You can bind ethX to a specific card [not slot] by using HWADDR= in
/etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer
an option to assign ethX by PCI slot, because that's what I can see when
I plug in the cables. My NICs are various brands and models,
but I treat them all as generic because that is much simpler,
especially in the beginning.
--
7:53 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 10:11:11PM -0800, John Reiser wrote:
On 11/13/2010 06:34 PM, Matt Domsch wrote:
> biosdevname installed by default, used in the installer and at runtime
> to rename Dell and HP server onboard NICs from non-deterministic
> "ethX" to clearly labeled "lomX" matching the chassis
silkscreen.
>
> http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
In that message I see:
** No rename for all others "ethX" (no change for NICs in PCI
slots/USB/others)
I'd like an option to assign "ethX" to NICs in /sys/devices/pci* order.
This matches chassis PCI slot order on many, many motherboards.
I get confused when ethX is assigned in a different order.
You can bind ethX to a specific card [not slot] by using HWADDR= in
/etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer
an option to assign ethX by PCI slot, because that's what I can see when
I plug in the cables. My NICs are various brands and models,
but I treat them all as generic because that is much simpler,
especially in the beginning.
For you, biosdevname has alternate naming policies. You'll edit
/etc/udev/rules.d/71-netdevice.rules, changing --policy=loms to
--policy={something else}, with various choices available:
[loms|kernelnames|all_ethN|all_names|embedded_ethN_slots_names|smbios_names]
all_ethN does exactly what you want, embedded devices first, then all
other devices in ascending PCI slot order.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
4:57 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote:
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
> Greetings.
>
> Fedora 14 was a pretty relaxing and stable release. I'm thinking that
> Fedora 15 may be much more exciting. ;)
biosdevname installed by default, used in the installer and at runtime
to rename Dell and HP server onboard NICs from non-deterministic
"ethX" to clearly labeled "lomX" matching the chassis silkscreen.
But why “lomX” for all? Isn't Lights-Out-Management available only on first
ethernet port and often on dedicated port?
--
Tomasz Torcz "Never underestimate the bandwidth of a station
xmpp: zdzichubg(a)chrome.pl wagon filled with backup tapes." -- Jim Gray
7:53 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 11:57:59AM +0100, Tomasz Torcz wrote:
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote:
> On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
> > Greetings.
> >
> > Fedora 14 was a pretty relaxing and stable release. I'm thinking that
> > Fedora 15 may be much more exciting. ;)
>
> biosdevname installed by default, used in the installer and at runtime
> to rename Dell and HP server onboard NICs from non-deterministic
> "ethX" to clearly labeled "lomX" matching the chassis
silkscreen.
But why ???lomX??? for all? Isn't Lights-Out-Management available only on first
ethernet port and often on dedicated port?
This has nothing to do with Lights-Out-Management. LOM also == LAN on
Motherboard.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
8:24 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote:
> > biosdevname installed by default, used in the installer and
at runtime
> > to rename Dell and HP server onboard NICs from non-deterministic
> > "ethX" to clearly labeled "lomX" matching the chassis
silkscreen.
> But why ???lomX??? for all? Isn't Lights-Out-Management available only on
first
> ethernet port and often on dedicated port?
This has nothing to do with Lights-Out-Management. LOM also == LAN on
Motherboard.
Since you're already silkscreening this on the chassis of your systems,
clearly this ship is well out of the harbor, but that confusion seems like a
completely legitimate concern. Seems like it could easily result in
management interfaces getting plugged into the wrong networks.
Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's
just an adapter, not actually a whole lan. It should clearly be NIC on
Motherboard, or "nom". And then you could silkscreen lolcats on to the
servers, which I think would be a win for everyone.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:32 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Tue, 2010-11-16 at 09:24 -0500, Matthew Miller wrote:
On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote:
> > > biosdevname installed by default, used in the installer and at runtime
> > > to rename Dell and HP server onboard NICs from non-deterministic
> > > "ethX" to clearly labeled "lomX" matching the chassis
silkscreen.
> > But why ???lomX??? for all? Isn't Lights-Out-Management available only on
first
> > ethernet port and often on dedicated port?
> This has nothing to do with Lights-Out-Management. LOM also == LAN on
> Motherboard.
Since you're already silkscreening this on the chassis of your systems,
clearly this ship is well out of the harbor, but that confusion seems like a
completely legitimate concern. Seems like it could easily result in
management interfaces getting plugged into the wrong networks.
Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's
just an adapter, not actually a whole lan. It should clearly be NIC on
Motherboard, or "nom". And then you could silkscreen lolcats on to the
servers, which I think would be a win for everyone.
I've had a few off-list conversations with various community members
about this. One thing that came up was that the alternative namespace is
necessary, but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
followed by another letter like "netm" or something. To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.
Meanwhile, there are two other things I'm keeping ticking over:
1). Potential kernel-based solutions to augment this (but not otherwise
affect what would be in F-15). More on that another time.
2). Naming of non-network devices. Both DMTF and other groups (ACPI,
PCI, etc.) looking at the problem of persistent device to slot mappings
have all looked at more than network. While Matt is (rightfully) looking
at networking in F-15, we need to remember this problem actually will in
future also necessitate work on other non-network devices, too.
Jon.
8:36 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Tue, 2010-11-16 at 09:32 -0500, Jon Masters wrote:
I've had a few off-list conversations with various community
members
about this. One thing that came up was that the alternative namespace is
necessary, but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
followed by another letter like "netm" or something. To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.
Just to add, if something like "net" were used, you'd still need an
extra letter to distinguish between "LOM" and others since the initial
focus is only on LOM and you don't want to create a new namespace only
to have to do so again later on.
Jon.
8:48 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
Once upon a time, Jon Masters <jonathan(a)jonmasters.org> said:
I've had a few off-list conversations with various community
members
about this. One thing that came up was that the alternative namespace is
necessary,
I'm not sold on this, but:
but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
followed by another letter like "netm" or something.
If you are adding a letter, stick with tried-and-true "eth".
Also, if your intention is to name the motherboard NICs, don't start
with 0 - I haven't seen a motherboard that does. If you are trying to
distinguish the motherboard NICs and make them easier to ID, follow what
the motherboard makers use (1, 2, ..., not 0-based).
To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.
There are legitimate concerns with "lom" being an established
abbreviation already associated with built-in NICs, so it is hardly
"bikeshedding" to disagree with that.
In any case, is this going to be something that can be disabled easily?
We have something like 18 years of Linux networking history that says
ethernet devices are "eth[0-9]+", and I'm not really interested in
auditing all the tools and scripts I use to make sure they handle
something different at this time.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:22 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 08:48:09AM -0600, Chris Adams wrote:
In any case, is this going to be something that can be disabled
easily?
We have something like 18 years of Linux networking history that says
ethernet devices are "eth[0-9]+", and I'm not really interested in
auditing all the tools and scripts I use to make sure they handle
something different at this time.
It can always be disabled at runtime by writing whatever you want into
/etc/udev/rules.d/70-persistent-net.rules. Whether or not we'll have
a way to disable it in the installer is TBD, right now there won't
be.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
3:16 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote:
I've had a few off-list conversations with various community
members
about this. One thing that came up was that the alternative namespace is
necessary, but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
followed by another letter like "netm" or something. To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.
There's an upstream conversation about the naming convention here:
http://marc.info/?l=linux-hotplug&m=129003163201746&w=2
For the record, right now, biosdevname uses:
emN_(vf).(vlan) for embedded devices
pci(slot)#(port)_(vf).(vlan) for add-in cards.
If the device does not support SR-IOV, then the _(vf) part is omitted.
If no huge objections on the upstream thread, I'll push this into
rawhide ASAP.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
4:06 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Thu, Nov 18, 2010 at 9:16 PM, Matt Domsch <Matt_Domsch(a)dell.com> wrote:
On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote:
> I've had a few off-list conversations with various community members
> about this. One thing that came up was that the alternative namespace is
> necessary, but also that "lom" is a sub-optimal choice. One idea that
> did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
> followed by another letter like "netm" or something. To avoid
> bikeshedding this to death though, I think Matt's "lom" naming is fine
> for the moment unless we happen to all agree on something else.
There's an upstream conversation about the naming convention here:
http://marc.info/?l=linux-hotplug&m=129003163201746&w=2
For the record, right now, biosdevname uses:
emN_(vf).(vlan) for embedded devices
pci(slot)#(port)_(vf).(vlan) for add-in cards.
If the device does not support SR-IOV, then the _(vf) part is omitted.
If no huge objections on the upstream thread, I'll push this into
rawhide ASAP.
Presumably there will be something in place that won't change this on
upgrades so that people don't end up in inoperable networking on the
next 'yum upgrade' after it gets installed.
Peter
4:15 p.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Thu, Nov 18, 2010 at 10:06:17PM +0000, Peter Robinson wrote:
On Thu, Nov 18, 2010 at 9:16 PM, Matt Domsch
<Matt_Domsch(a)dell.com> wrote:
> On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote:
>> I've had a few off-list conversations with various community members
>> about this. One thing that came up was that the alternative namespace is
>> necessary, but also that "lom" is a sub-optimal choice. One idea that
>> did come up was simply to call them "net" (net0, etc.) or perhaps
"net"
>> followed by another letter like "netm" or something. To avoid
>> bikeshedding this to death though, I think Matt's "lom" naming is
fine
>> for the moment unless we happen to all agree on something else.
>
> There's an upstream conversation about the naming convention here:
> http://marc.info/?l=linux-hotplug&m=129003163201746&w=2
>
> For the record, right now, biosdevname uses:
>
> ?emN_(vf).(vlan) for embedded devices
> ?pci(slot)#(port)_(vf).(vlan) for add-in cards.
>
> If the device does not support SR-IOV, then the _(vf) part is omitted.
>
> If no huge objections on the upstream thread, I'll push this into
> rawhide ASAP.
Presumably there will be something in place that won't change this on
upgrades so that people don't end up in inoperable networking on the
next 'yum upgrade' after it gets installed.
yes, if /etc/udev/rules.d/70-persistent-net.rules is in place, that is
used in preference to whatever biosdevname would choose. If a rule
for your device isn't in that file though, biosdevname kicks in to ask
udev to rename it.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
8:55 a.m.
New subject: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 09:24:26AM -0500, Matthew Miller wrote:
Also, I gotta say, it really shouldn't be LAN on Motherboard,
since it's
just an adapter, not actually a whole lan. It should clearly be NIC on
Motherboard, or "nom". And then you could silkscreen lolcats on to the
servers, which I think would be a win for everyone.
For the bike-shed-painting record, I'm kidding about the above, in case that
wasn't clear. I do think lom is a bad choice, and am not convinced of a very
compelling reason to not use "eth", but I don't think it's worth an
argument.
(But, c'mon: the first one could be 'nom', the second one 'nomnom',
and the
third one 'nomnomnom'. Delicious!)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:11 a.m.
On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote:
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore
with
any luck).
Only 30 packages left requiring it, according to repoquery. smolt's
probably the most interesting one to fix, if anyone's looking for a
project.
* Some kind of packaged wayland to play with, even if it doesn't
do
much?
https://bugzilla.redhat.com/show_bug.cgi?id=652746
Which _really_ won't do much at the moment, since we can't build any of
the demo clients yet. I'm still considering what to do about packaging
cairo's GL backend, it's not considered ABI stable yet.
And yeah, be aware that it's likely to detonate babies for a while yet.
- ajax
9:23 a.m.
On 11/15/2010 10:11 AM, Adam Jackson wrote:
On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote:
> * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
> any luck).
Only 30 packages left requiring it, according to repoquery. smolt's
probably the most interesting one to fix, if anyone's looking for a
project.
For the curious, the 30 packages (in rawhide) are:
HAL itself (and its satellite packages):
hal-0:0.5.14-6.fc15.x86_64
hal-devel-0:0.5.14-6.fc15.i686
hal-devel-0:0.5.14-6.fc15.x86_64
hal-docs-0:0.5.14-6.fc15.x86_64
hal-info-0:20090716-3.fc12.noarch
hal-storage-addon-0:0.5.14-6.fc15.x86_64
Others:
beldi-0:0.9.25-2.fc12.x86_64
blueman-0:1.21-6.fc15.x86_64
exaile-0:0.3.2.0-2.fc14.noarch
fedora-setup-keyboard-0:0.6-1.fc13.x86_64
gnome-device-manager-libs-0:0.2-6.fc12.i686
gnome-device-manager-libs-0:0.2-6.fc12.x86_64
ifuse-0:1.0.0-1.fc14.x86_64
kdelibs-6:4.5.3-2.fc15.i686
kdelibs-6:4.5.3-2.fc15.x86_64
libconcord-0:0.21-10.fc14.i686
libconcord-0:0.21-10.fc14.x86_64
lxsession-0:0.4.4-1.fc14.x86_64
matahari-0:0.0.5-4.fc15.x86_64
nut-0:2.4.3-8.fc15.x86_64
nut-cgi-0:2.4.3-8.fc15.x86_64
nut-client-0:2.4.3-8.fc15.i686
nut-client-0:2.4.3-8.fc15.x86_64
nut-hal-0:2.4.3-8.fc15.x86_64
ovirt-server-installer-0:0.100-5.fc15.noarch
razertool-0:0.0.7-7.fc14.x86_64
smolt-0:1.4.2.2-3.fc15.noarch
xfce4-cddrive-plugin-0:0.0.1-3.fc13.x86_64
xfce4-power-manager-0:0.8.5-1.fc15.x86_64
xfce4-volstatus-icon-0:0.1.0-6.fc12.x86_64
I know that at least a few of these are just an upgrade and/or rebuild away.
Nathaniel
6:04 p.m.
On Mon, Nov 15, 2010 at 10:23:37AM -0500, Nathaniel McCallum wrote:
On 11/15/2010 10:11 AM, Adam Jackson wrote:
> On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote:
>
>> * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
>> any luck).
>
> Only 30 packages left requiring it, according to repoquery. smolt's
> probably the most interesting one to fix, if anyone's looking for a
> project.
For the curious, the 30 packages (in rawhide) are:
HAL itself (and its satellite packages):
hal-0:0.5.14-6.fc15.x86_64
hal-devel-0:0.5.14-6.fc15.i686
hal-devel-0:0.5.14-6.fc15.x86_64
hal-docs-0:0.5.14-6.fc15.x86_64
hal-info-0:20090716-3.fc12.noarch
hal-storage-addon-0:0.5.14-6.fc15.x86_64
Others:
beldi-0:0.9.25-2.fc12.x86_64
blueman-0:1.21-6.fc15.x86_64
exaile-0:0.3.2.0-2.fc14.noarch
fedora-setup-keyboard-0:0.6-1.fc13.x86_64
whoops, this package was renamed by system-setup-keyboard, which now uses
xorg.conf.d snippets instead of hal. package is about to be retired any
minute now.
Cheers,
Peter
gnome-device-manager-libs-0:0.2-6.fc12.i686
gnome-device-manager-libs-0:0.2-6.fc12.x86_64
ifuse-0:1.0.0-1.fc14.x86_64
kdelibs-6:4.5.3-2.fc15.i686
kdelibs-6:4.5.3-2.fc15.x86_64
libconcord-0:0.21-10.fc14.i686
libconcord-0:0.21-10.fc14.x86_64
lxsession-0:0.4.4-1.fc14.x86_64
matahari-0:0.0.5-4.fc15.x86_64
nut-0:2.4.3-8.fc15.x86_64
nut-cgi-0:2.4.3-8.fc15.x86_64
nut-client-0:2.4.3-8.fc15.i686
nut-client-0:2.4.3-8.fc15.x86_64
nut-hal-0:2.4.3-8.fc15.x86_64
ovirt-server-installer-0:0.100-5.fc15.noarch
razertool-0:0.0.7-7.fc14.x86_64
smolt-0:1.4.2.2-3.fc15.noarch
xfce4-cddrive-plugin-0:0.0.1-3.fc13.x86_64
xfce4-power-manager-0:0.8.5-1.fc15.x86_64
xfce4-volstatus-icon-0:0.1.0-6.fc12.x86_64
I know that at least a few of these are just an upgrade and/or rebuild away.
Nathaniel
11:46 p.m.
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote:
libconcord-0:0.21-10.fc14.i686
libconcord-0:0.21-10.fc14.x86_64
This one's a bit tricky, as it does something unique that you can't do
any other way (it lets you program Logitech Harmony remote controls -
Logitech only provide a tool for Windows, and AFAIK there's no other
Linux tool available), and to my knowledge there's no patch to make it
not use HAL available.
On the positive side, it doesn't do anything terribly complicated, it
just ships a single HAL rules file which does this:
<append key="info.capabilities"
type="strlist">access_control</append>
<merge key="access_control.file"
type="copy_property">linux.device_file</merge>
<merge key="access_control.type"
type="string">libconcord</merge>
</match>
for a bunch of different devices (all the various supported remotes). I
don't know exactly what that is, but I can't imagine it'd be terribly
hard to port to udev or something for anyone who does know about it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:37 a.m.
Le vendredi 19 novembre 2010 à 21:46 -0800, Adam Williamson a écrit :
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote:
> libconcord-0:0.21-10.fc14.i686
> libconcord-0:0.21-10.fc14.x86_64
I
don't know exactly what that is, but I can't imagine it'd be terribly
hard to port to udev or something for anyone who does know about it.
Libconcord just needs the device to be writeable by the current user
(it's kind of hard to program a remote you can't write to)
--
Nicolas Mailhot
10:51 a.m.
On Sat, 2010-11-20 at 10:37 +0100, Nicolas Mailhot wrote:
Le vendredi 19 novembre 2010 à 21:46 -0800, Adam Williamson a écrit
:
> On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote:
>
> > libconcord-0:0.21-10.fc14.i686
> > libconcord-0:0.21-10.fc14.x86_64
> I
> don't know exactly what that is, but I can't imagine it'd be terribly
> hard to port to udev or something for anyone who does know about it.
Libconcord just needs the device to be writeable by the current user
(it's kind of hard to program a remote you can't write to)
oh, that's right. I think I even reported that bug in the first place :)
(I remember only being able to use it as root before). Now I remember,
there's a
file /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.libconcord.policy which
goes along with it. I'm sure that should be easy to do in udev instead.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:19 p.m.
Adam Williamson wrote:
On the positive side, it doesn't do anything terribly
complicated, it
just ships a single HAL rules file which does this:
<append key="info.capabilities"
type="strlist">access_control</append> <merge
key="access_control.file"
type="copy_property">linux.device_file</merge>
<merge key="access_control.type"
type="string">libconcord</merge>
</match>
for a bunch of different devices (all the various supported remotes). I
don't know exactly what that is, but I can't imagine it'd be terribly
hard to port to udev or something for anyone who does know about it.
That stuff ALREADY doesn't work and hasn't for a couple releases, ACL
support has been disabled in Fedora's HAL builds!
Kevin Kofler
9:48 p.m.
On Sun, 2010-11-21 at 03:19 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> On the positive side, it doesn't do anything terribly complicated, it
> just ships a single HAL rules file which does this:
>
> <append key="info.capabilities"
> type="strlist">access_control</append> <merge
> key="access_control.file"
> type="copy_property">linux.device_file</merge>
> <merge key="access_control.type"
type="string">libconcord</merge>
> </match>
>
> for a bunch of different devices (all the various supported remotes). I
> don't know exactly what that is, but I can't imagine it'd be terribly
> hard to port to udev or something for anyone who does know about it.
That stuff ALREADY doesn't work and hasn't for a couple releases, ACL
support has been disabled in Fedora's HAL builds!
I dunno, I haven't had to re-program my remote for a while, so I haven't
used it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:55 p.m.
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote:
On 11/15/2010 10:11 AM, Adam Jackson wrote:
> On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote:
>
>> * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
>> any luck).
>
> Only 30 packages left requiring it, according to repoquery. smolt's
> probably the most interesting one to fix, if anyone's looking for a
> project.
For the curious, the 30 packages (in rawhide) are:
And gnome-lirc-properties as well. Which, it seems, wouldn't have worked
if installed from a minimal installation. Oops.
11:28 a.m.
On Mon, Nov 15, 2010 at 10:11:52AM -0500, Adam Jackson wrote:
> * Some kind of packaged wayland to play with, even if it
doesn't do
> much?
https://bugzilla.redhat.com/show_bug.cgi?id=652746
Which _really_ won't do much at the moment, since we can't build any of
the demo clients yet. I'm still considering what to do about packaging
cairo's GL backend, it's not considered ABI stable yet.
And yeah, be aware that it's likely to detonate babies for a while yet.
If it can at least do a demo, that'd be a pretty good PR win, for whatever
that's worth.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:44 a.m.
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
* Can we finally remove hal? (xfce4.8 shouldn't need it anymore
with
any luck).
Not without a pile of X changes, which themselves are blocking on
upstream kernel changes that I've submitted but which haven't been
merged.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:48 p.m.
On Mon, 2010-11-15 at 15:44 +0000, Matthew Garrett wrote:
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
> * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
> any luck).
Not without a pile of X changes, which themselves are blocking on
upstream kernel changes that I've submitted but which haven't been
merged.
For brightness? For GNOME at least, this is worked around in:
http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-he...
though a cleaner fix would certainly be appreciated.
11:23 a.m.
Bastien Nocera wrote:
On Mon, 2010-11-15 at 15:44 +0000, Matthew Garrett wrote:
> On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
>
> > * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
> > any luck).
>
> Not without a pile of X changes, which themselves are blocking on
> upstream kernel changes that I've submitted but which haven't been
> merged.
For brightness? For GNOME at least, this is worked around in:
http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-
helper.c
though a cleaner fix would certainly be appreciated.
Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil:
http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backe...
and it appears to work fine for those who have coded this.
It might not to work for proprietary drivers, but that's those drivers'
problem. KDE basically requires XRandR since at least 4.0.
Kevin Kofler
11:31 a.m.
On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote:
Bastien Nocera wrote:
> On Mon, 2010-11-15 at 15:44 +0000, Matthew Garrett wrote:
>> On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote:
>>
>> > * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
>> > any luck).
>>
>> Not without a pile of X changes, which themselves are blocking on
>> upstream kernel changes that I've submitted but which haven't been
>> merged.
>
> For brightness? For GNOME at least, this is worked around in:
> http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-
helper.c
> though a cleaner fix would certainly be appreciated.
Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil:
http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backe...
and it appears to work fine for those who have coded this.
It might not to work for proprietary drivers, but that's those drivers'
problem. KDE basically requires XRandR since at least 4.0.
this is a fairly new thing, AIUI:
http://mjg59.livejournal.com/127103.html
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:17 p.m.
Adam Williamson wrote:
On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote:
> It might not to work for proprietary drivers, but that's those drivers'
> problem. KDE basically requires XRandR since at least 4.0.
>
this is a fairly new thing, AIUI:
http://mjg59.livejournal.com/127103.html
I know it's a fairly recent XRandR feature. But it's also part of KDE's
track record to always require the latest XRandR spec. :-) As long as the
drivers actually in Fedora support that, I'm fine with it.
Kevin Kofler
1:56 p.m.
On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote:
Huh? KDE trunk (4.6) already uses XRandR backlight setting in
PowerDevil:
http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backe...
and it appears to work fine for those who have coded this.
It might not to work for proprietary drivers, but that's those drivers'
problem. KDE basically requires XRandR since at least 4.0.
Well, that's unfortunate - XRandR backlight control is only implemented
on -intel.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:51 p.m.
Matthew Garrett wrote:
On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote:
> Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil:
>
http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backe...
> and it appears to work fine for those who have coded this.
>
> It might not to work for proprietary drivers, but that's those drivers'
> problem. KDE basically requires XRandR since at least 4.0.
Well, that's unfortunate - XRandR backlight control is only implemented
on -intel.
Well, what's unfortunate is that HAL got deprecated long before replacements
for all its parts were ready. KDE already waited for quite some time before
implementing the replacements for HAL and was heavily criticized for that
out of some circles. And STILL, the replacement isn't ready?
Surely copying&pasting HAL code into a helper which runs as root as gnome-
power-manager does isn't a long-term-viable solution!
How about next time the replacements get implemented BEFORE everyone
scrambles to replace HAL and those who don't get yelled at for waiting until
things actually work?!
Is there a hope that radeon and nouveau get fixed to support XRandR
backlight control by F15? (I don't give a darn about Catalyst/fglrx and
nvidia.)
Kevin Kofler
8:21 a.m.
On Tue, Nov 23, 2010 at 09:51:13PM +0100, Kevin Kofler wrote:
Well, what's unfortunate is that HAL got deprecated long before
replacements
for all its parts were ready. KDE already waited for quite some time before
implementing the replacements for HAL and was heavily criticized for that
out of some circles. And STILL, the replacement isn't ready?
It's been repeatedly pointed out that you still need HAL (or a
workalike) if you want backlight control. The replacement isn't ready
because the upstream kernel maintainer went AWOL for an extended period
of time.
Surely copying&pasting HAL code into a helper which runs as root
as gnome-
power-manager does isn't a long-term-viable solution!
You're right! It's not! Which is why nobody has claimed it is.
Is there a hope that radeon and nouveau get fixed to support XRandR
backlight control by F15? (I don't give a darn about Catalyst/fglrx and
nvidia.)
There is a hope, but it's going to have to happen at the server level
rather than the driver level - otherwise we're going to leave behind
various other drivers as well. Not all the world is nvidia, intel or
radeon despite how much easier that'd make things.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:43 p.m.
Dne 12.11.2010 17:35, Kevin Fenzi napsal(a):
Any other exciting work in progress that might land in F15 that
people
are actively working on?
ABRT with retrace server support, and a retrace server instance up and
running. It will improve the quality of backtraces.
http://fedoraproject.org/wiki/Features/RetraceServer
Design:
https://fedorahosted.org/pipermail/crash-catcher/attachments/20101102/f90...
Code:
http://git.fedorahosted.org/git/?p=abrt.git;a=shortlog;h=refs/heads/retrace
Hopefully I'll cope with ABRT duplicates: backtrace similarity algorithm
with a command line Bugzilla processing tool in F15, and a HTTP
front-end (service) or Bugzilla plugin for it in F16.
Karel
3:13 p.m.
On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
Dne 12.11.2010 17:35, Kevin Fenzi napsal(a):
> Any other exciting work in progress that might land in F15 that people
> are actively working on?
ABRT with retrace server support, and a retrace server instance up and
running. It will improve the quality of backtraces.
How does the user verify that there are no passwords or other personal
information in the core dump?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:59 p.m.
Dne 15.11.2010 22:13, Matthew Garrett napsal(a):
On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
> ABRT with retrace server support, and a retrace server instance up and
> running. It will improve the quality of backtraces.
How does the user verify that there are no passwords or other personal
information in the core dump?
Users only verify the resulting backtrace before sending it to Bugzilla.
They need to trust the retrace server administrator when they decide to
upload coredumps to the server for retracing (coredumps are kept on the
server only during the retracing operation - this should be stated in a
"privacy policy" for the server).
4:01 p.m.
On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
> Dne 12.11.2010 17:35, Kevin Fenzi napsal(a):
> > Any other exciting work in progress that might land in F15 that people
> > are actively working on?
>
> ABRT with retrace server support, and a retrace server instance up and
> running. It will improve the quality of backtraces.
How does the user verify that there are no passwords or other personal
information in the core dump?
I don't think it really works to ask the user to do that in practice
(though I'm not going to go scanning through bugzilla to try to prove
the point). It would work out better to:
1) Have crashes be anonymous by default
2) Limited access to crash dump data (for a given package, only allow
access by people in the ACLs for those packages?)
3) Still warn the user that it may contain private data, and allow
them not to submit (obviously)
4:04 p.m.
On Mon, Nov 15, 2010 at 10:01 PM, Colin Walters <walters(a)verbum.org> wrote:
On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
>> Dne 12.11.2010 17:35, Kevin Fenzi napsal(a):
>> > Any other exciting work in progress that might land in F15 that people
>> > are actively working on?
>>
>> ABRT with retrace server support, and a retrace server instance up and
>> running. It will improve the quality of backtraces.
>
> How does the user verify that there are no passwords or other personal
> information in the core dump?
I don't think it really works to ask the user to do that in practice
(though I'm not going to go scanning through bugzilla to try to prove
the point). It would work out better to:
1) Have crashes be anonymous by default
2) Limited access to crash dump data (for a given package, only allow
access by people in the ACLs for those packages?)
This would need to also include the QA people.
3) Still warn the user that it may contain private data, and allow
them not to submit (obviously)
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:04 p.m.
On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote:
On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> How does the user verify that there are no passwords or other personal
> information in the core dump?
I don't think it really works to ask the user to do that in practice
(though I'm not going to go scanning through bugzilla to try to prove
the point). It would work out better to:
Leaving the retracing at the user's end of things means that the user at
least has a choice in the matter - I'm unlikely to submit any firefox
crashes if I don't have an opportunity to look at what's in the
backtrace. We can make symbols available for local tracing without
forcing the user to download the entirity of the debuginfo, and that
would seem a more reasonable approach.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:07 p.m.
Matthew Garrett píše v Po 15. 11. 2010 v 22:04 +0000:
On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote:
> On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > How does the user verify that there are no passwords or other personal
> > information in the core dump?
>
> I don't think it really works to ask the user to do that in practice
> (though I'm not going to go scanning through bugzilla to try to prove
> the point). It would work out better to:
Leaving the retracing at the user's end of things means that the user at
least has a choice in the matter - I'm unlikely to submit any firefox
crashes if I don't have an opportunity to look at what's in the
backtrace. We can make symbols available for local tracing without
forcing the user to download the entirity of the debuginfo, and that
would seem a more reasonable approach.
Don't we need the entirety of debuginfo
in order to be able to include
parameter and local variable values in the backtrace?
Mirek
4:48 p.m.
On Mon, Nov 15, 2010 at 11:07:11PM +0100, Miloslav Trmač wrote:
Don't we need the entirety of debuginfo in order to be able to
include
parameter and local variable values in the backtrace?
The entirity of it needs to be available, but that's not the same as
requiring the user install it on local storage.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:51 p.m.
Dne 15.11.2010 23:04, Matthew Garrett napsal(a):
On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote:
> On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett<mjg59(a)srcf.ucam.org> wrote:
Leaving the retracing at the user's end of things means that the user at
least has a choice in the matter - I'm unlikely to submit any firefox
crashes if I don't have an opportunity to look at what's in the
backtrace. We can make symbols available for local tracing without
forcing the user to download the entirity of the debuginfo, and that
would seem a more reasonable approach.
http://fedoraproject.org/wiki/Features/DebuginfoFS
Agreed, debuginfofs will be better for many scenarios.
Major advantage of the retrace server is that you can get a good
backtraces even from unfresh coredumps. GDB needs access to the binary
and dynamic libraries that were installed at the time of the crash when
generating a backtrace. So if there was an update yesterday that
installed new versions of several packages, it can happen that the
backtrace can no longer be obtained from the coredump locally (without
installing the old packages somewhere else). Retrace server installs
packages that were used at the time of the crash, so the backtrace can
be obtained.
Major disadvantages of RS are that coredump upload takes time, 3rd party
packages can't be easily supported, and users must trust the administrator.
4:04 a.m.
Le Lun 15 novembre 2010 23:51, Karel Klic a écrit :
Dne 15.11.2010 23:04, Matthew Garrett napsal(a):
> On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote:
>> On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett<mjg59(a)srcf.ucam.org>
>> wrote:
> Leaving the retracing at the user's end of things means that the user at
> least has a choice in the matter - I'm unlikely to submit any firefox
> crashes if I don't have an opportunity to look at what's in the
> backtrace. We can make symbols available for local tracing without
> forcing the user to download the entirity of the debuginfo, and that
> would seem a more reasonable approach.
>
http://fedoraproject.org/wiki/Features/DebuginfoFS
Agreed, debuginfofs will be better for many scenarios.
Major advantage of the retrace server is that you can get a good
backtraces even from unfresh coredumps.
And why can't this be done with debuginfofs ? It's the same data.
--
Nicolas Mailhot
11:57 a.m.
Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a):
Le Lun 15 novembre 2010 23:51, Karel Klic a écrit :
> Major advantage of the retrace server is that you can get a good
> backtraces even from unfresh coredumps.
And why can't this be done with debuginfofs ? It's the same data.
GDB pretty printers (written in Python) need to be in the in the same
tree as GDB. They are distributed among packages, so if you want them,
you need to install GDB and coredump-related packages (containing the
pretty printers, in version which matches the coredump) to some
directory, chroot there, and then run the GDB. Then it outputs
prettified backtrace.
I haven't spent too much time thinking about debuginfofs, so I do not
know what would be possible if we'd work on it.
12:31 p.m.
On Tue, 16 Nov 2010 18:57:19 +0100, Karel Klic wrote:
Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a):
> Le Lun 15 novembre 2010 23:51, Karel Klic a écrit :
>> Major advantage of the retrace server is that you can get a good
>> backtraces even from unfresh coredumps.
>
> And why can't this be done with debuginfofs ? It's the same data.
GDB pretty printers (written in Python) need to be in the in the same
tree as GDB. They are distributed among packages,
Maybe not, it would have to be tried. I was discussing it later with the GDB
team and the Python Pretty Printers should be both cross-arch compatible and
they should work even for other versions - such as using GDB `set sysroot'.
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.14-gdb.py
from libstdc++-4.5.1-4.fc14.x86_64 already contains the version string
`6.0.14' so there can be multiple such `host OS' packages installed for
supporting various `target OS' versions.
Regards,
Jan
3:31 p.m.
On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
ABRT with retrace server support, and a retrace server instance up
and
running. It will improve the quality of backtraces.
Further, what's the licensing situation here? If I have an application
that (at runtime) is a mixture of GPLed and GPL-incompatible code, does
sending this coredump to a remote service count as distribution?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:28 p.m.
Dne 15.11.2010 22:31, Matthew Garrett napsal(a):
On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote:
> ABRT with retrace server support, and a retrace server instance up and
> running. It will improve the quality of backtraces.
Further, what's the licensing situation here? If I have an application
that (at runtime) is a mixture of GPLed and GPL-incompatible code, does
sending this coredump to a remote service count as distribution?
Interesting point. I do not know.
What is the scope of this question? Can GPLed and GPL-incompatible code
end up in the same coredump in Fedora installation without 3rd party
software installed?
It could happen that a coredump from Firefox contains non-free
javascript from pages that were viewed around the time of the crash, but
that is a browser-specific issue.
4:49 p.m.
On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote:
Dne 15.11.2010 22:31, Matthew Garrett napsal(a):
> Further, what's the licensing situation here? If I have an application
> that (at runtime) is a mixture of GPLed and GPL-incompatible code, does
> sending this coredump to a remote service count as distribution?
Interesting point. I do not know.
What is the scope of this question? Can GPLed and GPL-incompatible code
end up in the same coredump in Fedora installation without 3rd party
software installed?
It was reasonably likely in X until Synaptics got relicensed. I think
we're fairly safe from a stock install point of view.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:35 a.m.
On Mon, Nov 15, 2010 at 10:49:24PM +0000, Matthew Garrett wrote:
On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote:
> Dne 15.11.2010 22:31, Matthew Garrett napsal(a):
> > Further, what's the licensing situation here? If I have an application
> > that (at runtime) is a mixture of GPLed and GPL-incompatible code, does
> > sending this coredump to a remote service count as distribution?
>
> Interesting point. I do not know.
>
> What is the scope of this question? Can GPLed and GPL-incompatible code
> end up in the same coredump in Fedora installation without 3rd party
> software installed?
It was reasonably likely in X until Synaptics got relicensed. I think
we're fairly safe from a stock install point of view.
We should probably detect when things we don't ship are linked in and put some
measures in place to keep the user from inadvertently breaking copyright law
(or worse, putting copyrighted material on our BZ so /we/ end up inadvertently
breaking copyright law).
--CJD
3:15 p.m.
New subject: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
I realize that most people on this mailing list are focused on
infrastructure and server/desktop usage.
But some of us are looking forward to using future Fedora releases on
tablets in vehicular infotainment systems.
To this end, what are the plans for releasing Meego as part of Fedora in
F15 ?
It would also be really nice to see Navit make it into Fedora. Its been
"almost there" for a long time (since F10 ?) but somehow it never seems
to make it. Any chance someone out there could give it a boost ?
https://bugzilla.redhat.com/show_bug.cgi?id=654374
Thanks
LG
9:58 p.m.
New subject: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
2010/11/19 Linuxguy123 <linuxguy123(a)gmail.com>:
I realize that most people on this mailing list are focused on
infrastructure and server/desktop usage.
But some of us are looking forward to using future Fedora releases on
tablets in vehicular infotainment systems.
To this end, what are the plans for releasing Meego as part of Fedora in
F15 ?
It would also be really nice to see Navit make it into Fedora. Its been
"almost there" for a long time (since F10 ?) but somehow it never seems
to make it. Any chance someone out there could give it a boost ?
https://bugzilla.redhat.com/show_bug.cgi?id=654374
Thanks
LG
Meego haven't officially released any tablet UX plan yet, we still
need to wait some time.
Regards,
Chen Lei
11:22 p.m.
New subject: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
On Thu, 2010-11-18 at 14:15 -0700, Linuxguy123 wrote:
I realize that most people on this mailing list are focused on
infrastructure and server/desktop usage.
But some of us are looking forward to using future Fedora releases on
tablets in vehicular infotainment systems.
To this end, what are the plans for releasing Meego as part of Fedora in
F15 ?
It would also be really nice to see Navit make it into Fedora. Its been
"almost there" for a long time (since F10 ?) but somehow it never seems
to make it. Any chance someone out there could give it a boost ?
https://bugzilla.redhat.com/show_bug.cgi?id=654374
I'm sorry about that - I put in a review request for it shortly after I
came to RH as at the time I was poking about with running it on my
TinyBook(tm) using my phone as a GPS provider via bluetooth, which was
all fun and shiny, but it never had much serious use potential and
frankly I got bored with it, which is why I didn't work on the package
as hard as I probably should have done. Anyway, someone else has taken
it over now, so hopefully it'll finally get done.
(Presumably, though, Nokia will come up with something for navigation
purposes? They seem fairly big on IVI for Meego and frankly I don't see
them relying on Navit. Of course, whatever they come up with may be
non-F/OSS, I guess.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:56 a.m.
New subject: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 5:22 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2010-11-18 at 14:15 -0700, Linuxguy123 wrote:
> I realize that most people on this mailing list are focused on
> infrastructure and server/desktop usage.
>
> But some of us are looking forward to using future Fedora releases on
> tablets in vehicular infotainment systems.
>
> To this end, what are the plans for releasing Meego as part of Fedora in
> F15 ?
>
> It would also be really nice to see Navit make it into Fedora. Its been
> "almost there" for a long time (since F10 ?) but somehow it never seems
> to make it. Any chance someone out there could give it a boost ?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=654374
I'm sorry about that - I put in a review request for it shortly after I
came to RH as at the time I was poking about with running it on my
TinyBook(tm) using my phone as a GPS provider via bluetooth, which was
all fun and shiny, but it never had much serious use potential andUVU
frankly I got bored with it, which is why I didn't work on the package
as hard as I probably should have done. Anyway, someone else has taken
it over now, so hopefully it'll finally get done.
(Presumably, though, Nokia will come up with something for navigation
purposes? They seem fairly big on IVI for Meego and frankly I don't see
them relying on Navit. Of course, whatever they come up with may be
non-F/OSS, I guess.)
They made a maps purchase a while ago which on the n900 is now called
ovi maps (don't remember its original name) but its quite good but
unfortunately not open source. Presumably it might well be used, but
presumably the vendors that use the IVI system are free to user what
ever Nav app they choose.
Peter
3:28 a.m.
New subject: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
On Saturday, November 20, 2010 06:22:40 am Adam Williamson wrote:
On Thu, 2010-11-18 at 14:15 -0700, Linuxguy123 wrote:
> I realize that most people on this mailing list are focused on
> infrastructure and server/desktop usage.
>
> But some of us are looking forward to using future Fedora releases on
> tablets in vehicular infotainment systems.
>
> To this end, what are the plans for releasing Meego as part of Fedora in
> F15 ?
>
> It would also be really nice to see Navit make it into Fedora. Its been
> "almost there" for a long time (since F10 ?) but somehow it never seems
> to make it. Any chance someone out there could give it a boost ?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=654374
I'm sorry about that - I put in a review request for it shortly after I
came to RH as at the time I was poking about with running it on my
TinyBook(tm) using my phone as a GPS provider via bluetooth, which was
all fun and shiny, but it never had much serious use potential and
frankly I got bored with it, which is why I didn't work on the package
as hard as I probably should have done. Anyway, someone else has taken
it over now, so hopefully it'll finally get done.
(Presumably, though, Nokia will come up with something for navigation
purposes? They seem fairly big on IVI for Meego and frankly I don't see
them relying on Navit. Of course, whatever they come up with may be
non-F/OSS, I guess.)
My impression from MeeGo conference says no. They are going to use MeeGo as just
a platform for proprietary software :( Maybe I'm wrong but a lot of people from
community feels the same.
R.
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
11:32 a.m.
Hi,
2010/11/12 Kevin Fenzi <kevin(a)scrye.com>:
Any other exciting work in progress that might land in F15 that
people
are actively working on?
How about removing some old unix crud? (he said this and he saw that
some people starts to gather firewood in the stack :))
Anyone uses gopher, uucp?
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
Who uses floppy?
gopher:x:30:
video:x:39:
dip:x:40:
ftp:x:50:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
exim:x:93:
floppy:x:19:
vcsa:x:69:
cdrom:x:11:
tape:x:33:
dialout:x:18:
/etc/inittab should not be needed anymore.
Other ideas?
Kind regards,
Michal
11:50 a.m.
On Sat, Nov 20, 2010 at 06:32:26PM +0100, Michał Piotrowski wrote:
How about removing some old unix crud? (he said this and he saw that
some people starts to gather firewood in the stack :))
Anyone uses gopher, uucp?
sync:x:5:0:sync:/sbin:/bin/sync
Someone at Red Hat asked me once what the purpose of the sync user
was, and I did some research and wrote the reply below. It may be
interesting.
Rich.
<quote>
If you read this old (1988) advisory:
http://www.cert.org/advisories/CA-1988-01.html
it seems clear the original intent of the 'sync' user was to allow an
administrator to log in as 'sync' and have that synchronize the disks,
without needing a password. There were apparently other user accounts
like 'who' with a similar purpose, and in the current passwd file we
can find similar accounts like 'halt' and 'shutdown'.
However having a passwordless guest account, even without a shell, is
a security hole (because some misconfigured or poorly written services
could allow access from one of these "users"):
http://www.cert.org/tech_tips/unix_configuration_guidelines.html#A.1.ii
I tried to find out for you when the 'sync' user was added to Unix.
It's *not* in Unix v7 (1979):
http://unix-tree.huihoo.org/V7/etc/passwd.html
It *is* in Fedora Core 1 (2003) and RHL 5.0 (1996?) and Debian 0.9 (1995).
All of these have the password field set to '*' to prevent the
security problem.
After a lot of internet spelunking, I found that MCC Interim Linux
(1992?) contained a 'sync' user with no password! So you could have
walked up to an MCC Interim Linux box c1992, and logged in as 'sync' /
no password, and it would have synchronized the disks.
It seems we inherited this tradition from Unix systems dating back to
some time in the 1980s. It was carried over to Linux in 1991/1992,
but soon afterwards the empty password field was replaced with a '*'
because of security concerns, and it's been like that to this day.
</quote>
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
12:09 p.m.
On Sat, Nov 20, 2010 at 06:57:16PM +0100, Ralf Ertzinger wrote:
Interesting. But the short version of that means that all those
users are useless in their current form, and could be removed?
An administrator might decide to enable one of these accounts, but I'd
say that would be pretty unwise. Maybe if your computer is absolutely
never attached to a network :-)
The only other things I can think of:
- Could there be the odd file that is owned by one of these users?
(Likely a bug I would think ...)
- It's required by some standard like POSIX or FHS. My google-fu
turns up nothing right now, but I could have missed something.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
12:34 p.m.
2010/11/20 Richard W.M. Jones <rjones(a)redhat.com>:
On Sat, Nov 20, 2010 at 06:57:16PM +0100, Ralf Ertzinger wrote:
> Interesting. But the short version of that means that all those
> users are useless in their current form, and could be removed?
An administrator might decide to enable one of these accounts, but I'd
say that would be pretty unwise. Maybe if your computer is absolutely
never attached to a network :-)
The only other things I can think of:
- Could there be the odd file that is owned by one of these users?
(Likely a bug I would think ...)
Is there any rpm error message when you install package with such file
and user isn't exist?
- It's required by some standard like POSIX or FHS. My google-fu
turns up nothing right now, but I could have missed something.
Yeah, possible. But to me it means that these standards need to be updated.
It seems to me that ancient, obsolete things should be removed
(someone may want to create museum page - "Antique things that have
been removed" :)), not preserved for ages.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Best regards,
Michal
3:53 p.m.
On Sat, 20 Nov 2010 18:32:26 +0100
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
Hi,
2010/11/12 Kevin Fenzi <kevin(a)scrye.com>:
> Any other exciting work in progress that might land in F15 that
> people are actively working on?
How about removing some old unix crud? (he said this and he saw that
some people starts to gather firewood in the stack :))
Anyone uses gopher, uucp?
I do use UUCP. ;)
I'd have no problem with the uucp package making a user itself tho and
dropping the user from base.
kevin
3:47 a.m.
On Sat, Nov 20, 2010 at 9:53 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 20 Nov 2010 18:32:26 +0100
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
> Hi,
>
> 2010/11/12 Kevin Fenzi <kevin(a)scrye.com>:
> > Any other exciting work in progress that might land in F15 that
> > people are actively working on?
>
> How about removing some old unix crud? (he said this and he saw that
> some people starts to gather firewood in the stack :))
>
> Anyone uses gopher, uucp?
I do use UUCP. ;)
So do I. Its quite useful in particular circumstances.
I'd have no problem with the uucp package making a user itself
tho and
dropping the user from base.
I think it should be made by the package itself like all other users
as per packaging guidelines. I'm also quite happy not to have it
installed by default as I (and presumably pretty much everyone that
would use it) would know how to yum install it and those that don't
would likely get it via PackageKit-command-not-found
Peter
8:33 p.m.
Michał Piotrowski wrote:
Anyone uses gopher, uucp?
Me.
gopher://www.calcforge.org/1/
Web version: http://www.calcforge.org:70/
https://admin.fedoraproject.org/pkgdb/acls/name/kio_gopher
(I don't use uucp though, but I see from Kevin Fenzi's reply that there's at
least one person using that too. :-p)
Who uses floppy?
Me. And I'm already angry at having to manually modprobe floppy in rc.local:
https://bugzilla.redhat.com/show_bug.cgi?id=567533
Kevin Kofler
8:49 p.m.
On Sun, Nov 21, 2010 at 03:33:56AM +0100, Kevin Kofler wrote:
Me. And I'm already angry at having to manually modprobe floppy
in rc.local:
https://bugzilla.redhat.com/show_bug.cgi?id=567533
If you're "angry" about a minor inconvenience then I think you might
want to seek counsel, but for what it's worth, I'm sorry I haven't
gotten around to poking ACPI to see if there's a floppy connected.
regards, Kyle
10:39 a.m.
On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote:
On Sun, Nov 21, 2010 at 03:33:56AM +0100, Kevin Kofler wrote:
> Me. And I'm already angry at having to manually modprobe floppy in rc.local:
> https://bugzilla.redhat.com/show_bug.cgi?id=567533
If you're "angry" about a minor inconvenience then I think you might
want to seek counsel, but for what it's worth, I'm sorry I haven't
gotten around to poking ACPI to see if there's a floppy connected.
Hi Kevin, (and Bruno if you're watching)
Please try this:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153
And let me know what the output is on your machine (it uses ACPI to
query the _FDE table in firmware, so hopefully we can only bind to it if
a floppy is connected.)
Grepping for 'fde' and 'floppies' should give me in the info I need.
regards, Kyle
8 p.m.
On Mon, Nov 22, 2010 at 11:39:29 -0500,
Kyle McMartin <kyle(a)mcmartin.ca> wrote:
Hi Kevin, (and Bruno if you're watching)
Please try this:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153
I've been running that kernel for a couple of days on one machine
with floppies. (I am go to switch to -62 tonight.) Two other machines
I have with floppies are running rawhide. One is essentially the same
as the one I with get the info from shortly. The other is significantly
different.
And let me know what the output is on your machine (it uses ACPI to
query the _FDE table in firmware, so hopefully we can only bind to it if
a floppy is connected.)
Grepping for 'fde' and 'floppies' should give me in the info I need.
I'm going to start by assuming you want us to look at dmesg output.
8:24 p.m.
On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153
I've been running that kernel for a couple of days on one machine
with floppies. (I am go to switch to -62 tonight.) Two other machines
I have with floppies are running rawhide. One is essentially the same
as the one I with get the info from shortly. The other is significantly
different.
Unlikely, given I only built it on Sunday night... It's a scratch build
with a patch included.
(Yes, the messages would be in dmesg.)
8:31 p.m.
On Mon, Nov 22, 2010 at 21:24:41 -0500,
Kyle McMartin <kyle(a)mcmartin.ca> wrote:
On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153
>
> I've been running that kernel for a couple of days on one machine
> with floppies. (I am go to switch to -62 tonight.) Two other machines
> I have with floppies are running rawhide. One is essentially the same
> as the one I with get the info from shortly. The other is significantly
> different.
Unlikely, given I only built it on Sunday night... It's a scratch build
with a patch included.
(Yes, the messages would be in dmesg.)
I saw a -61 and assumed it was the same build. I was going to double check.
Things are taking me longer to do here as I am having some annoying video
problems with rawhide. It takes a long time to switch work spaces and some
times raising windows is also takes a long time.
Anyway, I'll try it out on one machine in a little bit.
9:32 p.m.
On Mon, Nov 22, 2010 at 21:16:40 -0600,
Bruno Wolff III <bruno(a)wolff.to> wrote:
On Mon, Nov 22, 2010 at 21:24:41 -0500,
Kyle McMartin <kyle(a)mcmartin.ca> wrote:
> (Yes, the messages would be in dmesg.)
[ 2.691809] acpi_fde: failed to evaluate _FDE
[ 2.692151] Floppy drive(s): fd0 is 1.44M
[ 2.724514] floppy: loaded
/dev/fd0 was created.
I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted to make
sure I hadn't put something on that machine to make the floppy available
at boot.)
So the patch looks good from the perspective of people who have floppies.
I think I can test it on a machine that doesn't have a floppy drive
tomorrow.
9:53 p.m.
On Mon, Nov 22, 2010 at 09:32:09PM -0600, Bruno Wolff III wrote:
> [ 2.691809] acpi_fde: failed to evaluate _FDE
> [ 2.692151] Floppy drive(s): fd0 is 1.44M
> [ 2.724514] floppy: loaded
>
> /dev/fd0 was created.
Yeah, it falls back to the ordinary probing if anything fails.
Can you send me (privately if you want, or fpaste) the dmesg of the
machine?
--Kyle
I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted
to make
sure I hadn't put something on that machine to make the floppy available
at boot.)
So the patch looks good from the perspective of people who have floppies.
I think I can test it on a machine that doesn't have a floppy drive
tomorrow.
8:07 p.m.
On Mon, Nov 22, 2010 at 11:39:29 -0500,
Kyle McMartin <kyle(a)mcmartin.ca> wrote:
On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote:
And let me know what the output is on your machine (it uses ACPI to
query the _FDE table in firmware, so hopefully we can only bind to it if
a floppy is connected.)
Grepping for 'fde' and 'floppies' should give me in the info I need.
I didn't find either string in messages or dmesg output. My machines are
all from around 2003, in case more recent ACPI support is needed.
4895
days inactive
4907
days old
162 comments
63 participants
participants (63)
-
Adam Jackson -
Adam Williamson -
Alasdair G. Kergon -
Bastien Nocera -
Ben Boeckel -
Brendan Jones -
Bruno Wolff III -
Casey Dahlin -
Chen Lei -
Chris Adams -
Chris Jones -
Chris Lumens -
Colin Walters -
David Woodhouse -
Dennis Jacobfeuerborn -
Dominik 'Rathann' Mierzejewski -
drago01 -
Eric Sandeen -
Frank Murphy -
Garrett Holmstrom -
Genes MailLists -
Hedayat Vatankhah -
Jan Kratochvil -
Jaroslav Reznik -
Javier Jardón -
John Reiser -
Jon Masters -
Josef Bacik -
Jóhann B. Guðmundsson -
Karel Klic -
Kevin Fenzi -
Kevin Kofler -
Kyle McMartin -
Lennart Poettering -
Liang Suilong -
linux guy -
Matt Domsch -
Matt McCutchen -
Matthew Garrett -
Matthew Miller -
Michael Cronenworth -
Michał Piotrowski -
Michel Alexandre Salim -
Mike McGrath -
Milan Broz -
Miloslav Trmač -
Nathaniel McCallum -
Nicolas Mailhot -
Owen Taylor -
Paul Wouters -
Peter Hutterer -
Peter Jones -
Peter Robinson -
Ralf Ertzinger -
Ric Wheeler -
Richard W.M. Jones -
Richard Z -
Roberto Ragusa -
Robyn Bergeron -
Sam Varshavchik -
Tom Callaway -
Tomasz Torcz -
Will Woods