Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #173840 > unrolled thread

Permissions for an entire PARTITION

Back to article view | Back to linux.debian.user

Contents

  Permissions for an entire PARTITION Richard Owlett <rowlett@cloud85.net> - 2016-10-25 17:40 +0200
    Re: Permissions for an entire PARTITION Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-25 17:50 +0200
      Re: Permissions for an entire PARTITION <tomas@tuxteam.de> - 2016-10-25 18:10 +0200
      Re: Permissions for an entire PARTITION Richard Owlett <rowlett@cloud85.net> - 2016-10-25 18:40 +0200
        Re: Permissions for an entire PARTITION Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-25 18:50 +0200
          Re: Permissions for an entire PARTITION Richard Owlett <rowlett@cloud85.net> - 2016-10-28 17:30 +0200
            Re: Permissions for an entire PARTITION Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-28 17:50 +0200
            Re: Permissions for an entire PARTITION Jörg-Volker Peetz <jvpeetz@web.de> - 2016-10-28 21:40 +0200
              EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Richard Owlett <rowlett@cloud85.net> - 2016-10-28 22:50 +0200
                Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] "John L. Ries" <jries@salford-systems.com> - 2016-10-28 23:10 +0200
                Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-29 00:20 +0200
                  Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Richard Owlett <rowlett@cloud85.net> - 2016-10-29 01:40 +0200
                    Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Reco <recoverym4n@gmail.com> - 2016-10-29 11:20 +0200
                      Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] rhkramer@gmail.com - 2016-10-29 14:20 +0200
                        Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Reco <recoverym4n@gmail.com> - 2016-10-29 15:00 +0200
                          Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-29 16:10 +0200
                            Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Reco <recoverym4n@gmail.com> - 2016-10-29 17:50 +0200
                              Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-29 20:20 +0200
                                Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Reco <recoverym4n@gmail.com> - 2016-10-29 22:30 +0200
                                  Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-30 00:50 +0200
                                    Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Reco <recoverym4n@gmail.com> - 2016-10-30 10:30 +0100
                                      Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-30 14:00 +0100
                                        Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] rhkramer@gmail.com - 2016-10-30 14:20 +0100
                                          Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-30 18:10 +0100
                          Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] rhkramer@gmail.com - 2016-10-29 21:30 +0200
                            Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-29 22:00 +0200
                              Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] rhkramer@gmail.com - 2016-10-29 22:30 +0200
                                Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Brian <ad44@cityscape.co.uk> - 2016-10-30 01:10 +0200
                                  Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] rhkramer@gmail.com - 2016-10-30 01:20 +0200
                                    Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] Lisi Reisz <lisi.reisz@gmail.com> - 2016-10-30 13:00 +0100
                    Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION] David Wright <deblis@lionunicorn.co.uk> - 2016-10-31 02:30 +0100
            Re: Permissions for an entire PARTITION Jochen Spieker <ml@well-adjusted.de> - 2016-10-29 15:30 +0200
        Re: Permissions for an entire PARTITION Jochen Spieker <ml@well-adjusted.de> - 2016-10-25 19:40 +0200
        Re: Permissions for an entire PARTITION <tomas@tuxteam.de> - 2016-10-26 10:20 +0200
          Re: Permissions for an entire PARTITION rhkramer@gmail.com - 2016-10-26 13:20 +0200
            Re: Permissions for an entire PARTITION Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-26 14:30 +0200
              Re: Permissions for an entire PARTITION <tomas@tuxteam.de> - 2016-10-26 14:50 +0200
              Re: Permissions for an entire PARTITION Tixy <tixy@yxit.co.uk> - 2016-10-27 07:50 +0200

Page 1 of 2  [1] 2  Next page →

#173840 — Permissions for an entire PARTITION

I'm in a multi-boot environment, multiple installs of Debian.
I want all install to have read/write/execute permissions.
The partition will effectively be serving as a common scratch pad 
in order to exchange information. There is organically a single 
user, [*ME*] and there is *NO* networking of any sort whatsoever.

How?
TIA

[toc] | [next] | [standalone]

#173841

On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote:
> I'm in a multi-boot environment, multiple installs of Debian.
> I want all install to have read/write/execute permissions.
> The partition will effectively be serving as a common scratch pad 
> in order to exchange information. There is organically a single 
> user, [*ME*] and there is *NO* networking of any sort whatsoever.

The simplest way would be to synchronize your UID across all your
installed operating systems.  If your UID is, let's say, 1000 on every
system, and the files on the partition are owned by user 1000, then
user 1000 (you) will have ownership of the files whenever you mount
the partition.

If that's not an option, then you'll need to use Unix permissions.
If you can synchronize a *group* GID across all OSes, then you can
just make the files and directories group-writable by that group.

Otherwise, you'll have to make everything world-writable.

[toc] | [prev] | [next] | [standalone]

#173842

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 25, 2016 at 11:40:10AM -0400, Greg Wooledge wrote:
> On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote:
> > I'm in a multi-boot environment, multiple installs of Debian.
> > I want all install to have read/write/execute permissions.
> > The partition will effectively be serving as a common scratch pad 
> > in order to exchange information. There is organically a single 
> > user, [*ME*] and there is *NO* networking of any sort whatsoever.
> 
> The simplest way would be to synchronize your UID across all your
> installed operating systems.  If your UID is, let's say, 1000 on every
> system, and the files on the partition are owned by user 1000, then
> user 1000 (you) will have ownership of the files whenever you mount
> the partition.
> 
> If that's not an option, then you'll need to use Unix permissions.
> If you can synchronize a *group* GID across all OSes, then you can
> just make the files and directories group-writable by that group.
> 
> Otherwise, you'll have to make everything world-writable.

Well, there's bindfs [1], where you can (via FUSE) mount a directory
somewhere else, and (among other things) map user/group IDs. Never
tried it, but it sounds like hellish fun. I'd prefer synchronizing
the IDs, though. But in a pinch...

There is a like-named Debian package.

[1] http://bindfs.org/docs/bindfs.1.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgPgU0ACgkQBcgs9XrR2kYHfQCdENS+HXbiFqhFEdCNBv6uwNvN
82gAnRcltXzyyF8fr+FJmeV1a26QzTnL
=piYm
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#173843

On 10/25/2016 10:40 AM, Greg Wooledge wrote:
> On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote:
>> I'm in a multi-boot environment, multiple installs of Debian.
>> I want all install to have read/write/execute permissions.
>> The partition will effectively be serving as a common scratch pad
>> in order to exchange information. There is organically a single
>> user, [*ME*] and there is *NO* networking of any sort whatsoever.
>
> The simplest way would be to synchronize your UID across all your
> installed operating systems.  If your UID is, let's say, 1000 on every
> system, and the files on the partition are owned by user 1000, then
> user 1000 (you) will have ownership of the files whenever you mount
> the partition.

That sounds like what I want.
I had previously created a ext2 partition on /dev/sda10 and a 
label of jessie-dvds .
How do I inform the "WORLD" that it belongs to UID 1000?
Right now when I attempt to mount it, I am asked for root password.
Not acceptable.

tomas' reply confused me ;/

>
> If that's not an option, then you'll need to use Unix permissions.
> If you can synchronize a *group* GID across all OSes, then you can
> just make the files and directories group-writable by that group.
>
> Otherwise, you'll have to make everything world-writable.
>
>

[toc] | [prev] | [next] | [standalone]

#173847

On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote:
> On 10/25/2016 10:40 AM, Greg Wooledge wrote:
> >The simplest way would be to synchronize your UID across all your
> >installed operating systems.  If your UID is, let's say, 1000 on every
> >system, and the files on the partition are owned by user 1000, then
> >user 1000 (you) will have ownership of the files whenever you mount
> >the partition.
> 
> That sounds like what I want.
> I had previously created a ext2 partition on /dev/sda10 and a 
> label of jessie-dvds .
> How do I inform the "WORLD" that it belongs to UID 1000?

Err... what?  I don't understand what you're asking.

You boot into an installed operating system.  Let's say it's Debian
wheezy.

You login as some user account.  Let's say it's "richard" with UID 1000.

Now you are richard, and you are UID 1000.

When the partition is mounted, any files on it that are owned by UID
1000 are yours for the taking.  You are UID 1000, even if the files
were created by UID 1000 from a different operating system.

> Right now when I attempt to mount it, I am asked for root password.
> Not acceptable.

So your actual question is how to *mount* the partition?  In the fstab
file, include the "user" option to allow non-root users to mount the
partition.  Better still, just make the partition mount automatically
at boot time (defaults).

Is there a particular reason you wanted the partition NOT to be mounted
by default, and to require the logged-in user to enter a command?

[toc] | [prev] | [next] | [standalone]

#173944

On 10/25/2016 11:42 AM, Greg Wooledge wrote:
> On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote:
>> On 10/25/2016 10:40 AM, Greg Wooledge wrote:
>>> The simplest way would be to synchronize your UID across all your
>>> installed operating systems.  If your UID is, let's say, 1000 on every
>>> system, and the files on the partition are owned by user 1000, then
>>> user 1000 (you) will have ownership of the files whenever you mount
>>> the partition.
>>
>> That sounds like what I want.
>> I had previously created a ext2 partition on /dev/sda10 and a
>> label of jessie-dvds .
>> How do I inform the "WORLD" that it belongs to UID 1000?
>
> Err... what?  I don't understand what you're asking.
>
> You boot into an installed operating system.  Let's say it's Debian
> wheezy.
>
> You login as some user account.  Let's say it's "richard" with UID 1000.
>
> Now you are richard, and you are UID 1000.
>
> When the partition is mounted, any files on it that are owned by UID
> 1000 are yours for the taking.  You are UID 1000, even if the files
> were created by UID 1000 from a different operating system.
>
>> Right now when I attempt to mount it, I am asked for root password.
>> Not acceptable.
>
> So your actual question is how to *mount* the partition?  In the fstab
> file, include the "user" option to allow non-root users to mount the
> partition.  Better still, just make the partition mount automatically
> at boot time (defaults).
>
> Is there a particular reason you wanted the partition NOT to be mounted
> by default, and to require the logged-in user to enter a command?
>
>

I have just re-read this entire thread and have my thought 
process joggled by some apparently unrelated posts.

I'll attempt to refine my problem definition.
My primary use case is a laptop:
   1. purchased explicitly for use as a test bed.
   2. whose HD has been erased multiple times in ONE day.
   3. is isolated from ANY network.
   4. has multiple installs of Debian, primarily classed as:
      a. a full GUI install - what one would get choosing all 
installer defaults.
      b. a GUI install limited to the tools I use routinely.
      c. an install oriented to whatever my current experiment needs.
   5. has 2 classes of "DATA Partitions":
      a. those which UID 1000 may mount without entering any 
password.
      b. those which *ANY* user may mount only by using root 
password.
The second use case is an existing machine with WinXP which is 
why I do not wish these "DATA Partitions" to be Windows readable.

My original question had (apparently incorrectly assume that 
partitions handled user/group/world permissions in the same 
manner as file systems.

I gather that I can approximately solve the problem with 
appropriate entries in /etc/fstab (pointer to good tutorial 
please). That approach has short comings:
    1. requires custom editing of /etc/fstab for each install.
    2. requires custom editing of /etc/fstab for each install
       whenever a partition is added.

Clearer than mud? ;/
TIA

[toc] | [prev] | [next] | [standalone]

#173948

On Fri, Oct 28, 2016 at 10:28:54AM -0500, Richard Owlett wrote:
> I'll attempt to refine my problem definition.
> My primary use case is a laptop:
>   1. purchased explicitly for use as a test bed.
>   2. whose HD has been erased multiple times in ONE day.
>   3. is isolated from ANY network.
>   4. has multiple installs of Debian, primarily classed as:
>      a. a full GUI install - what one would get choosing all 
> installer defaults.
>      b. a GUI install limited to the tools I use routinely.
>      c. an install oriented to whatever my current experiment needs.
>   5. has 2 classes of "DATA Partitions":
>      a. those which UID 1000 may mount without entering any 
> password.
>      b. those which *ANY* user may mount only by using root 
> password.
> The second use case is an existing machine with WinXP which is 
> why I do not wish these "DATA Partitions" to be Windows readable.

Simply creating a Linux file system (ext3 or whatever) on the partition
should be enough to prevent Windows from mounting it (or "mapping" it,
or whatever Windows calls the act of opening up a file system for
use by applications).

> My original question had (apparently incorrectly assume that 
> partitions handled user/group/world permissions in the same 
> manner as file systems.

If you want to write files on this partition, it has to be formatted
with some kind of file system, and then mounted.  If the file system
is a unix-like one, then it will have unix file metadata like ownership,
group ownership and permissions.

> I gather that I can approximately solve the problem with 
> appropriate entries in /etc/fstab (pointer to good tutorial 
> please). That approach has short comings:

man fstab

Consider using file system labels so that you don't have to put cryptic
UUIDs into the fstab, or potentially volatile device names.

man e2label

>    1. requires custom editing of /etc/fstab for each install.
>    2. requires custom editing of /etc/fstab for each install
>       whenever a partition is added.

There is absolutely no way you're going to be able to mount a file system
as an ordinary user (UID 1000 or whatever) without putting a line in the
/etc/fstab file.  So then the goal becomes to make this process as easy
and foolproof as possible for yourself, or for whoever's doing these
hourly wipes and reinstalls.  I'd recommend e2label for this.

I don't know why you need users to be able to mount the file system via
commands, instead of just having them automatically mounted at boot time.
/etc/fstab would also be used for the latter.  That's how most file systems
work (/, /usr, /var, /home, etc.).

[toc] | [prev] | [next] | [standalone]

#173954

Did you take a look at the package pmount?
I use it to mount external disks.
It requires no changes to /etc/fstab.

Regards,
jvp.

[toc] | [prev] | [next] | [standalone]

#173956 — EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Be aware sir that you are the cause of:
    multiple renditions of the "Alleluia Chorus" [courtesy 
Handle] at > 10^^Bels
    an "innocent"[snicker] senior citizen is about to have many 
sleepless nights
    multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !!!!!

On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> Did you take a look at the package pmount?
> I use it to mount external disks.
> It requires no changes to /etc/fstab.

Just in case you have not perceived this quiet discrete message:
   I have not come across pmount before
   The links I've found so far suggest the original author(s) 
were thinking of *ME*!

In case you haven't got "the drift",
*THANK YOU*
I currently suspect this will be the key to resolving MULTIPLE 
purportedly  unrelated conundrums :> *YMMV*

[toc] | [prev] | [next] | [standalone]

#173957 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Multipart message — attachments visible in raw view] — view raw

Better than what Archimedes did (yes, I know I'm top posting).

--------------------------|
John L. Ries              |
Salford Systems           |
Phone: (619)543-8880 x107 |
or     (435)867-8885      |
--------------------------|


On Fri, 28 Oct 2016, Richard Owlett wrote:

> Be aware sir that you are the cause of:
>    multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> 10^^Bels
>    an "innocent"[snicker] senior citizen is about to have many sleepless
> nights
>    multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !!!!!
>
> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> > Did you take a look at the package pmount?
> > I use it to mount external disks.
> > It requires no changes to /etc/fstab.
>
> Just in case you have not perceived this quiet discrete message:
>   I have not come across pmount before
>   The links I've found so far suggest the original author(s) were thinking of
> *ME*!
>
> In case you haven't got "the drift",
> *THANK YOU*
> I currently suspect this will be the key to resolving MULTIPLE purportedly
> unrelated conundrums :> *YMMV*
>
>
>

[toc] | [prev] | [next] | [standalone]

#173960 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:

> Be aware sir that you are the cause of:
>    multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> 10^^Bels
>    an "innocent"[snicker] senior citizen is about to have many sleepless
> nights
>    multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !!!!!
> 
> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> >Did you take a look at the package pmount?
> >I use it to mount external disks.
> >It requires no changes to /etc/fstab.
> 
> Just in case you have not perceived this quiet discrete message:
>   I have not come across pmount before

Yes you have. It is on the wiki page

 https://wiki.debian.org/Installation+Archive+USBStick

You read this page about a week or so ago (you told us so) but seemed
more concerned about its style rather than its substance.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#173962 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On 10/28/2016 5:17 PM, Brian wrote:
> On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:
>
>> Be aware sir that you are the cause of:
>>     multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
>> 10^^Bels
>>     an "innocent"[snicker] senior citizen is about to have many sleepless
>> nights
>>     multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !!!!!
>>
>> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
>>> Did you take a look at the package pmount?
>>> I use it to mount external disks.
>>> It requires no changes to /etc/fstab.
>>
>> Just in case you have not perceived this quiet discrete message:
>>    I have not come across pmount before
>
> Yes you have. It is on the wiki page
>
>   https://wiki.debian.org/Installation+Archive+USBStick
>
> You read this page about a week or so ago (you told us so) but seemed
> more concerned about its style rather than its substance.
>

*BULL*
Said page may have included the string "pmount".

But it gave no useful info!!!!!!!!!!!!!!!!!!!!!

[toc] | [prev] | [next] | [standalone]

#173965 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

	Hi.

On Fri, 28 Oct 2016 18:34:10 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

> On 10/28/2016 5:17 PM, Brian wrote:
> > On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:
> >
> >> Be aware sir that you are the cause of:
> >>     multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> >> 10^^Bels
> >>     an "innocent"[snicker] senior citizen is about to have many sleepless
> >> nights
> >>     multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !!!!!
> >>
> >> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> >>> Did you take a look at the package pmount?
> >>> I use it to mount external disks.
> >>> It requires no changes to /etc/fstab.
> >>
> >> Just in case you have not perceived this quiet discrete message:
> >>    I have not come across pmount before
> >
> > Yes you have. It is on the wiki page
> >
> >   https://wiki.debian.org/Installation+Archive+USBStick
> >
> > You read this page about a week or so ago (you told us so) but seemed
> > more concerned about its style rather than its substance.
> >
> 
> *BULL*
> Said page may have included the string "pmount".
> 
> But it gave no useful info!!!!!!!!!!!!!!!!!!!!!

I dunno ;). Quoting the page, this:

Installing GRUB on the USB Stick
Install pmount, udevil or udisks2 and use one of the following commands
to mount the primary partition. The mount point for pmount
is /media/ARCHIVE. ...

pmount /dev/disk/by-label/ARCHIVE ARCHIVE

seems like a useful info to me about mounting certain USB stick to a
directory with pmount.

Reco

[toc] | [prev] | [next] | [standalone]

#173971 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Saturday, October 29, 2016 05:17:30 AM Reco wrote:
> On Fri, 28 Oct 2016 18:34:10 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:

> > But it gave no useful info!!!!!!!!!!!!!!!!!!!!!
> 
> I dunno ;). Quoting the page, this:
> 
> Installing GRUB on the USB Stick
> Install pmount, udevil or udisks2 and use one of the following commands
> to mount the primary partition. The mount point for pmount
> is /media/ARCHIVE. ...
> 
> pmount /dev/disk/by-label/ARCHIVE ARCHIVE
> 
> seems like a useful info to me about mounting certain USB stick to a
> directory with pmount.

I'm not the OP or anybody that has participated in this thread so far.

I don't know whether I want to comment or not.

I'll say that the wiki page gave no hint as to which of the three options to 
install, or any hint that one might work better than another.  Of course, 
until this issue came up, no one may have expected one to work better than 
another, so then someone reading that page could, quite appropriately, try one 
and not the others, and assume that there was no more useful information on 
the page.

Someone with a more experimental nature might have tried all three, but, like 
I hope I implied, why would anyone expect that to make a difference?

I guess maybe I'm doing the same thing some others seem to do--belaboring a 
point that maybe shouldn't have even come up as issue.

If someone read the page and didn't find / recognize a key piece of information 
on that page, maybe the page could use a revision.

If it was because no one previously recognized something (like that pmount, 
udevil or udisks2 might each behave slightly different, and that, therefore, 
one might work when another might not), that would seem like another reason to 
consider a revision of the page.

To argue about the subject just makes the list seem unfriendly, to newbies as 
well as "oldbies". ;-)

[toc] | [prev] | [next] | [standalone]

#173972 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

	Hi.

On Sat, 29 Oct 2016 08:16:18 -0400
rhkramer@gmail.com wrote:

> On Saturday, October 29, 2016 05:17:30 AM Reco wrote:
> > On Fri, 28 Oct 2016 18:34:10 -0500
> > Richard Owlett <rowlett@cloud85.net> wrote:
> 
> > > But it gave no useful info!!!!!!!!!!!!!!!!!!!!!
> > 
> > I dunno ;). Quoting the page, this:
> > 
> > Installing GRUB on the USB Stick
> > Install pmount, udevil or udisks2 and use one of the following commands
> > to mount the primary partition. The mount point for pmount
> > is /media/ARCHIVE. ...
> > 
> > pmount /dev/disk/by-label/ARCHIVE ARCHIVE
> > 
> > seems like a useful info to me about mounting certain USB stick to a
> > directory with pmount.
> 
> I'm not the OP or anybody that has participated in this thread so far.

[1] tells me otherwise, for the 'participation' part. I take it that
this e-mail I'm replying to is shared among several people, then?


> I'll say that the wiki page gave no hint as to which of the three options to 
> install, or any hint that one might work better than another.

The page is describing 'Producing an automated install of a Debian
operating system from a USB stick', to quote it. For such an advanced
task it can be safely assumed IMO that the person who's implementing the
instruction is familiar with the basic concepts of a 'file system' or
'mounting'.

It can be argued (again IMO) that the 3 tools proposed are not the best
ones available for the task, or downright redundant due to availability
of mount(8), but all three mentioned tools are in fact are links to [2].
Broken ones (for me at least), but they are links to manpages for the
mentioned tools. Surely a manpage can be viewed as a suitable source of
hints you're referring to.


>  Of course, 
> until this issue came up, no one may have expected one to work better than 
> another, so then someone reading that page could, quite appropriately, try one 
> and not the others, and assume that there was no more useful information on 
> the page.

I agree that the page provides unnecessary choice in this regard, and
for the sake of clarity of this topic [3] would be more appropriate.


> Someone with a more experimental nature might have tried all three, but, like 
> I hope I implied, why would anyone expect that to make a difference?

Different tools. Different programming languages to implement
them. Different dependencies for said tools. Surely all of them should
behave exact the same behavior (sarcasm implied).


> I guess maybe I'm doing the same thing some others seem to do--belaboring a 
> point that maybe shouldn't have even come up as issue.
> 
> If someone read the page and didn't find / recognize a key piece of information 
> on that page, maybe the page could use a revision.

I believe you're missing the point here. The page in question is not
supposed to provide information on mounting anything as a *key piece*
in the first place due to very nature of the topic the page describes.

But since such information is in there for some reason, and it's
covering *both* mounting and unmounting in a compact enough form - it
can be used as an example for mounting and unmounting also.


Reco

[1]
https://lists.debian.org/msgid-search/201610260711.18646.rhkramer@gmail.com

[2] http://manpages.debian.org/

[3] https://wiki.debian.org/pmount

[toc] | [prev] | [next] | [standalone]

#173980 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:

> On Sat, 29 Oct 2016 08:16:18 -0400
> rhkramer@gmail.com wrote:
> 
> > I'll say that the wiki page gave no hint as to which of the three options to 
> > install, or any hint that one might work better than another.
> 
> The page is describing 'Producing an automated install of a Debian
> operating system from a USB stick', to quote it. For such an advanced
> task it can be safely assumed IMO that the person who's implementing the
> instruction is familiar with the basic concepts of a 'file system' or
> 'mounting'.

The question of providing guidance on which of the three tools to use is
an interesting one. As far as possible a wiki page like this one should
stick to facts and technical matters; venturing into the area of opinion
isn't the way to go, IMO. Do any of these tools have a distinct
technical advantage for the purpose of installing GRUB is the question
to ask and answer? If the answer is "no" don't they deserve equal
exposure?

The tools exist and all can be assumed to work.  The choice of which one
to use is up to the user. For many users a couple of clicks on a desktop
will get the stick mounted; others might like the challenge of using a
new tool. A few might say - "Hey, interesting, never knew about that;
I'll give it a go". And then go on to use it in another context.

> It can be argued (again IMO) that the 3 tools proposed are not the best
> ones available for the task, or downright redundant due to availability
> of mount(8), but all three mentioned tools are in fact are links to [2].
> Broken ones (for me at least), but they are links to manpages for the
> mentioned tools. Surely a manpage can be viewed as a suitable source of
> hints you're referring to.

mount is a root-only tool; the others aren't. Need I say more?

The Debian manpages site is broken and awaiting relocation to a new
host.

> >  Of course, 
> > until this issue came up, no one may have expected one to work better than 
> > another, so then someone reading that page could, quite appropriately, try one 
> > and not the others, and assume that there was no more useful information on 
> > the page.
> 
> I agree that the page provides unnecessary choice in this regard, and
> for the sake of clarity of this topic [3] would be more appropriate.

Fair enough. But why not udisks2? After all, it will already be on many
machines.

> > Someone with a more experimental nature might have tried all three, but, like 
> > I hope I implied, why would anyone expect that to make a difference?
> 
> Different tools. Different programming languages to implement
> them. Different dependencies for said tools. Surely all of them should
> behave exact the same behavior (sarcasm implied).

Sarcasm noted :).

By its very nature a wiki page has prescriptive aspects to it but that
does not need to be extended to everything on it. Where there is more
than one way to do something there can surely be a case for mentioning
all of them. If choice confuses there is no answer to that apart from a
user tossing a coin.

When it comes to making an archive there would be at least one -user
member who would be profoundly put out if xorriso was not one of the
choices for the task. :)

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#173986 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

	Hi.

On Sat, 29 Oct 2016 15:09:09 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> 
> > On Sat, 29 Oct 2016 08:16:18 -0400
> > rhkramer@gmail.com wrote:
> > 
> > > I'll say that the wiki page gave no hint as to which of the three options to 
> > > install, or any hint that one might work better than another.
> > 
> > The page is describing 'Producing an automated install of a Debian
> > operating system from a USB stick', to quote it. For such an advanced
> > task it can be safely assumed IMO that the person who's implementing the
> > instruction is familiar with the basic concepts of a 'file system' or
> > 'mounting'.
> 
> The question of providing guidance on which of the three tools to use is
> an interesting one. As far as possible a wiki page like this one should
> stick to facts and technical matters; venturing into the area of opinion
> isn't the way to go, IMO. Do any of these tools have a distinct
> technical advantage for the purpose of installing GRUB is the question
> to ask and answer? If the answer is "no" don't they deserve equal
> exposure?

No advantage that I'm aware of. In fact, the whole paragraph could be
shortened to already existing text:

If you are working within one of the desktop environments it is very
likely the mounting can be done from he file manager which comes with
it. This is because udisks2 will be on the system. A label will
possibly be used for the mount point.



> The tools exist and all can be assumed to work.  The choice of which one
> to use is up to the user. For many users a couple of clicks on a desktop
> will get the stick mounted; others might like the challenge of using a
> new tool. 

My point exactly. Why bother naming all these tools if it all comes down
to "you might use your file manager to do this part for you as well"?


> A few might say - "Hey, interesting, never knew about that;
> I'll give it a go". And then go on to use it in another context.

True, but why stop here? Author(s?) of the page might mention usbmount
and supermount as well.


> > It can be argued (again IMO) that the 3 tools proposed are not the best
> > ones available for the task, or downright redundant due to availability
> > of mount(8), but all three mentioned tools are in fact are links to [2].
> > Broken ones (for me at least), but they are links to manpages for the
> > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > hints you're referring to.
> 
> mount is a root-only tool; the others aren't. Need I say more?

Yes, I believe you do.

The page mentions 'Check the mount point from within the fie manager or
with the command "mount"' (curious typo btw), rightfully assuming that
one does not need to be root to do that.

The bottom of the page mentions at least one operation that needs to be
performed as root, so why exactly mounting USB stick as root is somehow
a bad thing in this context?


> The Debian manpages site is broken and awaiting relocation to a new
> host.

Here I can only assume that this useful service was available at the
time that page was written.


> > >  Of course, 
> > > until this issue came up, no one may have expected one to work better than 
> > > another, so then someone reading that page could, quite appropriately, try one 
> > > and not the others, and assume that there was no more useful information on 
> > > the page.
> > 
> > I agree that the page provides unnecessary choice in this regard, and
> > for the sake of clarity of this topic [3] would be more appropriate.
> 
> Fair enough. But why not udisks2? After all, it will already be on many
> machines.

No reason, really. pmount was mentioned first on the page.


Reco

[toc] | [prev] | [next] | [standalone]

#173994 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote:

> On Sat, 29 Oct 2016 15:09:09 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> > 
> > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > rhkramer@gmail.com wrote:
> > > 
> > > > I'll say that the wiki page gave no hint as to which of the three options to 
> > > > install, or any hint that one might work better than another.
> > > 
> > > The page is describing 'Producing an automated install of a Debian
> > > operating system from a USB stick', to quote it. For such an advanced
> > > task it can be safely assumed IMO that the person who's implementing the
> > > instruction is familiar with the basic concepts of a 'file system' or
> > > 'mounting'.
> > 
> > The question of providing guidance on which of the three tools to use is
> > an interesting one. As far as possible a wiki page like this one should
> > stick to facts and technical matters; venturing into the area of opinion
> > isn't the way to go, IMO. Do any of these tools have a distinct
> > technical advantage for the purpose of installing GRUB is the question
> > to ask and answer? If the answer is "no" don't they deserve equal
> > exposure?
> 
> No advantage that I'm aware of. In fact, the whole paragraph could be
> shortened to already existing text:
> 
> If you are working within one of the desktop environments it is very
> likely the mounting can be done from he file manager which comes with
> it. This is because udisks2 will be on the system. A label will
> possibly be used for the mount point.

I wish you had addressed the "equal exposure" question. Desktops are not
the only environments in town. Leaving non-policykit users out in the
cold is not an option.
 
> > The tools exist and all can be assumed to work.  The choice of which one
> > to use is up to the user. For many users a couple of clicks on a desktop
> > will get the stick mounted; others might like the challenge of using a
> > new tool. 
> 
> My point exactly. Why bother naming all these tools if it all comes down
> to "you might use your file manager to do this part for you as well"?

It doesn't come down to that; using a desktop filemanager is just one of
the alternatives. One could equally well ask why it is has to mentioned
when there is

 > Install pmount, udevil or udisks2 and use one ..... 

Providing a range of advice for a range of people isn't exactly easy in
all situations. Advice on installing a wifi kernel module is easy -
there is only one for each chipset. A page on pmount is a little harder
because it is a moving target. (The link you gave has out-of-date info
on HAL). Anything more complex can always be criticised as time moves
on.

But your sort of constructive criticism is valuable.

> > A few might say - "Hey, interesting, never knew about that;
> > I'll give it a go". And then go on to use it in another context.
> 
> True, but why stop here? Author(s?) of the page might mention usbmount
> and supermount as well.

You are getting carried away here. Both are for *automatically* mounting
and unmounting removable media, which is not a focus for the task.

There is no sign of supermount in stable or unstable.
 
> > > It can be argued (again IMO) that the 3 tools proposed are not the best
> > > ones available for the task, or downright redundant due to availability
> > > of mount(8), but all three mentioned tools are in fact are links to [2].
> > > Broken ones (for me at least), but they are links to manpages for the
> > > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > > hints you're referring to.
> > 
> > mount is a root-only tool; the others aren't. Need I say more?
> 
> Yes, I believe you do.

As little as possible should be done as root is a good principle.

> The page mentions 'Check the mount point from within the fie manager or
> with the command "mount"' (curious typo btw), rightfully assuming that
> one does not need to be root to do that.

C'mon; pointing out a typo! This is unworthy of you, even as an aside.
 
> The bottom of the page mentions at least one operation that needs to be
> performed as root, so why exactly mounting USB stick as root is somehow
> a bad thing in this context?

Excellent point. This will lead to a rewriting.

The problem at the time was that Wheezy and Jessie behaved differently.
It is mentioned (bug #751892) that root may be necessary. Now Wheezy is
unsupported references to it can go. 

> > The Debian manpages site is broken and awaiting relocation to a new
> > host.
> 
> Here I can only assume that this useful service was available at the
> time that page was written.

Good thinking, Batman. :)
 
> > > >  Of course, 
> > > > until this issue came up, no one may have expected one to work better than 
> > > > another, so then someone reading that page could, quite appropriately, try one 
> > > > and not the others, and assume that there was no more useful information on 
> > > > the page.
> > > 
> > > I agree that the page provides unnecessary choice in this regard, and
> > > for the sake of clarity of this topic [3] would be more appropriate.
> > 
> > Fair enough. But why not udisks2? After all, it will already be on many
> > machines.
> 
> No reason, really. pmount was mentioned first on the page.

Mounting and unmounting are not really a problem. Users and root can
easily do these. But, as far as I can see, only someone with root
privileges can use dd, cfdisk, fdisk and mkfs.vfat with a removable
device. I'd like to be wrong.

--  
Brian.

[toc] | [prev] | [next] | [standalone]

#174004 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

	Hi.

On Sat, 29 Oct 2016 19:15:53 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote:
> 
> > On Sat, 29 Oct 2016 15:09:09 +0100
> > Brian <ad44@cityscape.co.uk> wrote:
> > 
> > > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> > > 
> > > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > > rhkramer@gmail.com wrote:
> > > > 
> > > > > I'll say that the wiki page gave no hint as to which of the three options to 
> > > > > install, or any hint that one might work better than another.
> > > > 
> > > > The page is describing 'Producing an automated install of a Debian
> > > > operating system from a USB stick', to quote it. For such an advanced
> > > > task it can be safely assumed IMO that the person who's implementing the
> > > > instruction is familiar with the basic concepts of a 'file system' or
> > > > 'mounting'.
> > > 
> > > The question of providing guidance on which of the three tools to use is
> > > an interesting one. As far as possible a wiki page like this one should
> > > stick to facts and technical matters; venturing into the area of opinion
> > > isn't the way to go, IMO. Do any of these tools have a distinct
> > > technical advantage for the purpose of installing GRUB is the question
> > > to ask and answer? If the answer is "no" don't they deserve equal
> > > exposure?
> > 
> > No advantage that I'm aware of. In fact, the whole paragraph could be
> > shortened to already existing text:
> > 
> > If you are working within one of the desktop environments it is very
> > likely the mounting can be done from he file manager which comes with
> > it. This is because udisks2 will be on the system. A label will
> > possibly be used for the mount point.
> 
> I wish you had addressed the "equal exposure" question. Desktops are not
> the only environments in town. Leaving non-policykit users out in the
> cold is not an option.

True, that does not look good at all. But why bother listing udisks2
which is using PolicyKit then?

Besides, in modern Debian it takes a certain amount of skill and
determination *not* to use PolicyKit ;)


> > > The tools exist and all can be assumed to work.  The choice of which one
> > > to use is up to the user. For many users a couple of clicks on a desktop
> > > will get the stick mounted; others might like the challenge of using a
> > > new tool. 
> > 
> > My point exactly. Why bother naming all these tools if it all comes down
> > to "you might use your file manager to do this part for you as well"?
> 
> It doesn't come down to that; using a desktop filemanager is just one of
> the alternatives. One could equally well ask why it is has to mentioned
> when there is
> 
>  > Install pmount, udevil or udisks2 and use one ..... 

Indeed. All this confusion could be avoided by simple 'please mount the
USB stick to this mountpoint'. Again, the page describes rather
advanced topic.


> Providing a range of advice for a range of people isn't exactly easy in
> all situations. Advice on installing a wifi kernel module is easy -
> there is only one for each chipset.

I honestly wish that this was true. Sadly, there's Broadcom, see [1]
for the gory details.


> A page on pmount is a little harder because it is a moving target.

I honestly lost you here. oldstable, stable, testing and even sid have
the same upstream version of pmount - 0.9.23, dated 2010.


> (The link you gave has out-of-date info on HAL). Anything more 
> complex can always be criticised as time moves on.

The page itself is somewhat outdated, true. Someone should cleanup that
obsolete hal reference.


> But your sort of constructive criticism is valuable.

You're welcome, I guess.


> > > A few might say - "Hey, interesting, never knew about that;
> > > I'll give it a go". And then go on to use it in another context.
> > 
> > True, but why stop here? Author(s?) of the page might mention usbmount
> > and supermount as well.
> 
> You are getting carried away here. Both are for *automatically* mounting
> and unmounting removable media, which is not a focus for the task.
> 
> There is no sign of supermount in stable or unstable.

True. That's something that I missed.


> > > > It can be argued (again IMO) that the 3 tools proposed are not the best
> > > > ones available for the task, or downright redundant due to availability
> > > > of mount(8), but all three mentioned tools are in fact are links to [2].
> > > > Broken ones (for me at least), but they are links to manpages for the
> > > > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > > > hints you're referring to.
> > > 
> > > mount is a root-only tool; the others aren't. Need I say more?
> > 
> > Yes, I believe you do.
> 
> As little as possible should be done as root is a good principle.

mount(2) system call is a privileged one regardless of the tool used.
Hence a root intervention in one form or the other is needed.

Whenever such privilege escalation is done by trusted daemon (udisks2),
or by hand (su, sudo) for the purposes of mounting and unmounting is not
relevant. Assuming, for the sake of simplicity, that all implementations
of privilege escalation (su, sudo, policykit, trusted suid binaries
such as pmount) are free of security bugs.

If it was desirable to exclude root intervention whenever possible in
this task - the page in question would suggest fusefat instead.


> > The page mentions 'Check the mount point from within the fie manager or
> > with the command "mount"' (curious typo btw), rightfully assuming that
> > one does not need to be root to do that.
> 
> C'mon; pointing out a typo! This is unworthy of you, even as an aside.

Disregard the typo comment then as it was not pointed to the article
quality. Not all mount(8) invokations require root, that was the point.


> > > > >  Of course, 
> > > > > until this issue came up, no one may have expected one to work better than 
> > > > > another, so then someone reading that page could, quite appropriately, try one 
> > > > > and not the others, and assume that there was no more useful information on 
> > > > > the page.
> > > > 
> > > > I agree that the page provides unnecessary choice in this regard, and
> > > > for the sake of clarity of this topic [3] would be more appropriate.
> > > 
> > > Fair enough. But why not udisks2? After all, it will already be on many
> > > machines.
> > 
> > No reason, really. pmount was mentioned first on the page.
> 
> Mounting and unmounting are not really a problem. Users and root can
> easily do these. But, as far as I can see, only someone with root
> privileges can use dd, cfdisk, fdisk and mkfs.vfat with a removable
> device. I'd like to be wrong.

This is a common myth that I'll debunk gladly.

Image copying (dd or any other tool) merely requires ability to write
to a block device. Such permissions on removable media should be
provided to any current console user by logind (or ConsoleKit if we
still need to think about wheezy), or a good old-fashioned
'floppy' (any group name will do) group and a custom udev rule (as of
jessie).

Creating any filesystem on a removable media's partition merely requires
the same.

Changing a partition table (as in 'bytes on media') require an ability
to both read and write from/to block device. Ditto.

Changing what current kernel thinks of the partition table (as in
'kernel state') is privileged indeed, but it can be worked around
by a simple yanking/putting back. Failing that there's always a
possibility to reboot a host (a dirty trick, I know ;).

Reco

[toc] | [prev] | [next] | [standalone]

#174011 — Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 23:23:52 +0300, Reco wrote:

> On Sat, 29 Oct 2016 19:15:53 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> > I wish you had addressed the "equal exposure" question. Desktops are not
> > the only environments in town. Leaving non-policykit users out in the
> > cold is not an option.
> 
> True, that does not look good at all. But why bother listing udisks2
> which is using PolicyKit then?

In the light of previous points I think there is a non-sequiteur in
there somwhere.
 
> Besides, in modern Debian it takes a certain amount of skill and
> determination *not* to use PolicyKit ;)

Maybe. Nothing to do with whether policykit is on a machine or not, of
course.

> > It doesn't come down to that; using a desktop filemanager is just one of
> > the alternatives. One could equally well ask why it is has to mentioned
> > when there is
> > 
> >  > Install pmount, udevil or udisks2 and use one ..... 
> 
> Indeed. All this confusion could be avoided by simple 'please mount the
> USB stick to this mountpoint'. Again, the page describes rather
> advanced topic.

As said, a rewrite is in the offing. The reality is that all operations
should be with root privileges.
 
> > Providing a range of advice for a range of people isn't exactly easy in
> > all situations. Advice on installing a wifi kernel module is easy -
> > there is only one for each chipset.
> 
> I honestly wish that this was true. Sadly, there's Broadcom, see [1]
> for the gory details.

There are always exceptions.

> > A page on pmount is a little harder because it is a moving target.
> 
> I honestly lost you here. oldstable, stable, testing and even sid have
> the same upstream version of pmount - 0.9.23, dated 2010.

They do indeed. Six years. Do you get the feeling it is getting on for
unmaintained. (And a wiki page with HAL on it! I ask you). But software
changes. Then wiki pages change. 

> > (The link you gave has out-of-date info on HAL). Anything more 
> > complex can always be criticised as time moves on.
> 
> The page itself is somewhat outdated, true. Someone should cleanup that
> obsolete hal reference.

Don't look at me.

> > But your sort of constructive criticism is valuable.
> 
> You're welcome, I guess.
> 
> > You are getting carried away here. Both are for *automatically* mounting
> > and unmounting removable media, which is not a focus for the task.
> > 
> > There is no sign of supermount in stable or unstable.
> 
> True. That's something that I missed.

We all miss something.

> > As little as possible should be done as root is a good principle.
> 
> mount(2) system call is a privileged one regardless of the tool used.
> Hence a root intervention in one form or the other is needed.
> 
> Whenever such privilege escalation is done by trusted daemon (udisks2),
> or by hand (su, sudo) for the purposes of mounting and unmounting is not
> relevant. Assuming, for the sake of simplicity, that all implementations
> of privilege escalation (su, sudo, policykit, trusted suid binaries
> such as pmount) are free of security bugs.
> 
> If it was desirable to exclude root intervention whenever possible in
> this task - the page in question would suggest fusefat instead.

Something to consider and test. Thanks.
 
> > C'mon; pointing out a typo! This is unworthy of you, even as an aside.
> 
> Disregard the typo comment then as it was not pointed to the article
> quality. Not all mount(8) invokations require root, that was the point.
> 
> > Mounting and unmounting are not really a problem. Users and root can
> > easily do these. But, as far as I can see, only someone with root
> > privileges can use dd, cfdisk, fdisk and mkfs.vfat with a removable
> > device. I'd like to be wrong.
> 
> This is a common myth that I'll debunk gladly.
> 
> Image copying (dd or any other tool) merely requires ability to write
> to a block device. Such permissions on removable media should be
> provided to any current console user by logind (or ConsoleKit if we
> still need to think about wheezy), or a good old-fashioned
> 'floppy' (any group name will do) group and a custom udev rule (as of
> jessie).
> 
> Creating any filesystem on a removable media's partition merely requires
> the same.

Since you wrote this, hundreds of people using GNOME have popped a USB
stick into their machines and typed

  dd if=/dev/zero of=/dev/<somewhere>

Those who didn't get

  dd: failed to open 'dev/<somewhere>'

will be along soon to report success and explain why.

The floppy group + a udev rule is a Wheezy thing. Not suitable for a
wiki relating to a current Debian.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web