Re: Removing user list from login screen.

[Michael Schwendt]

On Fri, 27 Aug 2010 15:42:29 -0500, Aaron wrote:

> On Fri, 2010-08-27 at 19:56 +0200, Michael Schwendt wrote:
> > On Fri, 27 Aug 2010 12:46:10 -0500, Aaron wrote:
> > 
> > > How can you rmove the list of users that can login from login screen?
> > > 
> > > .gconf/apps/gdm/simplegreeter/disable_user_list=true
> >   ^^^
> > What is this?
> It is a directory present in your home directory that can be manipulated
> using gconf-editor program. gconf-editor is File->System
> Tools->Configuration Editor I will admit it is simple-greeter not
> simplegreeter.
> > 
> > > does not work neither do the other simple_greeter options.
> > 
> > What is the exact command you used to set the disable_user_list Boolean?
> You execute gconf-editor and go to simple-greeter
> 
> You run gconf-editor (or Configuration editor which allows you to
> manipulate the parameters in the simple-editor (really and XML file)
> Or you can go down the directory tree above and edit the XML file
> directly.

Okay, I assumed you had fiddled with the files in .gconf directly somehow
getting it wrong, because you didn't mention gconf-editor or gconftool. ;)

With the warning posted elsewhere in this thread that changing the setting
exposes a fatal bug (bz 590456), this is one quick way to set the flag:

gconftool-2 --direct --config-source 
xml:readwrite:/etc/gconf/gconf.xml.mandatory 
/apps/gdm/simple-greeter/disable_user_list --set --type bool true
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: How to debug resume (suspend) problems?

[Felix Schwarz]

Am 27.08.2010 22:09, schrieb Konstantin Svist:
> Check if numlock+capslock are flashing -- if they are, kernel crashed
>
> Check if you can switch to a virtual terminal with Ctrl+Alt+F2..F6

No, I tried that before (sorry, did not mention that)

> edit /etc/sysctl.conf and set sysreq = 1. After that, when you get a
> freeze, try using REISUB (http://en.wikipedia.org/wiki/Reisub) to reboot

I enabled the magic sysrq and verified that I can use it when the system 
is up and running. When provoked a resume failure, the system did not 
react to any of the sysrq combinations.

So it looks to me like the system is just completely dead. Any ideas how 
I can gather more information? Suspend/resume worked well in Fedora 12 
and in the beginnings of Fedora 13 so I really want to have that feature 
back!

fs
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: does Fedora need Google search logic?

[Valent Turkovic]

Richard said he contacted few people from infrastructure, but I agree
there should be a public discussion about this.

Valent.

On Fri, Jul 30, 2010 at 5:26 AM, Rahul Sundaram  wrote:
>  On 07/29/2010 03:49 PM, Valent Turkovic wrote:
>>> Have you asked in the infrastructure list?
>>>
>>> Rahul
>> Rahul check out comment on bugzilla:
>> https://bugzilla.redhat.com/show_bug.cgi?id=618829#c5
>>
>> Looks like he is in contact with them.
>
> I haven't seen any public discussions in the infrastructure list.
>
> Rahul
> --
> users mailing list
> users@lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>



-- 
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: How to debug resume (suspend) problems?

[JB]

Felix Schwarz  oss.schwarz.eu> writes:

> ...
> Suspend/resume worked well in Fedora 12 
> and in the beginnings of Fedora 13 so I really want to have that feature 
> back!
Hi,
There have been a couple of threads for the last few days dedicated to kernel,
grub, hibernation problems.
In addition, the last kernel update to 2.6.33.8-149.fc13 screwed hibernation and
suspension.
I went back to previous kernel to have both back, even if hibernation's system
restore (grub menu handling) behaves randomly.
Otherwise, document it and submit a bugzilla report.
You may pray as well if you like ... :-)
JB


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: yum repository synchronization time?

[Christoph A.]

On 08/24/2010 07:49 AM, Michael Schwendt wrote:
> When pushed into a repo, it will either be tagged with
> "dist-*-updates-testing" or "dist-*-updates". Candidates are only
> available in koji (and not even in the koji buildroot repos, depending
> on what dist is built for).

This http://koji.fedoraproject.org/koji/buildinfo?buildID=192358
is taged as dist-f13-updates-testing and not yet in a repo:

https://admin.fedoraproject.org/updates/kernel-2.6.34.6-47.fc13

status: pending
pushed: false

so I asume only 'dist-*-updates' are pushed to a repo?


date && repoquery -i kernel
Sat Aug 28 14:35:17 CEST 2010

Name: kernel
Version : 2.6.33.8
Release : 149.fc13
Architecture: x86_64
Size: 108243345
Packager: Fedora Project
Group   : System Environment/Kernel
URL : http://www.kernel.org/
Repository  : updates
Summary : The Linux kernel




signature.asc
Description: OpenPGP digital signature
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Patrick O'Callaghan]

On Fri, 2010-08-27 at 21:53 -0700, JD wrote:
> On 08/27/2010 09:25 PM, JD wrote:
> >  Is there a Linux util to scrub free disk blocks and keep everything 
> > else intact ??
> >
> Someone (not on this list) described a simple way to do this.
> Scrubbing files to be deleted is easy enough - there are utils for it 
> already.
> But scrubbing existing free space is slower and requires patience.
> 
> cd to the root of the partition.
> sudo dd if=/dev/zero of=ZERO bs=20M
> 
> When the dd program fails to write any further, you
> have grabbed and zeroed all available free disk blocks
> in the partition.
> 
> Now all you do is use the command scrub to scrub the file ZERO
> and when done  the file is deleted.

From scrub(1):

-X, --freespace
  Create  specified  directory and fill it with files until write 
returns ENOSPC (file system full),
  then scrub the files as usual.  The size of each file can be set 
with -s, otherwise it will be the
  maximum file size creatable given the user’s file size limit or 
1g if umlimited.

However note that neither of these methods guarantees to scrub indirect
blocks in the filesystem that were used to create the space-filling
files. Maybe they do, maybe they don't, it's not clear.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Removing user list from login screen.

[Robert Nichols]

On 08/27/2010 03:42 PM, Aaron Konstam wrote:
> On Fri, 2010-08-27 at 19:56 +0200, Michael Schwendt wrote:
>> On Fri, 27 Aug 2010 12:46:10 -0500, Aaron wrote:
>>
>>> How can you rmove the list of users that can login from login screen?
>>>
>>> .gconf/apps/gdm/simplegreeter/disable_user_list=true
>>^^^
>> What is this?
> It is a directory present in your home directory that can be manipulated
> using gconf-editor program. gconf-editor is File->System
> Tools->Configuration Editor I will admit it is simple-greeter not
> simplegreeter.

Why would you expect anything under your home directory to be of
significance before you have logged in?

-- 
Bob Nichols "NOSPAM" is really part of my email address.
 Do NOT delete it.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Robert Nichols]

On 08/27/2010 11:53 PM, JD wrote:
>On 08/27/2010 09:25 PM, JD wrote:
>>   Is there a Linux util to scrub free disk blocks and keep everything
>> else intact ??
>>
> Someone (not on this list) described a simple way to do this.
> Scrubbing files to be deleted is easy enough - there are utils for it
> already.
> But scrubbing existing free space is slower and requires patience.
>
> cd to the root of the partition.
> sudo dd if=/dev/zero of=ZERO bs=20M
>
> When the dd program fails to write any further, you
> have grabbed and zeroed all available free disk blocks
> in the partition.
>
> Now all you do is use the command scrub to scrub the file ZERO
> and when done  the file is deleted.

You need to do that as the UID permitted to use the reserved blocks
if you really want to clear _all_ the free space.  Note that if the
drive has reallocated any bad sectors there could still be some old
data present on the disk.

-- 
Bob Nichols "NOSPAM" is really part of my email address.
 Do NOT delete it.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: yum repository synchronization time?

[Michael Schwendt]

On Sat, 28 Aug 2010 14:41:24 +0200, Christoph wrote:

> > When pushed into a repo, it will either be tagged with
> > "dist-*-updates-testing" or "dist-*-updates". Candidates are only
> > available in koji (and not even in the koji buildroot repos, depending
> > on what dist is built for).
> 
> This http://koji.fedoraproject.org/koji/buildinfo?buildID=192358
> is taged as dist-f13-updates-testing and not yet in a repo:
> 
> https://admin.fedoraproject.org/updates/kernel-2.6.34.6-47.fc13
> 
> status: pending
> pushed: false

One cannot see whether it is currently in the process of being pushed
into the repo. The status is not detailed enough. The update ticket
submitter receives the tag notification from koji. Bodhi adds a comment
to the ticket only after the package has been pushed.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Dual boot Fedora 13 and Windows XP ???

[Jesse Palser]

  Dual boot Fedora 13 and Windows XP ???

Hi,

I formatted a 250GB HDD with NTFS and install Windows XP.
I want to now install onto same HDD Fedora 13 and dual boot.

I burned the Fedora 13 ISO to a CD and checked the MD5sum.
I put into computer's CD drive and boot it.
It boots fine into a working desktop.

I click install icon, but do not see an option to dual boot Fedora 13 
and XP.
On Ubuntu install, there is an option to shrink Windows partition to 
dual boot.

I've Googled for hours but do not see a guide to dual boot F13 and XP.
Can someone point me in the right direction?

Thanks

Jesse
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
> On Fri, 2010-08-27 at 21:53 -0700, JD wrote:
>> On 08/27/2010 09:25 PM, JD wrote:
>>>   Is there a Linux util to scrub free disk blocks and keep everything
>>> else intact ??
>>>
>> Someone (not on this list) described a simple way to do this.
>> Scrubbing files to be deleted is easy enough - there are utils for it
>> already.
>> But scrubbing existing free space is slower and requires patience.
>>
>> cd to the root of the partition.
>> sudo dd if=/dev/zero of=ZERO bs=20M
>>
>> When the dd program fails to write any further, you
>> have grabbed and zeroed all available free disk blocks
>> in the partition.
>>
>> Now all you do is use the command scrub to scrub the file ZERO
>> and when done  the file is deleted.
>  From scrub(1):
>
> -X, --freespace
>Create  specified  directory and fill it with files until 
> write returns ENOSPC (file system full),
>then scrub the files as usual.  The size of each file can be 
> set with -s, otherwise it will be the
>maximum file size creatable given the user’s file size limit 
> or 1g if umlimited.
>
> However note that neither of these methods guarantees to scrub indirect
> blocks in the filesystem that were used to create the space-filling
> files. Maybe they do, maybe they don't, it's not clear.
>
> poc
>
Very good.
Actually, indirect blocks are used if and only if the file is larger
than what can be addressed via direct blocks.
So, scrub has no interest in whether or not a file has indirect
blocks, nor should it care if blocks are direct or indirect.
During file access, the file system will access ANY file block(s)
that the process has the right permissions for.


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dual boot Fedora 13 and Windows XP ???

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 10:08 -0400, Jesse Palser wrote:
> Dual boot Fedora 13 and Windows XP ???
> 
> Hi,
> 
> I formatted a 250GB HDD with NTFS and install Windows XP.
> I want to now install onto same HDD Fedora 13 and dual boot.
> 
> I burned the Fedora 13 ISO to a CD and checked the MD5sum.
> I put into computer's CD drive and boot it.
> It boots fine into a working desktop.
> 
> I click install icon, but do not see an option to dual boot Fedora 13 
> and XP.
> On Ubuntu install, there is an option to shrink Windows partition to 
> dual boot.
> 
> I've Googled for hours but do not see a guide to dual boot F13 and XP.
> Can someone point me in the right direction?

You have to partition the disk, leaving at least one partition for each
system. One way is to download a live CD (or USB) copy of gparted, the
GNU Partition Editor. See http://gparted.sourceforge.net/livecd.php

Gparted can resize your existing Windows partition and create a new one
(or more than one) for Linux. It's best to let Windows use the first
partition as that what it seems to expect, so just shrink it in place.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
> On Fri, 2010-08-27 at 21:53 -0700, JD wrote:
>> On 08/27/2010 09:25 PM, JD wrote:
>>>   Is there a Linux util to scrub free disk blocks and keep everything
>>> else intact ??
>>>
>> Someone (not on this list) described a simple way to do this.
>> Scrubbing files to be deleted is easy enough - there are utils for it
>> already.
>> But scrubbing existing free space is slower and requires patience.
>>
>> cd to the root of the partition.
>> sudo dd if=/dev/zero of=ZERO bs=20M
>>
>> When the dd program fails to write any further, you
>> have grabbed and zeroed all available free disk blocks
>> in the partition.
>>
>> Now all you do is use the command scrub to scrub the file ZERO
>> and when done  the file is deleted.
>  From scrub(1):
>
> -X, --freespace
>Create  specified  directory and fill it with files until 
> write returns ENOSPC (file system full),
>then scrub the files as usual.  The size of each file can be 
> set with -s, otherwise it will be the
>maximum file size creatable given the user’s file size limit 
> or 1g if umlimited.
>
> However note that neither of these methods guarantees to scrub indirect
> blocks in the filesystem that were used to create the space-filling
> files. Maybe they do, maybe they don't, it's not clear.
>
> poc
>
What is not clear from the man page is, when using the -X option, whether or
not the directory and the files created in the directory are automatically
deleted before scrub exits. I will assume that they are. Currently scrubbing
189GB free space.


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 06:31 AM, Robert Nichols wrote:
> On 08/27/2010 11:53 PM, JD wrote:
>> On 08/27/2010 09:25 PM, JD wrote:
>>>Is there a Linux util to scrub free disk blocks and keep everything
>>> else intact ??
>>>
>> Someone (not on this list) described a simple way to do this.
>> Scrubbing files to be deleted is easy enough - there are utils for it
>> already.
>> But scrubbing existing free space is slower and requires patience.
>>
>> cd to the root of the partition.
>> sudo dd if=/dev/zero of=ZERO bs=20M
>>
>> When the dd program fails to write any further, you
>> have grabbed and zeroed all available free disk blocks
>> in the partition.
>>
>> Now all you do is use the command scrub to scrub the file ZERO
>> and when done  the file is deleted.
> You need to do that as the UID permitted to use the reserved blocks
> if you really want to clear _all_ the free space.  Note that if the
> drive has reallocated any bad sectors there could still be some old
> data present on the disk.
Guess you might call that caveat emptor.
There is nothing you can do about
relocated bad blocks.

Perhaps there might be a util that can bypass the driver
and send direct commands to the drive via a SATA port, or
and IDE interface or a SCSI port, to write random
data to the  bad blocks - but such a util would
have to be a standalone utility. Perhaps there is a boot
disk out there with such a util.


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Bruno Wolff III]

On Sat, Aug 28, 2010 at 08:36:48 -0700,
  JD  wrote:
> There is nothing you can do about
> relocated bad blocks.

You can use secure erase. That is suppsed to try to do something with those.
You can also use encryption in the first place.
It will be some work to get from where the system is now to a state where
secure erase has been used and stuff is put back on top of an encrypted
block device, but it can be done.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dual boot Fedora 13 and Windows XP ???

[Ankur Sinha]

On Sat, 2010-08-28 at 10:33 -0430, Patrick O'Callaghan wrote:
> You have to partition the disk, leaving at least one partition for
> each
> system. One way is to download a live CD (or USB) copy of gparted, the
> GNU Partition Editor. See http://gparted.sourceforge.net/livecd.php 

Another way:

In XP:
right click on My Computer > Manage > Disk Management > shrink your
drive and leave unallocated space for Fedora.

Once this is done, reboot with your fedora dvd in the drive, choose the
unallocated space as your install location and continue.

-- 
Thanks!
Regards,
Ankur 

https://fedoraproject.org/wiki/User:Ankursinha

"FranciscoD"

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dual boot Fedora 13 and Windows XP ???

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 22:11 +0530, Ankur Sinha wrote:
> On Sat, 2010-08-28 at 10:33 -0430, Patrick O'Callaghan wrote:
> > You have to partition the disk, leaving at least one partition for
> > each
> > system. One way is to download a live CD (or USB) copy of gparted, the
> > GNU Partition Editor. See http://gparted.sourceforge.net/livecd.php 
> 
> Another way:
> 
> In XP:
> right click on My Computer > Manage > Disk Management > shrink your
> drive and leave unallocated space for Fedora.
> 
> Once this is done, reboot with your fedora dvd in the drive, choose the
> unallocated space as your install location and continue.

Yes, that will work as long as a single Linux partition is enough. Some
people like separate partitions for /home, swap etc., though you can get
much the same effect via LVM.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 07:42 -0700, JD wrote:
> > However note that neither of these methods guarantees to scrub
> indirect
> > blocks in the filesystem that were used to create the space-filling
> > files. Maybe they do, maybe they don't, it's not clear.
> >
> > poc
> >
> Very good.
> Actually, indirect blocks are used if and only if the file is larger
> than what can be addressed via direct blocks.
> So, scrub has no interest in whether or not a file has indirect
> blocks, nor should it care if blocks are direct or indirect.
> During file access, the file system will access ANY file block(s)
> that the process has the right permissions for.

So what? My point is that after scrubbing and removal of the
space-filling files, you may be left with a number of sectors that were
used for indirect blocks during the space-filling phase of the scrub
process. These sectors may not themselves be scrubbed but will now be
available on the free list after you're done.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 10:24 AM, Patrick O'Callaghan wrote:
> On Sat, 2010-08-28 at 07:42 -0700, JD wrote:
>>> However note that neither of these methods guarantees to scrub
>> indirect
>>> blocks in the filesystem that were used to create the space-filling
>>> files. Maybe they do, maybe they don't, it's not clear.
>>>
>>> poc
>>>
>> Very good.
>> Actually, indirect blocks are used if and only if the file is larger
>> than what can be addressed via direct blocks.
>> So, scrub has no interest in whether or not a file has indirect
>> blocks, nor should it care if blocks are direct or indirect.
>> During file access, the file system will access ANY file block(s)
>> that the process has the right permissions for.
> So what? My point is that after scrubbing and removal of the
> space-filling files, you may be left with a number of sectors that were
> used for indirect blocks during the space-filling phase of the scrub
> process. These sectors may not themselves be scrubbed but will now be
> available on the free list after you're done.
>
> poc
>
You need to study filesystem architecture to gain better understanding.


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Steven Stern]

On 08/27/2010 11:25 PM, JD wrote:
>   Is there a Linux util to scrub free disk blocks and keep everything 
> else intact ??
> 

This really is an interested thread... but why do you want to scrub free
blocks?

I can think of a few reasons:

1) You're running Linux in a virtual machine. Zeroing all free space
makes it easier to compress the image file.

2) You've been looking at something "bad" and want to make sure all
traces of it are gone before the lawyers/cops arrive.

There are probably other good reasons, but I'm stalled out here.



-- 
-- Steve
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: HP 6930p: mute button doesn't work properly

[Zoltan Hoppar]

Well,

This is not the chip that I have probably thought of, but I just only hope
that helps. This line helped to me, and I think puts the HDA Intel snd
driver right direction. There is no guarantee it works but one try - and we
will see it. Maybe another kernel glitch - and it will be repaired in
further kernels.

So... Let's try.

First - stand back to default, as you boot in - don't run anything that
needs sound.
Secondly - create an empty text file - named 'alsa-base.conf'
Third - For content insert this single line without quotes - ' options
snd-hda-intel position_fix=1' - and save it.
Fourth - place this file as root to /etc/modprobe.d
Fifth - close everything, and restart the complete fedora.

If you return, first - try mic, and try to play something. If everything
seems alright, then try to mute.

HTH.

See you,

Zoltan



2010/8/28 Hoang Le 

> Dear Zoltan,
>
> Here are the results. Hope that they help. Thank you
> 
> lsmod
>
> Module  Size  Used by
> aes_x86_64  7654  3
> aes_generic27012  1 aes_x86_64
> fuse   54749  2
> cpufreq_ondemand8420  2
> acpi_cpufreq7493  1
> freq_table  3851  2 cpufreq_ondemand,acpi_cpufreq
> nf_conntrack_netbios_ns 1502  0
> ip6t_REJECT 4055  2
> nf_conntrack_ipv6  17513  8
> ip6table_filter 2743  1
> ip6_tables 16558  1 ip6table_filter
> ipv6  267017  21 ip6t_REJECT,nf_conntrack_ipv6
> uinput  7230  0
> snd_hda_codec_analog72626  1
> arc41377  2
> ecb 1967  2
> iwlagn147169  0
> snd_hda_intel  24280  2
> ppdev   8142  0
> iwlcore   220139  1 iwlagn
> snd_hda_codec  73671  2 snd_hda_codec_analog,snd_hda_intel
> parport_pc 20649  0
> tpm_infineon8075  0
> mac80211  197166  2 iwlagn,iwlcore
> snd_hwdep   6206  1 snd_hda_codec
> parport30553  2 ppdev,parport_pc
> snd_seq50925  0
> sdhci_pci   6910  0
> snd_seq_device  5895  1 snd_seq
> snd_pcm76131  2 snd_hda_intel,snd_hda_codec
> hp_wmi  5025  0
> sdhci  17430  1 sdhci_pci
> hp_accel   11864  0
> uvcvideo   54017  0
> videodev   35123  1 uvcvideo
> mmc_core   59134  1 sdhci
> ricoh_mmc   3208  0
> iTCO_wdt   10864  0
> v4l1_compat12570  2 uvcvideo,videodev
> e1000e115757  0
> cfg80211  117182  3 iwlagn,iwlcore,mac80211
> lis3lv02d   7358  1 hp_accel
> v4l2_compat_ioctl32 9793  1 videodev
> iTCO_vendor_support 2451  1 iTCO_wdt
> wmi 6600  1 hp_wmi
> snd_timer  19234  2 snd_seq,snd_pcm
> joydev  9439  0
> rfkill 16402  3 hp_wmi,cfg80211
> input_polldev   3757  1 lis3lv02d
> serio_raw   4539  0
> snd60573  12
> snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
> soundcore   6198  1 snd
> snd_page_alloc  7221  2 snd_hda_intel,snd_pcm
> microcode  17930  0
> pata_pcmcia10098  1
> firewire_ohci  20136  0
> firewire_core  42425  1 firewire_ohci
> crc_itu_t   1523  1 firewire_core
> yenta_socket   22610  3
> rsrc_nonstatic  7974  1 yenta_socket
> pata_acpi   3251  0
> ata_generic 3355  0
> video  20741  0
> output  2117  1 video
> radeon589901  3
> ttm53215  1 radeon
> drm_kms_helper 23936  1 radeon
> drm   169089  5 radeon,ttm,drm_kms_helper
> i2c_algo_bit4781  1 radeon
> i2c_core   24507  5
> videodev,radeon,drm_kms_helper,drm,i2c_algo_bit
>
> -
>
> aplay -l
>
>  List of PLAYBACK Hardware Devices 
> card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
>
> --
> *From:* Zoltan Hoppar 
> *To:* Community support for Fedora users 
> *Sent:* Sat, August 28, 2010 12:36:10 AM
> *Subject:* Re: HP 6930p: mute button doesn't work properly
>
> Hi,
>
> Please tell me the chipset you use in your machine. I have purchased an HP
> and met this problem also. Maybe I know an solution to it, if it's an Altec
> Lansig chipset (or as known Azalia, or such). Hp lately uses ATI RS XXX
> chipsets, and this needs one line of modification, and after it perhaps will
> work.
>
> To decision please provide the following info: 'lsmod' and 'aplay -l'
>
> Thank you.
>
> Zoltan.
>
>
> --
> users mailing list
> use

Re: Scrub free disk blocks

[mike cloaked]

On Sat, Aug 28, 2010 at 5:13 PM, Bruno Wolff III  wrote:
> On Sat, Aug 28, 2010 at 08:36:48 -0700,
>  JD  wrote:
>> There is nothing you can do about
>> relocated bad blocks.
>
> You can use secure erase. That is suppsed to try to do something with those.
> You can also use encryption in the first place.
> It will be some work to get from where the system is now to a state where
> secure erase has been used and stuff is put back on top of an encrypted
> block device, but it can be done.

This is interesting - I recently had a machine that was reporting an
HD that passed the health check, but there were palimpsest popups
appearing warning of possible disc failure due to pending reallocated
sector counts going up.  It took me a week to get a replacement
machine to slot in and when I got the dying machine out of service I
used secure erase to kill the disc data after booting a live cd and
running hdparm commands to issue the secure erase. At the end of the
secure erase process, which appeared to end normally, I used a live CD
to boot and use palimpsest to check the "now erased" hard drive in the
original position in the processor box - the report still showed a
non-zero pending sector count so I was not sure what the state of the
data was - I had not done this before and usually simply open up the
HD and remove the platters and drive head and then "deal" with the
platters such that they would not be likely to be read again!

However in this case I was interested to see what the disc state was
(purely from an inquisitive viewpoint) after the secure erase process
had completed (using HDparm commands)

I was still unsure whether before physical destruction any data could
have been retrieved from the drive? However hdparm -I /dev/sda showed
an apparently clean disc with no partitions on it.
-- 
mike c
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Bruno Wolff III]

On Sat, Aug 28, 2010 at 13:05:08 -0500,
  Steven Stern  wrote:
> 
> I can think of a few reasons:
> 
> 1) You're running Linux in a virtual machine. Zeroing all free space
> makes it easier to compress the image file.
> 
> 2) You've been looking at something "bad" and want to make sure all
> traces of it are gone before the lawyers/cops arrive.
> 
> There are probably other good reasons, but I'm stalled out here.

You don't like nosy people snooping on your stuff.

You had proproietary data on your machine previously and you need to be sure
it is gone now.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 11:05 AM, Steven Stern wrote:
> On 08/27/2010 11:25 PM, JD wrote:
>>Is there a Linux util to scrub free disk blocks and keep everything
>> else intact ??
>>
> This really is an interested thread... but why do you want to scrub free
> blocks?
>
> I can think of a few reasons:
>
> 1) You're running Linux in a virtual machine. Zeroing all free space
> makes it easier to compress the image file.
>
> 2) You've been looking at something "bad" and want to make sure all
> traces of it are gone before the lawyers/cops arrive.
>
> There are probably other good reasons, but I'm stalled out here.
>
>
>
Too dumb a question to respond to.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Removing user list from login screen.

[Aaron Konstam]

On Sat, 2010-08-28 at 08:26 -0500, Robert Nichols wrote:
> On 08/27/2010 03:42 PM, Aaron Konstam wrote:
> > On Fri, 2010-08-27 at 19:56 +0200, Michael Schwendt wrote:
> >> On Fri, 27 Aug 2010 12:46:10 -0500, Aaron wrote:
> >>
> >>> How can you rmove the list of users that can login from login screen?
> >>>
> >>> .gconf/apps/gdm/simplegreeter/disable_user_list=true
> >>^^^
> >> What is this?
> > It is a directory present in your home directory that can be manipulated
> > using gconf-editor program. gconf-editor is File->System
> > Tools->Configuration Editor I will admit it is simple-greeter not
> > simplegreeter.
> 
> Why would you expect anything under your home directory to be of
> significance before you have logged in?
That is a good question and the answer is I would not. Which leaves with
the question in the home directory of what user should you set the
parameters of simple-greeter.?
I tried root and someone suggested a user gdm. I am still not sure.


-- 
Aaron Konstam 


gnome-gconf-editor.desktop
Description: application/desktop
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
> You need to study filesystem architecture to gain better
> understanding.

If you can't explain what you mean, just say so.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Error reading pen drive

[Bill Davidsen]

Parshwa Murdia wrote:
> On Wed, Aug 25, 2010 at 2:13 PM, Bill Davidsen  > wrote:
>  
> 
> concluding that all Windows users are numbskulls?
> 
>  
>  
> One is numbskull or not is a personal view which you say! And further is 
> relative. No doubt Linux is more more secured and powerful than Windows, 
> but did you check each and every Window user that he/she is numbskull?

I think you need to reread the question, not take half of the last sentence of 
the paragraph and disagree with it.

-- 
Bill Davidsen 
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Slow network with F13 [SOLVED]

[Bill Davidsen]

Roberto Ragusa wrote:
> Bill Davidsen wrote:
>> Roberto Ragusa wrote:
>>> john wendel wrote:
>>>
 Looks like I'll spend a little time poking at F13 scp and see if I can 
 improve the transfer speed.
>>> Maybe you are using compression? Compression is a disadvantage when
>>> the network is fast (gigabit); you just spend CPU time.
>>>
>>> Then there is encryption. That can't be turned off. I would love
>>> an option --no-crypto for scp or rsync+ssh on local networks, but
>>> there is none: you are forced to turn to rcp or rsh or nc tricks.
>>>
>> There actually is a patch to provide encryption "none" to improve speed and 
>> reduce CPU for trusted connections.
>>
>> HINT: sure would be a nice addition to Fedora FC14!!
>>
>> It's really desirable for doing scp or ssh to/from a VM from the host. Why 
>> spend 
>> CPU encrypting a connection which is as trusted as possible? Note that for 
>> just 
>> file transfer netcat can be useful if you have the firewall set to allow it.
> 
> I didn't know about this patch. There is also a bug on Ubuntu (54180), but it
> looks like nothing has moved.
> 
> So let's hope we will have it someday.
> 
> BTW, about compression, we just have gzip. Where is LZMA? It would be useful
> on slow links (e.g., all ADSL uplinks) :-)
> 
> Maybe extra ciphers and compressions could be handled as plugins.
> 
Well good idea, but the patch I mentioned is out for inclusion now, and so 
represents a minimal effort. I agree that plug-ins would be nice, but they must 
not replace existing code or compression, for security reasons. If a plugin 
could be compromised... better to compile stuff in, what's there is adequate, 
the "none" crypto is a special case.

-- 
Bill Davidsen 
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: How to debug resume (suspend) problems?

[Geoffrey Leach]

On 08/28/2010 01:21:37 AM, Felix Schwarz wrote:
> Am 27.08.2010 22:09, schrieb Konstantin Svist:
> > Check if numlock+capslock are flashing -- if they are, kernel
> crashed
> >
> > Check if you can switch to a virtual terminal with Ctrl+Alt+F2..F6
> 
> No, I tried that before (sorry, did not mention that)
> 
> > edit /etc/sysctl.conf and set sysreq = 1. After that, when you get 
> a
> > freeze, try using REISUB (http://en.wikipedia.org/wiki/Reisub) to
> reboot
> 
> I enabled the magic sysrq and verified that I can use it when the
> system 
> is up and running. When provoked a resume failure, the system did not 
> react to any of the sysrq combinations.
> 
> So it looks to me like the system is just completely dead. Any ideas
> how 
> I can gather more information? Suspend/resume worked well in Fedora 
> 12
> 
> and in the beginnings of Fedora 13 so I really want to have that
> feature 
> back!

This is a good place to start.

http://www.mjmwired.net/kernel/Documentation/power/basic-pm-
debugging.txt

It also helps to know that /usr/sbin/pm-suspend (and related commands) 
are shell scripts, so they can be executed with 'sh -x' to follow 
what's happening.  Finally, that happens on each suspend (aka suspend 
to mem) and hibernate (aka suspend to disk) gets recorded in /var/log/
pm-suspend.log.

Good luck.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
>> You need to study filesystem architecture to gain better
>> understanding.
> If you can't explain what you mean, just say so.
>
> poc
>
I can explain it alright - and I tried to tell you that a program
can access all blocks of a file, direct and indirect, given that
tha program has the access permissions for that file, but you ignored 
it. Direct and Indirect blocks are only meaningful to the inode layer. 
The file's offset will be computed and a block number arrived at. If 
that block number is outside the range of the direct blocks, then the
indirect blocks are accessed. Enough said.
Explaining FS architecture is beyond the scope of this list, and
certainly beyond this thread.



-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dual boot Fedora 13 and Windows XP ???

[James McKenzie]

Patrick O'Callaghan wrote:
> On Sat, 2010-08-28 at 22:11 +0530, Ankur Sinha wrote:
>   
>> On Sat, 2010-08-28 at 10:33 -0430, Patrick O'Callaghan wrote:
>> 
>>> You have to partition the disk, leaving at least one partition for
>>> each
>>> system. One way is to download a live CD (or USB) copy of gparted, the
>>> GNU Partition Editor. See http://gparted.sourceforge.net/livecd.php 
>>>   
>> Another way:
>>
>> In XP:
>> right click on My Computer > Manage > Disk Management > shrink your
>> drive and leave unallocated space for Fedora.
>>
>> Once this is done, reboot with your fedora dvd in the drive, choose the
>> unallocated space as your install location and continue.
>> 
>
> Yes, that will work as long as a single Linux partition is enough. Some
> people like separate partitions for /home, swap etc., though you can get
> much the same effect via LVM.
>   
Before the days of LVM, I put /swap and / as primary partitions and 
everything else (/opt, /usr, /home, /WHATEVER) on an extended 
partition.  This worked well.  If all you have is WindowsXP, you have 
two primary partitions left

James McKenzie

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

/dev/shm size?

[Tom Horsley]

So, I just noticed that /dev/shm is 4 gig on my system
with 8 gig of main memory. Does fedora always just automatically
take half the memory for /dev/shm (I've never seen it say
more than 1% was in use, so I'm not sure why it thinks
it needs half). Does tempfs really grab all that memory
up front? Or is that just some max it can grow to if it
wants? Just curious if it affects the memory available
for my virtual machines...
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Ndiswrapper does not start during boot/network. Requires manual starts?

[Daniel B. Thurman]

I have a Gateway laptop that has a topdog
wireless chip, and have sucessfully got wireless
to work.

However, for some reason, the wireless device
does not start during bootup, ntp fails to synchronize
as a clue.

However, once up, I can log in as a user, I have to
open a gnome terminal and issue the following
commands:

# depmod -a
# modprobe ndiswrapper

What I'd like to ask, is this normally how ndiswrapper
works?  Is it possible to get ndiswrapper to start
as it boots? I have saved wireless connection into
/etc/sysconfig/network-scripts but this does not seem
to work because ndiswrapper is not activated first?

Any advice?

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Ndiswrapper does not start during boot/network. Requires manual starts?

[Mohamed El Morabity]

Le samedi 28 août 2010 à 17:17 -0700, Daniel B. Thurman a écrit :
> I have a Gateway laptop that has a topdog
> wireless chip, and have sucessfully got wireless
> to work.
> 
> However, for some reason, the wireless device
> does not start during bootup, ntp fails to synchronize
> as a clue.
> 
> However, once up, I can log in as a user, I have to
> open a gnome terminal and issue the following
> commands:
> 
> # depmod -a
> # modprobe ndiswrapper
> 
> What I'd like to ask, is this normally how ndiswrapper
> works?  Is it possible to get ndiswrapper to start
> as it boots? I have saved wireless connection into
> /etc/sysconfig/network-scripts but this does not seem
> to work because ndiswrapper is not activated first?
> 
> Any advice?
> 

Hi,

a quick fix would be to force the module to be always loaded on startup.
You could so add a script named ndiswrapper.modules for example
in /etc/sysconfig/modules/ and containing a simple "modprobe
ndiswrapper".


signature.asc
Description: This is a digitally signed message part
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[James McKenzie]

Steven Stern wrote:
> On 08/27/2010 11:25 PM, JD wrote:
>   
>>   Is there a Linux util to scrub free disk blocks and keep everything 
>> else intact ??
>>
>> 
>
> This really is an interested thread... but why do you want to scrub free
> blocks?
>
> I can think of a few reasons:
>
> 1) You're running Linux in a virtual machine. Zeroing all free space
> makes it easier to compress the image file.
>
> 2) You've been looking at something "bad" and want to make sure all
> traces of it are gone before the lawyers/cops arrive.
>
> There are probably other good reasons, but I'm stalled out here.
>
>
>
>   
One thing is that if you expect the police on your doorstop, you are 
screwed anyway.  There is NO truly secure method, other than complete 
pulverization, to destroy disk data. 

If you want to clear the free space and reuse it, then the methods 
described are sufficient.

James McKenzie
SSCP 367830
(Yes, I could give a real technical description of why but it involves a 
bunch of phyics and electrical stuff that usually drives folks nuts, 
suffice it that Data Discovery and Restore of Tucson can do what I 
describe to a hard drive that was trown into a fire and the heads were 
melted to the disk.  The police got what they wanted, the disk had child 
porn on it and had been 'secure erased' as well.)

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
> > On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
> >> You need to study filesystem architecture to gain better
> >> understanding.
> > If you can't explain what you mean, just say so.
> >
> > poc
> >
> I can explain it alright - and I tried to tell you that a program
> can access all blocks of a file, direct and indirect, given that
> tha program has the access permissions for that file, but you ignored 
> it. Direct and Indirect blocks are only meaningful to the inode layer. 
> The file's offset will be computed and a block number arrived at. If 
> that block number is outside the range of the direct blocks, then the
> indirect blocks are accessed. Enough said.
> Explaining FS architecture is beyond the scope of this list, and
> certainly beyond this thread.

I've been using Unix since 1975 and am very well aware of how the
direct/indirect addressing scheme works. And I still fail to see what
this has to do with the scrub command. Are you saying that scrub
overwrites these blocks when deleting a file? If so, what is your basis
for saying so, given that the manpage explicitly states that "only the
data in the file (and optionally its name in the directory entry) is
destroyed"?

OTOH if you're saying these blocks are irrelevant, you're contradicting
your original requirement of scrubbing any free space.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 05:32 PM, James McKenzie wrote:
> Steven Stern wrote:
>> On 08/27/2010 11:25 PM, JD wrote:
>>
>>>Is there a Linux util to scrub free disk blocks and keep everything
>>> else intact ??
>>>
>>>
>> This really is an interested thread... but why do you want to scrub free
>> blocks?
>>
>> I can think of a few reasons:
>>
>> 1) You're running Linux in a virtual machine. Zeroing all free space
>> makes it easier to compress the image file.
>>
>> 2) You've been looking at something "bad" and want to make sure all
>> traces of it are gone before the lawyers/cops arrive.
>>
>> There are probably other good reasons, but I'm stalled out here.
>>
>>
>>
>>
> One thing is that if you expect the police on your doorstop, you are
> screwed anyway.  There is NO truly secure method, other than complete
> pulverization, to destroy disk data.
>
> If you want to clear the free space and reuse it, then the methods
> described are sufficient.
>
> James McKenzie
> SSCP 367830
> (Yes, I could give a real technical description of why but it involves a
> bunch of phyics and electrical stuff that usually drives folks nuts,
> suffice it that Data Discovery and Restore of Tucson can do what I
> describe to a hard drive that was trown into a fire and the heads were
> melted to the disk.  The police got what they wanted, the disk had child
> porn on it and had been 'secure erased' as well.)
>
It seems that at least 2 individuals on this list have made the assumption
that hiding data, encrypting data and erasing data is for the purpose of
hiding criminal activity. Such an assumption would put hundreds
of millions of people, and possibly a lot more,  within these two 
individuals'
category of criminals or highly suspected of criminal activity.

Here we are in the 21st century and we still discover that there are
people with such narrow minds, that they can easily pass through a
1 picometer wide slot.
I am being very generous with that slot width.




-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:
> On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
>> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
>>> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
 You need to study filesystem architecture to gain better
 understanding.
>>> If you can't explain what you mean, just say so.
>>>
>>> poc
>>>
>> I can explain it alright - and I tried to tell you that a program
>> can access all blocks of a file, direct and indirect, given that
>> tha program has the access permissions for that file, but you ignored
>> it. Direct and Indirect blocks are only meaningful to the inode layer.
>> The file's offset will be computed and a block number arrived at. If
>> that block number is outside the range of the direct blocks, then the
>> indirect blocks are accessed. Enough said.
>> Explaining FS architecture is beyond the scope of this list, and
>> certainly beyond this thread.
> I've been using Unix since 1975 and am very well aware of how the
> direct/indirect addressing scheme works. And I still fail to see what
> this has to do with the scrub command. Are you saying that scrub
> overwrites these blocks when deleting a file? If so, what is your basis
> for saying so, given that the manpage explicitly states that "only the
> data in the file (and optionally its name in the directory entry) is
> destroyed"?
>
> OTOH if you're saying these blocks are irrelevant, you're contradicting
> your original requirement of scrubbing any free space.
>
> poc
>
Let me quote to you what YOU wrote:
On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
> From scrub(1):
>
> -X, --freespace
> Create specified directory and fill it with files until write returns 
> ENOSPC (file system full),
> then scrub the files as usual. The size of each file can be set with 
> -s, otherwise it will be the
> maximum file size creatable given the user’s file size limit or 1g if 
> umlimited.
>
> However note that neither of these methods guarantees to scrub indirect
> blocks in the filesystem that were used to create the space-filling
> files. Maybe they do, maybe they don't, it's not clear.
>
> poc

It was you who made the off-the-wall and totally wrong statement that
indirect blocks of files created by the scrub process ARE NOT SCRUBBED!

You have exposed your ignorance of the filesystem architecture, and
mentioned something you vaguely remember the name of, and totally
embarrassed yourself before a very large audience.





-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: F14 Alpha x86_64 ISO too large?

[Bill Davidsen]

JD wrote:
>   On 08/25/2010 03:29 PM, Bill Davidsen wrote:
>>> Here are the directory contents of:
>>> http://alt.fedoraproject.org/pub/alt/stage/14-Alpha.RC4/Fedora/x86_64/iso/
>>>
>>>
>>> Index of /pub/alt/stage/14-Alpha.RC4/Fedora/x86_64/iso
>>>
>> Really? That URL certainly doesn't seem to work today...
>>
> 
> Yup! They moved it. Here it is as of a few seconds ago:
> 
> http://alt.fedoraproject.org/pub/alt/stage/
> 
> Or the F14 Alpha:
> 
> http://mirrors.kernel.org/fedora/releases/test/14-Alpha/Live/x86_64/
> 
Thanks, I found it at yet another location, IIRC on download.fedoraproject.org. 
Not total consistency, but it's alpha...

-- 
Bill Davidsen 
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Bill Davidsen]

JD wrote:
>   On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:
>> On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
>>> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
 On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
> You need to study filesystem architecture to gain better
> understanding.
 If you can't explain what you mean, just say so.

 poc

>>> I can explain it alright - and I tried to tell you that a program
>>> can access all blocks of a file, direct and indirect, given that
>>> tha program has the access permissions for that file, but you ignored
>>> it. Direct and Indirect blocks are only meaningful to the inode layer.
>>> The file's offset will be computed and a block number arrived at. If
>>> that block number is outside the range of the direct blocks, then the
>>> indirect blocks are accessed. Enough said.
>>> Explaining FS architecture is beyond the scope of this list, and
>>> certainly beyond this thread.
>> I've been using Unix since 1975 and am very well aware of how the
>> direct/indirect addressing scheme works. And I still fail to see what
>> this has to do with the scrub command. Are you saying that scrub
>> overwrites these blocks when deleting a file? If so, what is your basis
>> for saying so, given that the manpage explicitly states that "only the
>> data in the file (and optionally its name in the directory entry) is
>> destroyed"?
>>
>> OTOH if you're saying these blocks are irrelevant, you're contradicting
>> your original requirement of scrubbing any free space.
>>
>> poc
>>
> Let me quote to you what YOU wrote:
> On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
>> From scrub(1):
>>
>> -X, --freespace
>> Create specified directory and fill it with files until write returns 
>> ENOSPC (file system full),
>> then scrub the files as usual. The size of each file can be set with 
>> -s, otherwise it will be the
>> maximum file size creatable given the user’s file size limit or 1g if 
>> umlimited.
>>
>> However note that neither of these methods guarantees to scrub indirect
>> blocks in the filesystem that were used to create the space-filling
>> files. Maybe they do, maybe they don't, it's not clear.
>>
>> poc
> 
> It was you who made the off-the-wall and totally wrong statement that
> indirect blocks of files created by the scrub process ARE NOT SCRUBBED!
> 
Since you imply that they are, please identify the method of doing so, since 
the 
documentation and source only seem to scrub the file *content* and not the 
indirect (ie. inode) blocks at all. There's code to zero the filename, and 
maybe 
truncating the file would clear the primary inode and release the indirect 
blocks, but I think inode clearing is f/s dependent, not necessarily a given.

I can see how the inode indirect blocks might get zeroed (on some filesystems), 
but I see no way to cause scrubbing with multiple random patterns.

> You have exposed your ignorance of the filesystem architecture, and
> mentioned something you vaguely remember the name of, and totally
> embarrassed yourself before a very large audience.
> 
Having jumped all over Patrick, please point us to the filesystem or other code 
to scrub the inode indirect blocks.

Don't read this as a claim the indirect blocks need to be scrubbed, but do tell 
us just how that scrubbing occurs. You haven't confused indirect block 
(filesystem metadata) with the data blocks described by the indirect blocks, 
have you?

-- 
Bill Davidsen 
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: clickpad pointer devicedoes not work in FC-12

[abhijeet tripathi]

Thanks for the input but my issue is not completely solved.

I cannot do right click or left click and also the two finger scroll
is disabled. Can you let me know how to solve it.

--Abhijeet

On Fri, Aug 27, 2010 at 2:19 PM, Kevin J. Cummings
 wrote:
> On 08/27/2010 05:12 PM, abhijeet tripathi wrote:
>> Hi,
>>
>> I installed xorg-x11-drv-synaptics driver in FC-12 but still my
>> clickpad mouse is not fully functional.
>> Is there any more applications I need to install?
>
> Did you configure it via System->Preferences->Mouse TouchPad tab?
> (It least that's where it is in Gnome.)
>
>> Thanks in advance.
>>
>> --Abhijeet
>
>
> --
> Kevin J. Cummings
> kjch...@rcn.com
> cummi...@kjchome.homeip.net
> cummi...@kjc386.framingham.ma.us
> Registered Linux User #1232 (http://counter.li.org)
> --
> users mailing list
> users@lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 06:35 PM, Bill Davidsen wrote:
> JD wrote:
>>On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:
>>> On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
 On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
>> You need to study filesystem architecture to gain better
>> understanding.
> If you can't explain what you mean, just say so.
>
> poc
>
 I can explain it alright - and I tried to tell you that a program
 can access all blocks of a file, direct and indirect, given that
 tha program has the access permissions for that file, but you ignored
 it. Direct and Indirect blocks are only meaningful to the inode layer.
 The file's offset will be computed and a block number arrived at. If
 that block number is outside the range of the direct blocks, then the
 indirect blocks are accessed. Enough said.
 Explaining FS architecture is beyond the scope of this list, and
 certainly beyond this thread.
>>> I've been using Unix since 1975 and am very well aware of how the
>>> direct/indirect addressing scheme works. And I still fail to see what
>>> this has to do with the scrub command. Are you saying that scrub
>>> overwrites these blocks when deleting a file? If so, what is your basis
>>> for saying so, given that the manpage explicitly states that "only the
>>> data in the file (and optionally its name in the directory entry) is
>>> destroyed"?
>>>
>>> OTOH if you're saying these blocks are irrelevant, you're contradicting
>>> your original requirement of scrubbing any free space.
>>>
>>> poc
>>>
>> Let me quote to you what YOU wrote:
>> On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
>>>  From scrub(1):
>>>
>>> -X, --freespace
>>> Create specified directory and fill it with files until write returns
>>> ENOSPC (file system full),
>>> then scrub the files as usual. The size of each file can be set with
>>> -s, otherwise it will be the
>>> maximum file size creatable given the user’s file size limit or 1g if
>>> umlimited.
>>>
>>> However note that neither of these methods guarantees to scrub indirect
>>> blocks in the filesystem that were used to create the space-filling
>>> files. Maybe they do, maybe they don't, it's not clear.
>>>
>>> poc
>> It was you who made the off-the-wall and totally wrong statement that
>> indirect blocks of files created by the scrub process ARE NOT SCRUBBED!
>>
> Since you imply that they are, please identify the method of doing so, since 
> the
> documentation and source only seem to scrub the file *content* and not the
> indirect (ie. inode) blocks at all. There's code to zero the filename, and 
> maybe
> truncating the file would clear the primary inode and release the indirect
> blocks, but I think inode clearing is f/s dependent, not necessarily a given.
>
> I can see how the inode indirect blocks might get zeroed (on some 
> filesystems),
> but I see no way to cause scrubbing with multiple random patterns.
The data blocks, be they direct or indirect data blocks ( an 'attribute' 
- and I use the word
attribute here loosely to make a point - is only meaningful to the inode 
layer),
has absolutely NOTHING to do with what the scrub program does to ALL the 
blocks of a file.
So, just get off of this whole thing about direct and indirect blocks.
This is irrelevant to the subject of scrubbing a file.
Rest assured scrub will get all of a file's blocks.
>> You have exposed your ignorance of the filesystem architecture, and
>> mentioned something you vaguely remember the name of, and totally
>> embarrassed yourself before a very large audience.
>>
> Having jumped all over Patrick, please point us to the filesystem or other 
> code
> to scrub the inode indirect blocks.
As stated above.
> Don't read this as a claim the indirect blocks need to be scrubbed, but do 
> tell
> us just how that scrubbing occurs. You haven't confused indirect block
> (filesystem metadata) with the data blocks described by the indirect blocks,
> have you?
>
A filesystem's metadata are things like inodes and cylinder groups, and 
superblocks.
These are NOT indirect blocks. Do not confuse filesystem metadata with a 
file's
data.
When a file is deleted, then the inode for that file is returned to the 
free list.
That inode does not have a file's content. Only info about that file, 
such as
owner, permissions, ..  and the addresses of the blocks holding the data of
that file.



-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[James McKenzie]

JD wrote:
>   On 08/28/2010 05:32 PM, James McKenzie wrote:
>   
>> Steven Stern wrote:
>> 
>>> On 08/27/2010 11:25 PM, JD wrote:
>>>
>>>   
Is there a Linux util to scrub free disk blocks and keep everything
 else intact ??


 
>>> This really is an interested thread... but why do you want to scrub free
>>> blocks?
>>>
>>> I can think of a few reasons:
>>>
>>> 1) You're running Linux in a virtual machine. Zeroing all free space
>>> makes it easier to compress the image file.
>>>
>>> 2) You've been looking at something "bad" and want to make sure all
>>> traces of it are gone before the lawyers/cops arrive.
>>>
>>> There are probably other good reasons, but I'm stalled out here.
>>>
>>>
>>>
>>>   
There are lots of good reasons.  You have been accessing your bank 
accounts and want to give the drive to your highly intelligent prodigy 
and they know how to read a drive and recover data.  You have been using 
the drive in your business and don't want business data going home with 
you when you pull the drive and use in it your laptop.
>>>   
>> One thing is that if you expect the police on your doorstop, you are
>> screwed anyway.  There is NO truly secure method, other than complete
>> pulverization, to destroy disk data.
>>
>> If you want to clear the free space and reuse it, then the methods
>> described are sufficient.
>>
>> James McKenzie
>> SSCP 367830
>> (Yes, I could give a real technical description of why but it involves a
>> bunch of phyics and electrical stuff that usually drives folks nuts,
>> suffice it that Data Discovery and Restore of Tucson can do what I
>> describe to a hard drive that was trown into a fire and the heads were
>> melted to the disk.  The police got what they wanted, the disk had child
>> porn on it and had been 'secure erased' as well.)
>>
>> 
> It seems that at least 2 individuals on this list have made the assumption
> that hiding data, encrypting data and erasing data is for the purpose of
> hiding criminal activity. Such an assumption would put hundreds
> of millions of people, and possibly a lot more,  within these two 
> individuals'
> category of criminals or highly suspected of criminal activity.
>   
Did I say you were hiding criminal activity?  There are LOTS of 
legitimate reasons to encrypt data and to clean it off.  If you work in 
the PCI industry or for the US Federal Government, you have to do both, 
on a regular basis.  This is why the NSA has Secure Erase available.  
Other folks don't want 'lingering' data to come back and bite them.  
However, if you think that Secure Erase or any other program is going to 
completely wipe your hard drive, that is not so.  Secure Erase only 
gives the ability to reuse the disk in the same operating environment.  
That means if you were processing company proprietary data, then you 
cannot give the drive away.  It has to be physically destroyed.  That is 
the only way to ensure data is not available.
> Here we are in the 21st century and we still discover that there are
> people with such narrow minds, that they can easily pass through a
> 1 picometer wide slot.
> I am being very generous with that slot width.
>
>   
My mind is not narrow.  All I did is state "IF you are expecting the 
police on your doorstop"  not WHEN.  If you are using these for 
legitimate reasons, that is wonderful.  You are forward thinking, a lot 
better than most folks who find that they shipped their 'clean drives' 
to others only to find out they pulled a bunch of personal information 
and used it for ill intended reasons.

James McKenzie
SSCP 367830

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[James McKenzie]

JD wrote:
>   On 08/28/2010 06:35 PM, Bill Davidsen wrote:
>   
>> JD wrote:
>> 
>>>On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:
>>>   
 On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
 
> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
>   
>> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
>> 
>>> You need to study filesystem architecture to gain better
>>> understanding.
>>>   
>> If you can't explain what you mean, just say so.
>>
>> poc
>>
>> 
> I can explain it alright - and I tried to tell you that a program
> can access all blocks of a file, direct and indirect, given that
> tha program has the access permissions for that file, but you ignored
> it. Direct and Indirect blocks are only meaningful to the inode layer.
> The file's offset will be computed and a block number arrived at. If
> that block number is outside the range of the direct blocks, then the
> indirect blocks are accessed. Enough said.
> Explaining FS architecture is beyond the scope of this list, and
> certainly beyond this thread.
>   
 I've been using Unix since 1975 and am very well aware of how the
 direct/indirect addressing scheme works. And I still fail to see what
 this has to do with the scrub command. Are you saying that scrub
 overwrites these blocks when deleting a file? If so, what is your basis
 for saying so, given that the manpage explicitly states that "only the
 data in the file (and optionally its name in the directory entry) is
 destroyed"?

 OTOH if you're saying these blocks are irrelevant, you're contradicting
 your original requirement of scrubbing any free space.

 poc

 
>>> Let me quote to you what YOU wrote:
>>> On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
>>>   
  From scrub(1):

 -X, --freespace
 Create specified directory and fill it with files until write returns
 ENOSPC (file system full),
 then scrub the files as usual. The size of each file can be set with
 -s, otherwise it will be the
 maximum file size creatable given the user’s file size limit or 1g if
 umlimited.

 However note that neither of these methods guarantees to scrub indirect
 blocks in the filesystem that were used to create the space-filling
 files. Maybe they do, maybe they don't, it's not clear.

 poc
 
>>> It was you who made the off-the-wall and totally wrong statement that
>>> indirect blocks of files created by the scrub process ARE NOT SCRUBBED!
>>>
>>>   
>> Since you imply that they are, please identify the method of doing so, since 
>> the
>> documentation and source only seem to scrub the file *content* and not the
>> indirect (ie. inode) blocks at all. There's code to zero the filename, and 
>> maybe
>> truncating the file would clear the primary inode and release the indirect
>> blocks, but I think inode clearing is f/s dependent, not necessarily a given.
>>
>> I can see how the inode indirect blocks might get zeroed (on some 
>> filesystems),
>> but I see no way to cause scrubbing with multiple random patterns.
>> 
> The data blocks, be they direct or indirect data blocks ( an 'attribute' 
> - and I use the word
> attribute here loosely to make a point - is only meaningful to the inode 
> layer),
> has absolutely NOTHING to do with what the scrub program does to ALL the 
> blocks of a file.
> So, just get off of this whole thing about direct and indirect blocks.
> This is irrelevant to the subject of scrubbing a file.
> Rest assured scrub will get all of a file's blocks.
>   
>>> You have exposed your ignorance of the filesystem architecture, and
>>> mentioned something you vaguely remember the name of, and totally
>>> embarrassed yourself before a very large audience.
>>>
>>>   
>> Having jumped all over Patrick, please point us to the filesystem or other 
>> code
>> to scrub the inode indirect blocks.
>> 
> As stated above.
>   
>> Don't read this as a claim the indirect blocks need to be scrubbed, but do 
>> tell
>> us just how that scrubbing occurs. You haven't confused indirect block
>> (filesystem metadata) with the data blocks described by the indirect blocks,
>> have you?
>>
>> 
> A filesystem's metadata are things like inodes and cylinder groups, and 
> superblocks.
> These are NOT indirect blocks. Do not confuse filesystem metadata with a 
> file's
> data.
> When a file is deleted, then the inode for that file is returned to the 
> free list.
> That inode does not have a file's content. Only info about that file, 
> such as
> owner, permissions, ..  and the addresses of the blocks holding the data of
> that file.
>
>   
If a file is moved to the trash, then the inode is retained, but the 
file is now linked to the trash directory.  When it is removed from the 
trash and thrown aw

Re: Scrub free disk blocks

[JD]

  On 08/28/2010 07:21 PM, James McKenzie wrote:
> JD wrote:
>>On 08/28/2010 06:35 PM, Bill Davidsen wrote:
>>
>>> JD wrote:
>>>
 On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:

> On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
>
>> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
>>
>>> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
>>>
 You need to study filesystem architecture to gain better
 understanding.

>>> If you can't explain what you mean, just say so.
>>>
>>> poc
>>>
>>>
>> I can explain it alright - and I tried to tell you that a program
>> can access all blocks of a file, direct and indirect, given that
>> tha program has the access permissions for that file, but you ignored
>> it. Direct and Indirect blocks are only meaningful to the inode layer.
>> The file's offset will be computed and a block number arrived at. If
>> that block number is outside the range of the direct blocks, then the
>> indirect blocks are accessed. Enough said.
>> Explaining FS architecture is beyond the scope of this list, and
>> certainly beyond this thread.
>>
> I've been using Unix since 1975 and am very well aware of how the
> direct/indirect addressing scheme works. And I still fail to see what
> this has to do with the scrub command. Are you saying that scrub
> overwrites these blocks when deleting a file? If so, what is your basis
> for saying so, given that the manpage explicitly states that "only the
> data in the file (and optionally its name in the directory entry) is
> destroyed"?
>
> OTOH if you're saying these blocks are irrelevant, you're contradicting
> your original requirement of scrubbing any free space.
>
> poc
>
>
 Let me quote to you what YOU wrote:
 On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:

>From scrub(1):
>
> -X, --freespace
> Create specified directory and fill it with files until write returns
> ENOSPC (file system full),
> then scrub the files as usual. The size of each file can be set with
> -s, otherwise it will be the
> maximum file size creatable given the user’s file size limit or 1g if
> umlimited.
>
> However note that neither of these methods guarantees to scrub indirect
> blocks in the filesystem that were used to create the space-filling
> files. Maybe they do, maybe they don't, it's not clear.
>
> poc
>
 It was you who made the off-the-wall and totally wrong statement that
 indirect blocks of files created by the scrub process ARE NOT SCRUBBED!


>>> Since you imply that they are, please identify the method of doing so, 
>>> since the
>>> documentation and source only seem to scrub the file *content* and not the
>>> indirect (ie. inode) blocks at all. There's code to zero the filename, and 
>>> maybe
>>> truncating the file would clear the primary inode and release the indirect
>>> blocks, but I think inode clearing is f/s dependent, not necessarily a 
>>> given.
>>>
>>> I can see how the inode indirect blocks might get zeroed (on some 
>>> filesystems),
>>> but I see no way to cause scrubbing with multiple random patterns.
>>>
>> The data blocks, be they direct or indirect data blocks ( an 'attribute'
>> - and I use the word
>> attribute here loosely to make a point - is only meaningful to the inode
>> layer),
>> has absolutely NOTHING to do with what the scrub program does to ALL the
>> blocks of a file.
>> So, just get off of this whole thing about direct and indirect blocks.
>> This is irrelevant to the subject of scrubbing a file.
>> Rest assured scrub will get all of a file's blocks.
>>
 You have exposed your ignorance of the filesystem architecture, and
 mentioned something you vaguely remember the name of, and totally
 embarrassed yourself before a very large audience.


>>> Having jumped all over Patrick, please point us to the filesystem or other 
>>> code
>>> to scrub the inode indirect blocks.
>>>
>> As stated above.
>>
>>> Don't read this as a claim the indirect blocks need to be scrubbed, but do 
>>> tell
>>> us just how that scrubbing occurs. You haven't confused indirect block
>>> (filesystem metadata) with the data blocks described by the indirect blocks,
>>> have you?
>>>
>>>
>> A filesystem's metadata are things like inodes and cylinder groups, and
>> superblocks.
>> These are NOT indirect blocks. Do not confuse filesystem metadata with a
>> file's
>> data.
>> When a file is deleted, then the inode for that file is returned to the
>> free list.
>> That inode does not have a file's content. Only info about that file,
>> such as
>> owner, permissions, ..  and the addresses of the blocks holding the data of
>> that file.
>>
>>
> If a file is moved to the trash, then the inode is retained, but the
> file is now linked to the trash directory.  When it is removed from

Re: Scrub free disk blocks

[Patrick O'Callaghan]

On Sat, 2010-08-28 at 18:01 -0700, JD wrote:
> > However note that neither of these methods guarantees to scrub
> indirect
> > blocks in the filesystem that were used to create the space-filling
> > files. Maybe they do, maybe they don't, it's not clear.
> >
> > poc
> 
> It was you who made the off-the-wall and totally wrong statement that
> indirect blocks of files created by the scrub process ARE NOT
> SCRUBBED!

Bullshit. I did said no such thing. Take the trouble to reread the above
and understand what I actually said, not what your prejudice leads you
to think I said. Even a child can understand the difference between
"does not guarantee to do X" and "does not do X". Furthermore, you still
insist on "does do X" without thus far producing a shred of evidence to
support this.

Furthermore, it's clear from your replies that you still don't get what
I'm talking about and can think of no comeback other than childish ad
hominem attacks. This exchange is going nowhere.

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[James McKenzie]

JD wrote:
[trimmed]
>   
> Well, that's the point another op has made: If you have
> a failing disk, and you have credit card account data,
> bank account data, tax data, and many other type of
> proprietary product secrets, business plans, meetings records...etc,
> then you should consider destroying the disk utterly and
> thoroughly instead of sending it in for RMA.
>
>   
Corrrect.  That is why any 'production' level disk should be RMA without 
the physical disk.  Just send back a tag and then certify the disk has 
been destroyed.  Too many RMAs and you get 'black listed' and this means 
replacing the same drive time and time again.  You have a bigger problem 
than hard drives at this point. 
> But what about the need to recover the data from such a disk?
> THAT's when you will DEFINITELY and MOST CERTAINLY compromise
> that data when you send the disk to a data recovery company.
>
>   
DDR has a clause that they will NOT release information, unless 
requested, to anyone other than the originator, unless it clearly 
violates Federal/State/Local statues.  Usually, this is records of 
viewable pornography of under aged participants.  They have been used to 
recover data from a drive that was under water for months and for a 
drive that had a hole drilled through it. 

In any case, if someone wants your data that bad, it is time to dig out 
the old sledgehammer and physically destroy the disk.  Otherwise, scrub 
and other secure erasure programs should be sufficient.

James McKenzie


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Removing user list from login screen.

[Robert Nichols]

On 08/28/2010 03:29 PM, Aaron Konstam wrote:
> On Sat, 2010-08-28 at 08:26 -0500, Robert Nichols wrote:
>> On 08/27/2010 03:42 PM, Aaron Konstam wrote:
>>> On Fri, 2010-08-27 at 19:56 +0200, Michael Schwendt wrote:
 On Fri, 27 Aug 2010 12:46:10 -0500, Aaron wrote:

> How can you rmove the list of users that can login from login screen?
>
> .gconf/apps/gdm/simplegreeter/disable_user_list=true
 ^^^
 What is this?
>>> It is a directory present in your home directory that can be manipulated
>>> using gconf-editor program. gconf-editor is File->System
>>> Tools->Configuration Editor I will admit it is simple-greeter not
>>> simplegreeter.
>>
>> Why would you expect anything under your home directory to be of
>> significance before you have logged in?
> That is a good question and the answer is I would not. Which leaves with
> the question in the home directory of what user should you set the
> parameters of simple-greeter.?
> I tried root and someone suggested a user gdm. I am still not sure.

I don't know either.  User "gdm" sounds like a good bet.  But, changing
that setting in the home directory of Joe RandomUser on a multi-user
system certainly can't be expected to change the way the greeter operates
before any user name has been selected.  The fact that the config editor
even allows you to try that should probably be reported as a bug.

-- 
Bob Nichols "NOSPAM" is really part of my email address.
 Do NOT delete it.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dual boot Fedora 13 and Windows XP ???

[Darr]

On Saturday, 28 August, 2010 @23:54 zulu, James McKenzie scribed:
> 
> Before the days of LVM, I put /swap and / as primary partitions and
> everything else (/opt, /usr, /home, /WHATEVER) on an extended
> partition.  This worked well.  If all you have is WindowsXP, you have
> two primary partitions left



Not with most Dell computers. Nearly all of them ship
with the first primary (sda1) as a ~50MB 'utility' FAT
partition, then an NTFS partition as sda2 with windows
on it, then a 4GB or so FAT32 partition (sda3) containing
a factory restore image, accessible from a menu in the
utility partition or directly from Win7's repair menu.

THEN, if the computer has a Media Direct button,
there will be a MediaDirect partition too (v3 and later
MediaDirect uses a visible partition rather than using
the HPA that v1 and v2 used). If you're lucky, the MD
partition is SDA5, so you could just shrink the NTFS
partition, expand the extended (sda4?) partition, which
might provide room for logical volumes in which to put fedora and swap.

It sounds like the OP has a Live CD already, since they
described booting to fedora then using the install icon.

So the output from
# fdisk -l
might be the more-appropriate info to request.

Note that the # prompt implies 'root' rather than normal 'user' access.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Howto setup OS2 using KVM in Fedora 13?

[KC8LDO]

Anybody have a good set of detailed instructions on how to go about 
installing OS2 Warp 4 using KVM in Fedora 13? The iso file of the install CD 
is non-bootable. I've seen some instructions for Qemu, which I assume could 
work for KVM, but the procedure looks messy. I'm looking for something easy 
or a good way to convert the iso into a bootable install iso.

Regards;

Leland C. Scott
KC8LDO

 

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Error reading pen drive

[Parshwa Murdia]

On Sun, Aug 29, 2010 at 2:37 AM, Bill Davidsen  wrote:


> I think you need to reread the question, not take half of the last sentence
> of
> the paragraph and disagree with it.
>


I read all and am not disagreeing but saying what is!
-- 

Regards,
Parshwa Murdia
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

DeltaISOs

[David]

Is it possible to make a deltaiso without having both the older ISO and
the Newer ISO on a local system.

Example.  Fedora-14-Alpha-x86_64-Live.iso was downloaded. A
Fedora-14-Alpha-2-x86_64-Live.iso is availible for download.

Can a deltaiso be made without downloading the newer ISO?


makedeltaiso Fedora-14-Alpha-x86_64-Live.iso
http://path/to/folder/containing/Fedora-14-Alpha-2-x86_64-Live.iso deltaiso


-- 


  David
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: DeltaISOs

[Jonathan Dieter]

On Sun, 2010-08-29 at 01:49 -0400, David wrote:
> Is it possible to make a deltaiso without having both the older ISO and
> the Newer ISO on a local system.
> 
> Example.  Fedora-14-Alpha-x86_64-Live.iso was downloaded. A
> Fedora-14-Alpha-2-x86_64-Live.iso is availible for download.
> 
> Can a deltaiso be made without downloading the newer ISO?
> 
> 
> makedeltaiso Fedora-14-Alpha-x86_64-Live.iso
> http://path/to/folder/containing/Fedora-14-Alpha-2-x86_64-Live.iso deltaiso

No.  Makedeltaiso doesn't understand web links, only local files.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Scrub free disk blocks

[Marko Vojinovic]

On Sunday, August 29, 2010 01:32:34 James McKenzie wrote:
> One thing is that if you expect the police on your doorstop, you are
> screwed anyway.  There is NO truly secure method, other than complete
> pulverization, to destroy disk data.

Whenever I see a statement like this (and this isn't the first time), I get 
baffled over and over with how is this possible.

Starting from the premise that every hard disk has in principle limited 
capacity to store data, one can always fill it up completely, then rewrite it 
completely again. I see no way of the old data being recoverable, because this 
is in contradiction with the fact that the disk was filled up completely two 
times. The old data has to be destroyed in order to make room for new data. At 
least as far as I can understand it.

OTOH, if the premise is false, it means that I can fill the disk with arbitrary 
amount of information and have it all recoverable in principle. That doesn't 
sound very reasonable, because the disk is made ultimately of a finite number 
of particles, and can thus be in finitely many different states. I see no way 
how a piece of metal can hold infinite amount of information.

Or let me put it more bluntly --- take a cup and fill it up with oil. Then try 
to fill it with the equal amount of water. The oil is going to overflow, and 
will be lost beyond any chance of recovery from within the cup. I see no way 
to avoid that. The structure of information storage on a hard disk is 
technically more intricate, but ultimately obeys the same principle.

So am I missing something?

Best, :-)
Marko

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines