Hi,
I just paid attention that utility 'dd' uses just 2 GB even I use greater
block size (BS). For example
=
[root@pcfarm-10 ~]# dd if=/dev/zero of=/mnt/sdb/TestFile-S1 bs=12GB count=1
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 15.8235 seconds, 136 MB/s
It says it only copied 2.1GB. You are runnig a 64bit OS. You reinstalld
the same coreutils package. You need to change the format of the package
names from rpm -qa if you want to see the architecture (man rpm should
help you figure out how).
On Wed, 1 Feb 2012, Andrey Y Shevel wrote:
Hi,
I
On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=636628
Give root password for maintenance
(or type Control-D to continue):
At this stage, at every second key stroke, it reports Login incorrect. and
repeats the above Give root
On 02/01/2012 09:03 AM, Konstantin Olchanski wrote:
On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=636628
[snip]
Anyone with physical access to the machine can walk away with your disks,
or boot their own OS from a USB disk or from
Hi Stephen,
thanks for the reply.
I am not sure that I do understand you (sorry for my stupidity).
I have
===
[root@pcfarm-10 ~]# yum list | grep coreutil
Failed to set locale, defaulting to C
coreutils.x86_64 5.97-34.el5
installed
Exactly if you type man rpm it will show you how you get it to print
the arch string (usually i686 or x86_64). Since you seem unabel to read a
man page what you want to type is;
rpm -qa --queryformat %{NAME}-%{VERSION}.%{ARCH}\n | grep coreutils
(or miss out the VERSION if you want to see
On Wed, Feb 1, 2012 at 12:28 PM, Yasha Karant ykar...@csusb.edu wrote:
On 02/01/2012 09:03 AM, Konstantin Olchanski wrote:
On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=636628
[snip]
Anyone with physical access to the machine can
On Wed, Feb 01, 2012 at 09:28:58AM -0800, Yasha Karant wrote:
It is my understanding that if the BIOS on a standard IA-32 or
X86-64 machine is protected by a boot password, then there is no
access to the boot procedure of the BIOS and thus the media you
suggest cannot be booted unless these
Just on a hunch how much does it copy if you give it a BS=1GB?
This might be an uncaught 32 bit int on only the block size value.
{^_^}
On 2012/02/01 09:58, Andrey Y. Shevel wrote:
Hi Stephen,
thanks for the reply.
I am not sure that I do understand you (sorry for my stupidity).
I have
On 2012/02/01 09:28, Yasha Karant wrote:
On 02/01/2012 09:03 AM, Konstantin Olchanski wrote:
On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=636628
[snip]
Anyone with physical access to the machine can walk away with your disks,
or
On 02/01/2012 12:22 PM, jdow wrote:
On 2012/02/01 09:28, Yasha Karant wrote:
On 02/01/2012 09:03 AM, Konstantin Olchanski wrote:
On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=636628
[snip]
Anyone with physical access to the machine
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant ykar...@csusb.edu wrote:
Back to my primary point: the bug in accepting the root password upon a
failed fsck during boot is from TUV and documented (please see a previous
post nominally in this thread). Is there any fix? I do not care if the fix
On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant ykar...@csusb.edu wrote:
Back to my primary point: the bug in accepting the root password upon a
failed fsck during boot is from TUV and documented (please see a previous
On Wed, 1 Feb 2012, Tom H wrote:
On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant ykar...@csusb.edu wrote:
Back to my primary point: =A0the bug in accepting the root password upon=
a
failed fsck during boot is from TUV
On 02/01/2012 03:05 PM, Nico Kadel-Garcia wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karantykar...@csusb.edu wrote:
Back to my primary point: the bug in accepting the root password upon a
failed fsck during boot is from TUV and documented (please see a previous
post nominally in this
On Wed, Feb 1, 2012 at 6:44 PM, Yasha Karant ykar...@csusb.edu wrote:
On 02/01/2012 03:05 PM, Nico Kadel-Garcia wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karantykar...@csusb.edu wrote:
Back to my primary point: the bug in accepting the root password upon a
failed fsck during boot is
On Wed, Feb 1, 2012 at 6:42 PM, Connie Sieh cs...@fnal.gov wrote:
On Wed, 1 Feb 2012, Tom H wrote:
It's not a bug; it's a TUV decision. Requiring the root password for
single user mode can be set through /etc/sysconfig/init.
There is even a rpm for that called SL_password_for_singleuser .
I
On 2012/02/01 15:38, Tom H wrote:
On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcianka...@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karantykar...@csusb.edu wrote:
Back to my primary point: the bug in accepting the root password upon a
failed fsck during boot is from TUV and
18 matches
Mail list logo
