On May 18, Mathieu Malaterre wrote:
> Could a udev guru please comment on the (somewhat) famous issue
> `Transport endpoint is not connected` happening when a udev rule tries
> to mount fuse filesystem ? The only description I found of this issue
I think that the fuse process is being killed.
You
On Monday 18 May 2015 15:10:56 Mathieu Malaterre wrote:
> 1. What is the actual issue of ``udev`` vs ``fuse``
> 2. What (if possible) is needed to make a *udev* rules mount a FUSE
> filesystem (I do not really care for proper umount for now).
I can only guess that:
- mounting a file system with fu
I have seen this issue outside of udev, for iRODS mounting filesystems
via fuse;
if there was a break in connectivity (network) the kernel driver would
crash,
and this problem would occur.
On 18/05/2015 14:10, Mathieu Malaterre wrote:
> On Mon, May 18, 2015 at 3:00 PM, Dominique Dumont wrote:
>>
On Mon, May 18, 2015 at 3:00 PM, Dominique Dumont wrote:
> On Monday 18 May 2015 14:13:46 Mathieu Malaterre wrote:
>> Could a udev guru please comment on the (somewhat) famous issue
>> `Transport endpoint is not connected` happening when a udev rule tries
>> to mount fuse filesystem ? The only des
On Monday 18 May 2015 14:13:46 Mathieu Malaterre wrote:
> Could a udev guru please comment on the (somewhat) famous issue
> `Transport endpoint is not connected` happening when a udev rule tries
> to mount fuse filesystem ? The only description I found of this issue
> appear on archlinux wiki, it d
> Ben Hutchings writes:
> On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote:
[…]
>> BTW, does the root=UUID= variant require udev as well?
> Yes, currently the kernel filesystem code does not probe for filesystem
> UUIDs. (However, it does support partition UUIDs as used in GPT.
On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote:
> > Timo Juhani Lindfors writes:
> > Ivan Shmakov writes:
>
> >> And what the initramfs-tools package has to do with consistent
> >> devices' filenames?
>
> > Initramfs runs udev. This allows you to use e.g.
>
> > root=/dev/di
On Mon, 24 Oct 2011 23:08:33 +0700
Ivan Shmakov wrote:
> > Anyway, I think that if you want to learn how udev works then you
> > should send your questions to an users support mailing
> > list/newsgroup/forum/etc.
>
> Well, seems like there're little specific to Debian in how udev
>
On Mon, 24 Oct 2011 21:20:01 +0700
Ivan Shmakov wrote:
> > Neil Williams writes:
> > On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote:
>
> > udev isn't just for pluggable devices, packages can provide udev
> > rules to ensure that devices appear with a consistent name,
>
>
> Marco d'Itri writes:
> On Oct 24, Ivan Shmakov wrote:
>> So, the kernel won't try to autoload a module when the corresponding
>> device gets accessed?
> Not for *hardware* drivers, since it cannot know which driver is
> needed.
Not even via modprobe.conf(5)?
>> I've nev
On Oct 24, Ivan Shmakov wrote:
> So, the kernel won't try to autoload a module when the
> corresponding device gets accessed?
Not for *hardware* drivers, since it cannot know which driver is needed.
> I've never heard of that (and Googling for “linux equiv” doesn't
> seem
> Timo Juhani Lindfors writes:
> Ivan Shmakov writes:
>> And what the initramfs-tools package has to do with consistent
>> devices' filenames?
> Initramfs runs udev. This allows you to use e.g.
> root=/dev/disk/by-id/ata-WDC_WD3200AAJS-65B4A0_WD-WMAT13954017-part1
> instead of
> Marco d'Itri writes:
> On Oct 24, Ivan Shmakov wrote:
>> It doesn't seem like a good reason for the aforementioned
>> dependency, does it?
> There are many other reasons, you can find them in /lib/udev/.
ACK, thanks.
>> And what the initramfs-tools package has to do with
Ivan Shmakov writes:
> And what the initramfs-tools package has to do with consistent
> devices' filenames?
Initramfs runs udev. This allows you to use e.g.
root=/dev/disk/by-id/ata-WDC_WD3200AAJS-65B4A0_WD-WMAT13954017-part1
instead of
root=/dev/sda1
to specify where your root fi
On Oct 24, Ivan Shmakov wrote:
> It doesn't seem like a good reason for the aforementioned
> dependency, does it?
There are many other reasons, you can find them in /lib/udev/.
> And what the initramfs-tools package has to do with consistent
> devices' filenames?
udev is
> Neil Williams writes:
> On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote:
>> I've found that a few packages, contrary to my expectations, have
>> Depends: on udev. I'm primarily concerned with alsa-base and
>> initramfs-tools, but also wonder about libcomedi0, dkopp,
>> python
On Mon, 24 Oct 2011 18:19:08 +0700
Ivan Shmakov wrote:
> I've found that a few packages, contrary to my expectations,
> have Depends: on udev. I'm primarily concerned with alsa-base
> and initramfs-tools, but also wonder about libcomedi0, dkopp,
> python-expeyes, libnjb5,
> Try dosfslabel instead of mlabel. If that works, report a bug in
> mtools. If not... I don't know.
>
> Ben.
Hi Ben,
I tried dosfslabel, just as you told me. It is possible, to add a new label to
the device, which is then seen by the system.
So far this will work for very fine for me, when
On Mon, Mar 07, 2011 at 08:05:22PM +0100, Hans-J. Ullrich wrote:
>
> > Labels and UUIDs are stored only on the filesystems they come from and
> > in the blkid cache in /etc/blkid.tab. That cache is cleared and
> > regenerated whenever you reboot. You can do this at any time by
> > running:
> >
> Labels and UUIDs are stored only on the filesystems they come from and
> in the blkid cache in /etc/blkid.tab. That cache is cleared and
> regenerated whenever you reboot. You can do this at any time by
> running:
>
> blkid -c /dev/null -w /etc/blkid.tab
>
> udev does not have a database
On Sun, 2011-03-06 at 18:37 +0100, Hans-J. Ullrich wrote:
> Dear developers,
>
> I got the proble, that a once given label is stored by udev, although the
> label of the device is deleted by mlabel.
>
> Whenever I put it in, the device keeps its first given label, as it is stored
> in its databa
On Sun, 18 Jul 2010, "Hans-J. Ullrich" wrote:
> /usr/sbin/pppd: using the noauth option requires root privileges
>
> This message was the reason for my very first report. What did I miss? Is
> there something else I should check?
The man page gives some information on this. If that isn't enoug
Am Sonntag, 18. Juli 2010 schrieben Sie:
> On Sun, 18 Jul 2010, "Hans-J. Ullrich" wrote:
> > Is it corrrect, what russel told, that /usr/sbin/pppd should be set to
> > rwxsrxr-x root:dip ?
>
> It should not be set to 04755 unless you want everyone on the system to be
> able to run it - which prob
On Jul 18, "Hans-J. Ullrich" wrote:
> Mine is set to rwxr-xr-x root:root, although it is installed by default (I
> didn't change anything).
I highly doubt it. This is how it is installed on Debian systems:
-rwsr-xr-- 1 root dip 269540 Jul 26 2008 /usr/sbin/pppd*
--
ciao,
Marco
signature.a
On Sun, 18 Jul 2010, "Hans-J. Ullrich" wrote:
> Is it corrrect, what russel told, that /usr/sbin/pppd should be set to
> rwxsrxr-x root:dip ?
It should not be set to 04755 unless you want everyone on the system to be
able to run it - which probably isn't what you desire.
On my system it is 047
Am Sonntag, 18. Juli 2010 schrieb Marco d'Itri:
> Maybe this program needs to be modified to use a suid helper or a
> daemon which interacts with the hardware.
> But I can't see why it would need access to /dev/ppp.
Marco,
this problem is tellling: cant get access to /dev/ppp when it is started
On Jul 17, "Hans-J. Ullrich" wrote:
> Sorry. if I am wrong, I am not very well experienced with the required access
> rights. The background of my report is, that I tried to start the application
> "umtsmon" (a dialout application for 3g-modems) as a normal user, and I found
> no way to start
On Jul 17, Petter Reinholdtsen wrote:
> [Marco d'Itri]
> > We have group dip to manage access to programs which can start
> > network connections.
> How does this interact with policykit? I was told that policykit uses
It does not.
> ACLs to grant device access to those that should have it, but
On Sun, 18 Jul 2010, "Hans-J. Ullrich" wrote:
> Sorry. if I am wrong, I am not very well experienced with the required
> access rights. The background of my report is, that I tried to start the
> application "umtsmon" (a dialout application for 3g-modems) as a normal
> user, and I found no way to
On Sat, Jul 17, 2010 at 09:45:52PM +0200, Hans-J. Ullrich wrote:
> Normal users, which are allowed to dial out, should be added to group
> "dialout" by root. Device /dev/ppp should be set to 660, and owner
> root:dialout.
You should read: /usr/share/doc/base-passwd/users-and-groups.html
dialou
Am Samstag, 17. Juli 2010 schrieb Marco d'Itri:
> On Jul 17, "Hans-J. Ullrich" wrote:
> > applications, which are using /dev/ppp also must be run as root. I think,
> > for
>
> We have group dip to manage access to programs which can start network
> connections.
>
Sorry. if I am wrong, I am not v
[Marco d'Itri]
> We have group dip to manage access to programs which can start
> network connections.
How does this interact with policykit? I was told that policykit uses
ACLs to grant device access to those that should have it, but have not
verified that it is true. Mentioning it here to see
On Jul 17, "Hans-J. Ullrich" wrote:
> applications, which are using /dev/ppp also must be run as root. I think, for
We have group dip to manage access to programs which can start network
connections.
> Normal users, which are allowed to dial out, should be added to group
> "dialout" by root. D
Hi Julien!
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
>
> > khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> > Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> > Modem / E270 HSDPA/HSUPA Mode
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
> khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> Modem / E270 HSDPA/HSUPA Modem
> lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> /dev/serial/by-id
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
> > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > > setup
> > > the (udev) env
Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
>> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>>> setup
>>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>>> (75
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > setup
> > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > (75-net-description.rules, 75-tty-descrip
Le lundi 07 septembre 2009 à 17:29 +0200, Michael Biebl a écrit :
> > So, again, why can't the programs that want to display this do the
> > lookup themselves? Both libpciaccess and libpci provide API for this as
> > far as I can tell.
>
> I am sure, they could. My guess is, it was added to udev
Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>
>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>> setup
>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>> (75-net-description.rules, 75-tty-description.rules, 78-sound-c
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> From what I can see in /lib/udev/rules.d, the ids files are only used to setup
> the (udev) environment variable ID_VENDOR_FROM_DATABASE
> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
>
> There are no sym
Henrique de Moraes Holschuh wrote:
> IMO, whomever came up with the idea of leaking pci.ids and usb.ids data to
> /dev, made a bad mistake. Just because you'd show something in an UI,
> doesn't mean it can be used to permanently identify a device safely. I have
> no idea what HAL, and HAL-consume
On Mon, 07 Sep 2009, Michael Biebl wrote:
> Henrique de Moraes Holschuh wrote:
> > So why exactly should we support this breakage in udev, again? If what it
> > takes is to move the usb and pci ID databases to /, so be it. When compared
> > to our kernel tarballs, they're small, less than 1MB for
Henrique de Moraes Holschuh wrote:
> So why exactly should we support this breakage in udev, again? If what it
> takes is to move the usb and pci ID databases to /, so be it. When compared
> to our kernel tarballs, they're small, less than 1MB for both of them.
Agreed. Moving usb.ids and pci.id
On Fri, 04 Sep 2009, Marco d'Itri wrote:
> On Sep 04, Ron Johnson wrote:
> > Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red H
On Sun, 2009-09-06 at 05:01 +0200, Marco d'Itri wrote:
> On Sep 06, Steve Langasek wrote:
> > It's normal that in the process of drafting a standard, people will take
> > into account the prevailing real-world practices, to ensure that the
> > standard will be useful. Once something *is a standa
On Sep 06, Steve Langasek wrote:
> If you're unable to persuade upstream to change their implementation, and
> you're unwilling to diverge from upstream to ensure the package complies
> with Debian policy, your other option is to orphan the package and let
I am willing to diverge from upstream an
On Sun, Sep 06, 2009 at 12:56:03AM +0200, Marco d'Itri wrote:
> > > They are currently providing most of the manpower for developing udev
> > > and the related infrastructure so this is pretty much the practical
> > > effect, yes.
> > So what, you think this means we don't have any right to object
On Sep 05, Steve Langasek wrote:
> > They are currently providing most of the manpower for developing udev
> > and the related infrastructure so this is pretty much the practical
> > effect, yes.
> So what, you think this means we don't have any right to object when they
> design things wrong?
No
On 2009-09-05, Goswin von Brederlow wrote:
>>> Mounting NFS volumes from
>>> the initramfs is probably not worth the effort.
>> How do you make root on NFS work without this?
> By building a kernel with nfsroot support and mounting without
> locking and specific nfs version.
>
> I'm not sure if in
Petter Reinholdtsen writes:
> [Bastian Blank]
>> Why do you not extend the current setup to do another step?
>> Currently we have two
>> - in the initramfs with only minimal information and
>> - during the rcS run with / available.
>
> Eh, currently we have 5 sections during the boot:
>
> - init
Josselin Mouette writes:
> Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit :
>> In Debian, /usr/ is allowed to be on NFS.
>
> So is /.
>
>> Mounting NFS volumes from
>> the initramfs is probably not worth the effort.
>
> How do you make root on NFS work without this?
By
sean finney writes:
> On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote:
>> Jonas Meurer wrote:
>> >do we really consider to stop support for seperate /usr? after all fhs
>> >supports seperate /usr by design. [1]
>> >i hope that we keep fhs compability within debian.
>>
>> I a
On Fri, Sep 04, 2009 at 09:12:03PM +0200, Marco d'Itri wrote:
> > But I guess Red Hat and Suse decide. Debian does what they do, nobody
> They are currently providing most of the manpower for developing udev
> and the related infrastructure so this is pretty much the practical
> effect, yes.
So w
On Fri, Sep 04, 2009 at 06:58:18PM +0200, Marco d'Itri wrote:
> On Sep 04, Bastian Blank wrote:
>
> > Why do you not extend the current setup to do another step? Currently we
> Even if this were possible at all, it would require (for a start):
> - working out all the possible side effects of synt
m...@linux.it (Marco d'Itri) writes:
> On your part, you could try to understand them instead of attributing to
> me straw man positions.
That's a good advice. Thanks. Please help me understand: What is the
usb-db and/or pci-db use case?
I'm afraid my creative imagination is far too limited to
On Sep 04, Bjørn Mork wrote:
> The issue is most certainly raised by other distributions. See e.g. the
> thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973
This is about the micromanagement of dependencies which greatly excites
Gentoo users, so is not very relevant (and
Bjørn Mork wrote:
Personally I really can't see why these addons (usb-db,pci-db) are so
important. Nobody has demonstrated a usecase for them. Yet you make it
sound like there is no choice at all, but to include them in udev.
Seconded. The Debian 5 system I just built (2.6.29 kernel from
b
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Ron Johnson wrote:
>
>> Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red Hat
On Sep 04, Bastian Blank wrote:
> Why do you not extend the current setup to do another step? Currently we
Even if this were possible at all, it would require (for a start):
- working out all the possible side effects of synthesizing all/most
(which ones?) events a second time
- having to forwa
On Sep 04, Ron Johnson wrote:
> Whatever the cause, it breaks the FHS.
Since it keeps being repeated, it is time to destroy this argument.
FHS documents what distributions want to do: of the other relevant
distributions, representatives from Red Hat and Suse said they do not
support this and exce
[Bastian Blank]
> Why do you not extend the current setup to do another step?
> Currently we have two
> - in the initramfs with only minimal information and
> - during the rcS run with / available.
Eh, currently we have 5 sections during the boot:
- initramfs with minimal set of files available.
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leadin
On 2009-09-04 07:46, Marco d'Itri wrote:
On Sep 04, Gabor Gombas wrote:
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design, udev was originally
praised because it can do everything in user space. Now, the authors of
udev are propo
On Sep 04, Gabor Gombas wrote:
> Incompetent, no. Careless, yes. Just think about the udev-related
> breakages in the past. And speaking about design, udev was originally
> praised because it can do everything in user space. Now, the authors of
> udev are proposing devtmpfs, because as it turned
On Fri, Sep 04, 2009 at 11:41:41AM +0200, Marco d'Itri wrote:
> So you believe that the upstream maintainers are incompetent and
> released something which is unreliable by design?
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design,
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Bjørn Mork wrote:
>
>> Yes. Any device specific matching should use vid:pid. How about just
>> disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
>> getting any users of this info in Debian? It will always be too
>> unreliabl
On Fri, Sep 4, 2009 at 11:41:41 +0200, Marco d'Itri wrote:
> On Sep 04, Steve Langasek wrote:
>
> > I still can't fathom why someone decided that udev should be responsible for
> > translating PCI IDs and USB IDs into text strings. This smells of crazy.
> I think that part of the rationale is
On Sep 04, Steve Langasek wrote:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
I think that part of the rationale is that eventually HAL will go away
replaced by udev and programs like thi
Steve Langasek writes:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers al
Steve Langasek wrote:
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
> >>> The issue was raised by the udev upstream maintainer along with the udev
> >>> package maintainers of the major distributions, who all agreed that this
> >>> configuration is not supported.
> >> FYI, udev 146 ships usb-id and pci
Giacomo A. Catenazzi wrote:
> Marco d'Itri wrote:
>> On May 31, md wrote:
>>
>>> The issue was raised by the udev upstream maintainer along with the udev
>>> package maintainers of the major distributions, who all agreed that this
>>> configuration is not supported.
>> FYI, udev 146 ships usb-id a
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff
>
> | I have ~600 Machines in the field - all with /usr on a seperate fs - If
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.
>
> I'
On Wed, Sep 02, 2009 at 11:11:31PM +0200, Josselin Mouette wrote:
> Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
> > /usr was on seperate filesystems for decades and some 3733t broken by design
> > Desktop utility turns around old Unix paradigms? I dont get it ...
>
> Sin
On Thu, 03 Sep 2009 13:23:11 +0200, Marc Haber
wrote:
>On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff
>wrote:
>>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>>is going to make seperate /usr a no-go its about 30 Euros worth
>>of field Engineer time - swappi
On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff
wrote:
>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>is going to make seperate /usr a no-go its about 30 Euros worth
>of field Engineer time - swapping disks.
>
>/usr was on seperate filesystems for decades an
Josselin Mouette wrote:
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
/usr was on seperate filesystems for decades and some 3733t broken by design
Desktop utility turns around old Unix paradigms? I dont get it ...
Since when is udev a desktop utility?
hmm. udev doesn'
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff
> | I have ~600 Machines in the field - all with /usr on a seperate fs - If
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.
> I'm fa
]] Florian Lohoff
| I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
| is going to make seperate /usr a no-go its about 30 Euros worth
| of field Engineer time - swapping disks.
I'm fairly sure I can sell you a small shell script that you can install
in the init
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
> /usr was on seperate filesystems for decades and some 3733t broken by design
> Desktop utility turns around old Unix paradigms? I dont get it ...
Since when is udev a desktop utility?
--
.''`. Josselin Mouette
: :' :
On Wed, Sep 02, 2009 at 04:26:08AM +0200, Marco d'Itri wrote:
> On Sep 01, Steve Langasek wrote:
> > You are drawing an artificial distinction between /usr and /var which is not
> > consistent with the standard, nor with how I've been laying out my
> > filesystems for years. I'm not going to refa
Marco d'Itri wrote:
On May 31, md wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/u
On Sep 01, Steve Langasek wrote:
> Why do programs need udev to read this information in at driver load time?
> Why can't packages that need this information query it when they need it
> (which is well after /usr is mounted), instead of expecting udev to provide
> it?
I did not design this aspect
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> > The issue was raised by the udev upstream maintainer along with the udev
> > package maintainers of the major distributions, who all agreed that this
> > configuration is not supported.
> FYI, udev 146 ships usb-id and pci-id progra
Neil McGovern wrote:
Do we only support network configuration with DHCP now?
That's not the point, the slightly off-topic point we got onto was that
you can in fact share / between hosts if you're using DHCP. I don't
think the FHS supports it, but I can see uses for it in places.
--
Chris
On Tue, Sep 01, 2009 at 04:47:54PM +0200, Josselin Mouette wrote:
> Le mardi 01 septembre 2009 à 15:36 +0100, Chris Jackson a écrit :
> > Well, /etc needs to be on /, since otherwise you can't get to fstab to
> > mount it, and generally things like /etc/hostname will be different, so,
> > while
On Sep 01, Gabor Gombas wrote:
> How about re-running the rules after all the filesystems have been
> mounted?
No.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote:
> > How will usb-id and pci-id behave, if the ids files are not accessible?
> Print an error on stderr and exit with rc=1.
> The more interesting question is which packages care about this
> information and how they will behave when it
Josselin Mouette wrote:
Ever heard of DHCP ?
Mmm, fair enough. Anyway, it isn't true that what's said about /usr also
applies to / since, once init is running (and a little before that), we
definitely have a /, but may not have a /usr yet, or /usr may fail to
mount. I'm not 100% sure wheth
Le mardi 01 septembre 2009 à 15:36 +0100, Chris Jackson a écrit :
> Well, /etc needs to be on /, since otherwise you can't get to fstab to
> mount it, and generally things like /etc/hostname will be different, so,
> while I suppose it's theoretically possible, I'd take it also to be
> somewhat
Josselin Mouette wrote:
/ is shareable as well, if you mount it read-only.
Everything that has been said about /usr in this thread can also be said
about /, so please think about it before making propositions.
Well, /etc needs to be on /, since otherwise you can't get to fstab to
mount it,
Le mardi 01 septembre 2009 à 13:41 +0100, Chris Jackson a écrit :
> Well, /usr is supposed to be shareable between hosts; forcing it to be
> on the same filesystem as / is very sub-optimal.
/ is shareable as well, if you mount it read-only.
Everything that has been said about /usr in this threa
On Tue, Sep 01, 2009 at 11:18:47AM +0200, Giacomo A. Catenazzi wrote:
> Josselin Mouette wrote:
> >Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a
> >écrit :
> >>In Debian, /usr/ is allowed to be on NFS.
> >
> >So is /.
>
> I was thinking the same, but #441291 (root over nfs) is st
Mike Hommey wrote:
An interesting corollary is how will upgraded systems behave ? A lot of
the currently installed ones have a separate /usr. It would be a shame to
tell users they have to reinstall (or go through hoops to put /usr in /)
Well, /usr is supposed to be shareable between hosts; f
On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote:
> Jonas Meurer wrote:
> >do we really consider to stop support for seperate /usr? after all fhs
> >supports seperate /usr by design. [1]
> >i hope that we keep fhs compability within debian.
>
> I agree, but the problem is "how?
Jonas Meurer wrote:
do we really consider to stop support for seperate /usr? after all fhs
supports seperate /usr by design. [1]
i hope that we keep fhs compability within debian.
I agree, but the problem is "how?".
Moving too much thinkgs from /usr to / is also against
the design of FHS, thus
hey,
On 01/09/2009 Mike Hommey wrote:
> On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote:
> > On Sep 01, Michael Biebl wrote:
> >
> > > Wouldn't make it sense then if udev had a recommends or at least suggests
> > > for
> > > usbutils and pciutils?
> > Yes, the next upload (today i
1 - 100 of 181 matches
Mail list logo
