[gentoo-user] soliciting a DHCP lease / carrier lost

[thelma]

The new box I installed in remote location has a problem obtaining IP
address.  The box was working perfectly on my local LAN.

In remote location I assigned static IP to it 10.10.0.5
Previously this IP was assigned to a Virtual Box but I no longer use it,
so I assign this IP to a new box.

The box was working for a day, but now when I boot the box I get
- soliciting a DHCP lease
- carrier lost

Could the old IP get stuck somewhere in DD-WRT router?

ping 10.10.0.5 - gives me no response.

The Cat5 is about 15-20meter long, I test it with a cable tester, it is
good (all the lights light up in correct order).
Cable is plugged in into a new switch.

I'll try to assign different address to it tomorrow and will try a new
router on Friday.

-- 
Thelma

[gentoo-user] Re: [OT] Tools for putting HDD back to new state

[Kai Krakow]

Am Mon, 3 Apr 2017 16:15:24 -0400
schrieb Rich Freeman :

> On Mon, Apr 3, 2017 at 2:34 PM, Kai Krakow 
> wrote:
> >
> > Just dd /dev/zero to the complete device. That purges everything you
> > need: partition tables, boot sectors, contents:
> >
> > # dd if=/dev/zero of=/dev/sdX
> >  
> 
> If it contains data you'd prefer not be recoverable you might want to
> use shred or ATA secure erase.

I wonder if shredding adds any value with the high density of modern
drives... Each bit is down to a "few" (*) atoms. It should be pretty
difficult, if not impossible, to infer the previous data from it. I
think most of the ability to infer the previous data comes from
magnetic leakage from the written bit to the neighbor bits. And this is
why clever mathematicians created series of alternating bit patterns to
distribute this leakage evenly, which is the different algorithms the
shredder programs use.

Do you have any insights on that matter? Just curious.

> Shred overwrites the drive with random data using a few passes to make
> recovery more difficult.  Some debate whether it actually adds value.

For a mere mortal it is already impossible to recover data after
writing zeros to it. Shredding is very time consuming and probably not
worth the effort if you just want a blank drive and have no critical or
security relevant data on it, i.e. you used it for testing.

But while you are at it: Shredding tools should usually do a read check
to compare that the data that ought to have been written actually was
written, otherwise the whole procedure is pretty pointless. As a side
effect, this exposes sector defects.

If you want to do this to pretend data has never been written to the
drive, you're probably out of luck anyways: If you'd be able to recover
data after a single write of zeros, it should be easily possible to see
that the data was shredded with different bit patterns. The S.M.A.R.T
counters will add the rest and tell you the power-on hours, maybe even
amount of data written, head moves etc.

(*): On an atomic scale, that's still 1 million atoms...

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file

[karl]

Walter Dnes:
...
>   This state of affairs seems to have evolved slowly.  There wasn't one
> version where it worked for nobody, immediately followed by the next
> version that worked for everybody.  Years ago, X would not run without
> an xorg.conf file.  Then X started being able to properly autoconfigure
> without an xorg.conf file for 10% of users...  then 20%... then 30%,
> etc.  Today it works for just about everybody.

No for me, I still use a serial mouse with mman protocol.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57

Re: [gentoo-user] [OT] Tools for putting HDD back to new state

[Mike Gilbert]

On Mon, Apr 3, 2017 at 2:11 PM, Harry Putnam  wrote:
> I probably should know this, but off the top of my head I don't
> remember ever running into anything like this.
>
> I'd like to do what ever is done to set a used  disk back to the
> state it was in when new... Not sure what that state is, but at least
> no evidence of boot manager or fs having been installed.
>
> This if for something I'm doing on OS openindiana (a solaris offshoot)
> and the disks are for that OS.
>
> The solaris milieu is somewhat behind linux in development of tools at
> least in my opinion.  That is why I'm asking here.
>
> I am a gentoo user as well, but expect I may have to boot the solaris
> host with one or another linux boot ISO in order to have the tools
> required.

If you are not worried about securely removing all data and simply
want to fool fdisk into thinking your drive is empty, use the wipefs
utility. This will zero-out key bytes like the MBR, partition table,
filesystem magic numbers, etc.

You'll want to run it once for each partition, and then once for the
whole device.

wipefs -a /dev/sdx1
wipefs -a /dev/sdx2
wipefs -a /dev/sdx

If you ARE worried about securely removing data, see the other replies
in this thread for better options.

Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file

[Walter Dnes]

On Sun, Apr 02, 2017 at 08:52:57PM +0300, Nikos Chantziaras wrote

> If you don't *need* an xorg.conf (and you don't, otherwise you'd know 
> :-P) then it's best to not have one.

  This state of affairs seems to have evolved slowly.  There wasn't one
version where it worked for nobody, immediately followed by the next
version that worked for everybody.  Years ago, X would not run without
an xorg.conf file.  Then X started being able to properly autoconfigure
without an xorg.conf file for 10% of users...  then 20%... then 30%,
etc.  Today it works for just about everybody.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: [OT] Tools for putting HDD back to new state

[Rich Freeman]

On Mon, Apr 3, 2017 at 2:34 PM, Kai Krakow  wrote:
>
> Just dd /dev/zero to the complete device. That purges everything you
> need: partition tables, boot sectors, contents:
>
> # dd if=/dev/zero of=/dev/sdX
>

If it contains data you'd prefer not be recoverable you might want to
use shred or ATA secure erase.

Shred overwrites the drive with random data using a few passes to make
recovery more difficult.  Some debate whether it actually adds value.

Secure erase is a standard command supported by most drives.  It has
the advantage of being MUCH faster, and it also should take care of
things like relocated blocks and such which might not be seen by the
OS.  It has the disadvantage of being a black box that might not
actually work or which might have some kind of NSA back door.
Typically it is implemented by the drive controller encrypting all
your data transparently using a random key in normal operation, and
then the secure erase command tells it to forget the key and generate
a new one.  I suspect that secure erase would probably be the closest
thing to restoring "factory" condition for a drive.

Instructions can be found at:
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Unless I'm in a hurry I tend to do the best of both worlds.  I run
shred, and then I do a secure erase.

And of course another option is to always encrypt your drives all the
time anyway, which means that even if the drive fails and you can't
erase it that your data is secure anyway.

-- 
Rich

Re: [gentoo-user] [OT] Tools for putting HDD back to new state

[tuxic]

On 04/03 02:11, Harry Putnam wrote:
> I probably should know this, but off the top of my head I don't
> remember ever running into anything like this.
> 
> I'd like to do what ever is done to set a used  disk back to the
> state it was in when new... Not sure what that state is, but at least
> no evidence of boot manager or fs having been installed.
> 
> This if for something I'm doing on OS openindiana (a solaris offshoot)
> and the disks are for that OS.
> 
> The solaris milieu is somewhat behind linux in development of tools at
> least in my opinion.  That is why I'm asking here.
> 
> I am a gentoo user as well, but expect I may have to boot the solaris
> host with one or another linux boot ISO in order to have the tools
> required. 
> 
> 

Hi,

if I understand you correctly: You want the opposite of "Total Recall"
for your harddisk...You want "to remember nothing...ignorance is
bliss" (The Matrix) in case of your harddisk.

I would suggest to 

dd if=/dev/zero of=/dev/


but!:

Vor example, your drive shows up as:

/dev/sdb
/dev/sdb1
/dev/sdb2
/dev/sdb3

you have to choose the raw device: /dev/sdb
(may be the partitions will not show up).

YOU CAN SHOOT YOUR OWN FEET-WARNING!
Be very careful here! You are acting as root here,
and choosing the wrong device will wipe the wrong 
disk instantly.

Good luck!
Cheers
Meino

PS: I will not take any responsibility for 
any command, which is not submitted by my own
hand -- and even then I will be unsure ;)

[gentoo-user] Re: [OT] Tools for putting HDD back to new state

[Kai Krakow]

Am Mon, 03 Apr 2017 14:11:40 -0400
schrieb Harry Putnam :

> I probably should know this, but off the top of my head I don't
> remember ever running into anything like this.
> 
> I'd like to do what ever is done to set a used  disk back to the
> state it was in when new... Not sure what that state is, but at least
> no evidence of boot manager or fs having been installed.
> 
> This if for something I'm doing on OS openindiana (a solaris offshoot)
> and the disks are for that OS.
> 
> The solaris milieu is somewhat behind linux in development of tools at
> least in my opinion.  That is why I'm asking here.
> 
> I am a gentoo user as well, but expect I may have to boot the solaris
> host with one or another linux boot ISO in order to have the tools
> required. 

Just dd /dev/zero to the complete device. That purges everything you
need: partition tables, boot sectors, contents:

# dd if=/dev/zero of=/dev/sdX

where sdX is the disk to "kill". Be sure not to purge just on partition
by saying sdX1 or so but the complete disk (without number). Then,
before running any partitioning software, reboot, so the partition
cache of the kernel becomes cleared, or run part-probe if it is
installed.

dd should also be available in solaris but I guess the whole-disk
devices are named differently.

A faster alternative may be ddrescue. You could also give dd bigger
block sizes:

# dd ... bs=1M

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] [OT] Tools for putting HDD back to new state

[Harry Putnam]

I probably should know this, but off the top of my head I don't
remember ever running into anything like this.

I'd like to do what ever is done to set a used  disk back to the
state it was in when new... Not sure what that state is, but at least
no evidence of boot manager or fs having been installed.

This if for something I'm doing on OS openindiana (a solaris offshoot)
and the disks are for that OS.

The solaris milieu is somewhat behind linux in development of tools at
least in my opinion.  That is why I'm asking here.

I am a gentoo user as well, but expect I may have to boot the solaris
host with one or another linux boot ISO in order to have the tools
required. 

[gentoo-user] Re: VIDEO_CARDS= apparently ignored and new pkgs assigned

[Kai Krakow]

Am Thu, 02 Mar 2017 00:07:50 -0500
schrieb Harry Putnam :

> Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
>  Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram
> 
> I'm having a situation where way too many packages are coming up
> needing rebuilt during emerge world.
> 
> Decided to see what `emerge @preserved-rebuild would bring me.
> 
> ran `emerge -va @preserved-rebuild' and I notice that it appears my
> setting in /etc/portage/make.conf for VIDEO_CARDS="virtualbox" is
> being ignored... the output of above command shows:
> 
>   Calculating dependencies... done!
>   
>   [ebuild R ] x11-libs/libdrm-2.4.75::gentoo USE="-libkms -static-libs
>  -valgrind" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="amdgpu*
> nouveau* radeon* (-exynos) (-freedreno) -intel (-omap) (-tegra) (-vc4)
>  (-vivante) -vmware" 0 KiB
>   
>   [ebuild   R] mail-mta/sendmail-8.14.9-r1::gentoo  USE="mbox ssl
>   tcpd -ipv6 -ldap -libressl -nis -sasl -sockets" 0 KiB
>   
>   [ebuild   R] x11-drivers/xf86-video-amdgpu-1.2.0::gentoo
> USE="-glamor" 0 KiB [ebuild   R]
> x11-drivers/xf86-video-ati-7.8.0::gentoo  USE="glamor -udev" 0 KiB
> [ebuild   R] x11-drivers/xf86-video-nouveau-1.0.13::gentoo  0 KiB
> 
> Note how VIDEO_CARDS="amdgpu* nouveau* radeon* [...]"
> is being assigned.
> 
> And the already installed (probably unneeded pkgs are being
> reinstalled)
> 
> I considered ummerging those pkgs but checked `qdepends' on them and
> that swears they are required by xorg-server not to mention this whole
> string of other pkgs:
> 
>  qdepends x11-drivers/xf86-video-nouveau
> 
> x11-drivers/xf86-video-nouveau-1.0.13:
> >=x11-libs/libdrm-2.4.60[video_cards_nouveau]
> >=x11-libs/libpciaccess-0.10 ! >=sys-devel/automake-1.15:1.15 >=sys-devel/autoconf-2.69
> >=sys-devel/libtool-2.4 virtual/pkgconfig x11-proto/xf86driproto  
> x11-proto/glproto x11-proto/dri2proto x11-proto/fontsproto
> x11-proto/randrproto x11-proto/renderproto x11-proto/videoproto
> x11-proto/xextproto x11-proto/xineramaproto x11-proto/xproto
> x11-base/xorg-server[-minimal] x11-libs/libdrm
> x11-base/xorg-server[xorg] x11-libs/libpciaccess
> 
> The other pkgs get similar output
> 
> This was not the first time I checked qdepends on this.
> 
> I did notice back when some of those driver pkgs were initially
> installed and wondered then why I needed them... I checked then with
> qdepends too and found that they are required by xorg-server and a
> similar string of other pkgs as shown above for each.
> 
> Can anyone say what is going on here...?  Is this normal?
> Should I really be needing drivers for ati, nouveau etc?
> Any ideas about what needs to be done if anything?

Please paste your complete make.conf and emerge --info.

-- 
Regards,
Kai

Replies to list-only preferred.