Re: [DNG] pressed root pw

[Peter Maloney]

On 10/23/2015 10:44 PM, Peter Maloney wrote:
> Not sure that's really right either... maybe it corrects the error for
> you though.
>
> The easiest way to make a proper crypted password is either to use
> usermod, passwd, as normal and then copy from /etc/shadow, or use
> mkpasswd.
>
> Here's a proper example with salt and a proper algorithm:
> # mkpasswd -m SHA-256 -s <<< "hi"
> $5$aiIZoKuCb81Ki$tBcSFQfyetVkJ03TXX5ftw/XJD27Qt5pTABGz7gdUM/
>
> Here is the obsolete insecure md5 algorithm as you have used before.
> You can see here the "$1$..." means it is md5, and is the proper way
> to format it unlike in the simple output you have with " | md5sum"
> used.
> # mkpasswd -m md5 -s <<< "hi"
> $1$SFSi8luS$jzco491ys2fylaH8ILLpC.
>
> See man 3 crypt for the details on the format and what it all means.
>
> To install mkpasswd, install the "whois" package.
>
Just in case someone reading needs more info...

In my examples "hi" was the password.

Without a salt, a cracker can crack your hash in an instant using a
rainbow table. Without a rainbow table, an md5sum can be cracked in a
short time, but an sha256 would take much longer; if you have a computer
with 4 high end dual slot double GPUs to do the cracking, maybe it takes
a few weeks.

Also I recommend using a temporary password and changing it after you
use preseed since you probably aren't storing your preseed file securely
anyway... pxe stuff uses tftp and http which doesn't encrypt anything.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] pressed root pw

[Peter Maloney]

Not sure that's really right either... maybe it corrects the error for
you though.

The easiest way to make a proper crypted password is either to use
usermod, passwd, as normal and then copy from /etc/shadow, or use mkpasswd.

Here's a proper example with salt and a proper algorithm:
# mkpasswd -m SHA-256 -s <<< "hi"
$5$aiIZoKuCb81Ki$tBcSFQfyetVkJ03TXX5ftw/XJD27Qt5pTABGz7gdUM/

Here is the obsolete insecure md5 algorithm as you have used before. You
can see here the "$1$..." means it is md5, and is the proper way to
format it unlike in the simple output you have with " | md5sum" used.
# mkpasswd -m md5 -s <<< "hi"
$1$SFSi8luS$jzco491ys2fylaH8ILLpC.

See man 3 crypt for the details on the format and what it all means.

To install mkpasswd, install the "whois" package.

On 10/23/2015 09:38 PM, aitor_czr wrote:
> Yes... you are right, Klaus.
>
> El 23/10/15 09:20, Klaus Hartnegg   escribió:
>> Maybe you need instead this
>>
>> echo -n "XX" | md5sum
>> c0a7ae7d513f4beb2bc203d6f339f1b5  -
>

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd in the era of hotplugable devices

[Peter Maloney]

On 07/22/2015 10:41 PM, Laurent Bercot wrote:
>  OT: I would like it if the list host could set the "Mailing-List:"
> header on list messages. Most MUAs understand it and implement a
> "reply to list" feature; without it, we're stuck with manual
> configuration
> or hitting "reply to all", which causes duplicates.
>
What's wrong with these, which Thunderbird handles just fine?

List-Id: "The first mailinglist after debianfork.org" 
List-Unsubscribe: , 
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
 


The only thing that bugs me about this list is how many messages
apparently bounce, so it leaves gaps in threads that I never see, and I
keep having to click a resubscribe link after some number of bounces so
it decides I shouldn't get mail any more.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed defaults changes

[Peter Maloney]

On 07/15/2015 09:52 AM, Peter Olson wrote:
>> On July 15, 2015 at 3:35 AM Didier Kryn  wrote:
>>
>> Le 15/07/2015 04:16, Go Linux a écrit :
>>> I never could figure out vim but can find my way around nano.  :)
>>>
>>> golinux
>>>
>>  Same for me. Was never able to make the slightest change to a file 
>> with vi :-(
> I have made horrendous changes with vi, quite simply, which had to be repaired
> by source code control :-) :-(
>
> Well, I probably could have done that with any other of multiple editors.
>
> Peter Olson
just run "vimtutor" and do what it says... it's only difficult if you
don't know the buttons.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] excessive bounces nuissance - was Re: Testing - Please ignore and delete this email

[Peter Maloney]

Mine also does this, constantly, and annoyingly. And many messages don't
show properly in thread view because many in between are missing, so
thunderbird can't join them in a tree view, which is mostly what annoys
me. I had this email address on many lists before without an issue, but
I assumed it was only me and didn't report it.

On 07/05/2015 10:49 PM, Anto wrote:
> This is just a test message as my membership was disableddue to
> excessive bounces. I am not sure why that happened.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] How to bust into a broken Qemu VM?

[Peter Maloney]

On 05/16/2015 01:49 PM, Brad Campbell wrote:
> On 16/05/15 15:37, Peter Maloney wrote:
>> On 05/16/2015 02:00 AM, Adam Borowski wrote:
>>> On Fri, May 15, 2015 at 07:37:57PM -0400, Steve Litt wrote:
>>>> When you accidentally bork a Qemu VM such that it won't boot to a
>>>> virtual terminal, how do you bust back in. I doubt System Rescue CD
>>>> would help, unless you can boot from the "cdrom" but somehow also
>>>> access the existing "hard disk" borked VM image.
>>> Well... you use the exact same arguments as you used for installing the
>>> system in the first place.  That is, give qemu both the hard disk
>>> image and
>>> the CD.  Then -boot d to boot from the first attached CD.
>>>
>> Or you can have more fun and mount it on the host...
>>
>>
>> losetup /dev/loop0 disk1.img
>
> With the caveat that only works for RAW format images though.
>
>
> Brad
You can use nmbd or some other qemu thing instead of losetup to use
qcow2 and other images though. (at the cost of performance)

Here is the nmbd method:
modprobe nbd
   
qemu-nbd -b 127.0.0.1 devuan_disk1.qcow2
(let it chill or nohup / bg it / whatever)
lsof -Pni | grep nbd
figure out which port it listens on (in my case 10809)
nbd-client localhost 10809 /dev/nbd0

kpartx -av /dev/nbd0
...

This method is also useful for combining with CoW so you can have a rw
image plus a ro image that you can use together, eg. to do some
experiment that might destroy your original otherwise.
qemu-img create -b basedisk.qcow2 -f qcow2 rwdisk.qcow2
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] How to bust into a broken Qemu VM?

[Peter Maloney]

On 05/16/2015 02:00 AM, Adam Borowski wrote:
> On Fri, May 15, 2015 at 07:37:57PM -0400, Steve Litt wrote:
>> When you accidentally bork a Qemu VM such that it won't boot to a
>> virtual terminal, how do you bust back in. I doubt System Rescue CD
>> would help, unless you can boot from the "cdrom" but somehow also
>> access the existing "hard disk" borked VM image.
> Well... you use the exact same arguments as you used for installing the
> system in the first place.  That is, give qemu both the hard disk image and
> the CD.  Then -boot d to boot from the first attached CD.
>
Or you can have more fun and mount it on the host...


losetup /dev/loop0 disk1.img
kpartx -av /dev/loop0
Konsole output
Output looks something like:
Konsole output
add map loop0p1 (253:27): 0 9949184 linear /dev/loop0 2048
add map loop0p2 (253:28): 0 2 linear /dev/loop0 9953278
add map loop0p5 : 0 530432 linear /dev/loop0 9953280

Now you know that /dev/dm-27 and /dev/dm-28 are your partitions. Also
there is /dev/mapper/loop0p1 and p2 which are symlinks to those.

Then mount and chroot to fix whatever you want.

#if there was lvm in there, (sometimes) you also need:
#vgchange -an vgname
#vgchange -ay vgname

mount /dev/dm-28 /mnt/test
mount /dev/dm-27 /mnt/test/boot
for d in dev proc sys; do
mount -obind /"$d" /mnt/test/"$d"
done
chroot /mnt/test


Then do some things to fix it... like fix fstab:

blkid
vim /etc/fstab

And refresh the bootloader and related:

grub-install /dev/loop0
update-initramfs -u
update-grub


you can also use apt-get as long as resolv.conf is right.

Then exit and clean up.

exit or ctrl+d  (logout of chroot)


umount /mnt/test/*
umount /mnt/test

#if there was lvm there, also:
#vgchange -an vgname

kpartx -d /dev/loop0
losetup -d /dev/loop0



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A novice attempt to speed up Devuan development

[Peter Maloney]

On 05/05/2015 08:55 AM, Anto wrote:
>
>>
>
> Just FYI. I just noticed that the changes that I have made seem to
> break udev. It was not started after reboot- I have not investigate
> further, but re-installing udev solve the problem. It seems that I
> have to re-compile udev as well. But it looks more complicated as udev
> *is* in systemd source.
>
Try eudev, which is a drop in replacement for udev on openrc systems,
and I think it was forked from udev before systemd got it.

https://github.com/gentoo/eudev
or maybe this
https://aur.archlinux.org/packages/eudev/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Newbie questions re installing a devuan image

[Peter Maloney]

On 04/28/2015 12:07 AM, Dragan FOSS wrote:
> On 04/27/15 11:37 PM, Steve Litt wrote:
>> OpenRC edition was astounding.
>

looks great :)  (I am currently using Manjaro-openrc)

Do you have any instructions on setting it up in English? I tried
looking and only found serbian.


> [root@trios][/home/dragan/Desktop]# zpool status
>> no pools available
>
>
> Cheers :)
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Two more reasons for Devuan

[Peter Maloney]

On 04/23/2015 06:48 PM, Peter Maloney wrote:
> On 04/23/2015 12:01 AM, John Morris wrote:
>> On Tue, 2015-04-21 at 12:06 +0200, Martin Steigerwald wrote:
>>> Hi!
>>>
>>> Here are two more reasons for Devuan:
>> I'd just say more signs that systemd was pushed into production way
>> early and not new objections to the (widely held to be defective in the
>> opinion here) design principles themselves.
> Are you sure about that? ;)
>
> http://imagebin.ca/v/1vU2MeBPkzJC
>
By the way, the system has nothing really special... I think it's just
the default install, then an update. So why should there be any issue
with mounting filesystems? And so I booted to that. And sshd was
working, nagios worked fine, etc. so it was not single user mode as you
would expect from maintenence mode. And ctrl+d rebooted the system :D
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Two more reasons for Devuan

[Peter Maloney]

On 04/23/2015 12:01 AM, John Morris wrote:
> On Tue, 2015-04-21 at 12:06 +0200, Martin Steigerwald wrote:
>> Hi!
>>
>> Here are two more reasons for Devuan:
> I'd just say more signs that systemd was pushed into production way
> early and not new objections to the (widely held to be defective in the
> opinion here) design principles themselves.
Are you sure about that? ;)

http://imagebin.ca/v/1vU2MeBPkzJC

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [OT]I have been liberated!

[Peter Maloney]

On 04/06/2015 06:10 AM, Neo Futur wrote: I certainly would not
>> put it on server without serious thought, but I do not think that I would be 
>> overly concerned about it on
>> the desktop.
>  Same here I accept it on my mageia laptop, i dont really care the nsa
> knowing everything of me ( they already have
> http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/
> ) , but, for the sake of my customers,  I will never ever accept this
> on the dedicated servers I'm paid to manage by customers trusting me.
>
>
>
If you manage those servers from your desktop, then from a security
perspective, that desktop is a single point of failure. If there was a
keylogger on there, plus someone could read your private keys, how safe
would your server infrastructure be?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] donating funds...

[Peter Maloney]

FYI flattr takes 10% of the donation

not saying it's a problem necessarily, but I found that rate alarming,
so just letting you know

On 03/13/2015 02:47 AM, Derek Shaw wrote:
> I was just reminded of this as I topped up my flattr account for the
> quarter.
>
> Any way you can start using flattr for donations?  It would make it a
> lot easier for me to plug you in to the system I already use to send
> money every month to The Document Foundation (makers of LibreOffice). 
>
> https://flattr.com/
>
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greets

[Peter Maloney]

On 03/10/2015 05:32 PM, hellekin wrote:
> On 03/10/15 11:57, Steve Litt wrote:
>>> I agree with you that Devuan governance needs to differ from Debian's,
>>> and that is must consider the general interest as well as respect the
>>> particular.
>>
>> LOL
>>
> *** Can you expand the acronym?  I'm not sure I find anything funny here.
>
> ==
> hk
>
Irony is a form of humor... and it is ironic that the most democratic
freedom (to vote away the principles) results in the most non-free end
result (total lock in and ignoring users). It would be funnier if it
wasn't pathetic.

Democracy is a very delicate system, and a constitution with missing
points, or that can be changed later by a future corrupt government,
doesn't solve it completely.

So to address the missing points, the draft says "9.10 Software must not
encourage lock-in", which is exactly what we were missing, and I'm happy
to see that there... but there is always something else we can't predict
that is also missing. I was hoping to see some insight in there, for
example in the "4. Decision-making bodies and individuals" section. And
especially hope it doesn't say anything like "anyone can join en masse
and override all the decisions completely overnight".
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] with pax flags, Java works fine - (was Hardened Devuan)

[Peter Maloney]

On 03/08/2015 08:25 AM, Neo Futur wrote:
>> cool, thanks! I think it would be important that packages that have an issue
>> running under grsec all do what they need to do on installation to make sure
>> the correct configs are in place to actually work under grsec. This is often
>> left out, making proper security expensive and difficult to track down.
>  lets be clear, you d have to check for each and every new version of
> each and every binary you ship to add this "allowed to skack exec or
> whatever other dirty memory trick"  flag whenever the upstream added a
> bug or a backdoor.
>
>  quite a bunch of work, imo this have to be the responsibility of the
> sysadmin to see the problem ( easy in the grsec log whenever something
> goes wrong ) and choose to allow/trust this binary, and / or report a
> bug to devuan and/or upstream.
It's not much work... I just stick those setfattr commands in a script
and run it each time I run system updates (but I wish there was some
"post update hooks" thing I could put it, so also unattended-upgrades or
similar will also set the flags). And on a server, it's pretty much just
java and maybe python that have issues (and the grub one is somehow
debian only). Mostly everything else I had to set flags on was on my
desktops.
>  also automatically adding this flag everywhere completely defeats the
> purpose of those security patches, you just say "wow this program have
> a backdoor, cool its allowed, dont even log that" to your grsec
> kernel, why not ship a grsec kernel with no security options enabled
> then ? or just use vanilla 
It certainly opens some holes, but they're much smaller issues than
having a vanilla kernel. For example try paxtest to see how open a
vanilla kernel is, and then try grsec, and then try grsec with the flags
set on the paxtest binary and shared objects,  and it's barely worse

And people in the grsec irc channel assure me that even though setting
all the flags on a binary opens up buffer overflow, etc. exploits to the
userland application, it still protects the kernel fully (no flags to
set there) and so the damage that application can do is limited to just
userspace; with apparmor or something confining the application, then
the damage is nearly nothing... eg. firefox can add addons, bookmarks,
connect to web pages, download files (my firefox profile doesn't let it
do anything else, just save files in one dir), etc. and then if it's
corrupted I can just remove my config (~/.mozilla/profiles/...), and it
can't affect the rest of the system.

And the biggest fear when using LSM or other mandatory access control
(MAC) is kernel exploits... if someone can execute code running in the
kernel, they can easily bypass MAC. So it's a huge improvement even with
the flags set.

>
>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] with pax flags, Java works fine - (was Hardened Devuan)

[Peter Maloney]

Just to clarify... *Java will run* with a grsecurity hardened kernel,
with pax enabled. It just needs mprotect disabled for the specific
programs that need it disabled. (and also many other things need this...
python, kdeinit4, skype, kscreenlocker_greet, thunderbird, firefox,
plugin-container, gdb, utox, grub-probe, etc. also firefox needs JIT
disabled for optimal stability). For this you need some kernel features
enabled; I recommend the one using xattrs because then the binaries
don't need modifications (or backups, and modified binaries won't run
properly in a non-grsec kernel, but they run fine with xattrs).

Set the extended file system attribute with:

setfattr -n user.pax.flags -v m Konsole output
/usr/lib*/jvm/java-*-openjdk-*/jre/bin/java

(example path, may not be right for Debian openjdk)

I have been running grsecurity kernels on my desktop at home and the
office for about a year now, with Java and everything in use.

Also, you can set pax to "soft mode" to temporarily disable those
protections.

And the kernel buffer displays errors when such things are needed, so it
is easy enough to identify why a program doesn't work, to enable those
flags:

[  477.346273] PAX: From 192.168.179.200: execution attempt in: ,
3cc7c968000-3cc7c989000 3fde000
[  477.346451] PAX: terminating task:
/usr/bin/grub-script-check(grub-script-che):7163, uid/euid: 0/0, PC:
03cc7c987cf0, SP: 03cc7c986698
[  477.346631] PAX: bytes at PC: 41 bb 30 27 40 00 49 ba e0 7c 98 7c cc
03 00 00 49 ff e3 90
[  477.346784] PAX: bytes at SP-8: 044d68d0 00404011
0001  044d6850 044d68d0
044d68d1 044d8911 044d8910 00405ca6
0002



On 03/07/2015 12:31 PM, Martijn Dekkers wrote:
> I am not sure I follow - is the plan for Devuan to be default
> hardened/grsec, or is it supposed to be an optional choice somehow? As
> was already pointed out, java won't run. Lots and lots of server
> workloads run Java
>
> On 7 March 2015 at 12:42, Jaromil  > wrote:
>
>
> dear Neo Futur and other members of the Devuan hardening team:
>
> please consider the Alpha release series a minimal base you can use to
> start working on the kernel patches, building them and testing them.
> In fact, this release series is mostly intended to receive
> feedback from
> developers and adjust to their needs.
>
> Please also let me know what is the format you prefer working on.
> Right
> now I can release virtualbox images and vagrant boxes using the
> SDK but
> I can also add support for Docker, Qemu, AWS, Google engine,
> DigitalOcean, OpenStack, Parallels etc.
>
> In a close future Devuan's signed releases will be available in all
> these formats, hoping they come handy to the sysadmins among our
> audience. I'm just trying to figure out what to prioritize now in
> order
> to facilitate your good plans.
>
> ciao
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org 
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] btrfs repair works fine, Lennart has no idea what he is talking about - was OT - It may be only one file, but it does point to the bigger problem!

[Peter Maloney]

On 02/22/2015 07:28 PM, Jim Murphy wrote:
> [...]
> Part of the discussion:
>
>>> btrfs checksumming theoretically allows you to transparently recover
>>> after media corruption if filesystem has redundancy (more than one
>>> copy of data). Journald checksum will probably detect corruption, but
>>> can it repair it?
>>>
>> No it cannot.
>> But btrfs checksumming cannot fix things for you either if you lose
>> non-trivial amounts of data. It might be able to fix a few bits of
>> errors, but not non-trivial amounts. I mean, that's a simple property
>> of error correction codes: the more you want to be able to correct the
>> longer must your checksum be. Neither btrfs' nor journald's are
>> substantial enough to correct even a sector...
>>
>> Lennart
>

This is pure ignorance. It does not require the redundancy provided by
the CRC algorithm to recover the data; it uses the checksum just to find
out if the copy is good, and uses redundancy provided by raid to repair
it. (which is simply what Lennart's victim already said by adding
context with "if filesystem has redundancy" and "more than one copy of
data", which is not the CRC). The checksum doesn't need to be longer to
repair it, only to prevent collision. The chance of a collision is
something like one in 2^32 = 4 billion. (< 1 in 512 :P)

Test this out simply by making a raid1, filling it with data, then run 2
things in infinite loops. One to repeat scrubs, and one to write random
data to the disks, not just a few bits.

Here's 30 minutes of the test script (kernel 3.18.x, btrfs tools version
3.18.2):

Konsole output Konsole output
WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:07:34 2015 and finished after 159
seconds
   total bytes scrubbed: 13.20GiB with 120 errors
   error details: csum=120
   corrected errors: 120, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14152)

WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:10:14 2015 and finished after 144
seconds
   total bytes scrubbed: 13.20GiB with 14 errors
   error details: csum=14
   corrected errors: 14, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14275)

WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:12:44 2015 and finished after 139
seconds
   total bytes scrubbed: 13.20GiB with 80 errors
   error details: csum=80
   corrected errors: 80, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14377)

WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:15:04 2015 and finished after 168
seconds
   total bytes scrubbed: 13.20GiB with 14 errors
   error details: csum=14
   corrected errors: 14, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14505)

WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:17:54 2015 and finished after 163
seconds
   total bytes scrubbed: 13.20GiB with 110 errors
   error details: csum=110
   corrected errors: 110, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14595)

WARNING: errors detected during scrubbing, corrected.
scrub status for af936534-6c3f-4136-809a-740a32a65591
   scrub started at Fri Feb 27 15:20:44 2015 and finished after 173
seconds
   total bytes scrubbed: 13.20GiB with 53 errors
   error details: csum=53
   corrected errors: 53, uncorrectable errors: 0, unverified errors: 0
scrub started on /mnt/test, fsid af936534-6c3f-4136-809a-740a32a65591
(pid=14737)



Obviously there is a chance for both copies to be destroyed at the same
time... but it isn't all that likely in 20 minutes, even with such high
destruction rate. But clearly this disproves Lennart's unfounded
statement, saying a single sector cannot be repaired. Here's 391 blocks
so far, which I assume is more than 391 sectors. Clearing cache and then
doing a diff on the test files compared to the original copy shows that
they are undamaged. (this means you can cp the files away without any
loss, but maybe there are bugs that will make btrfs die later :P it's
not exactly fully production ready)

So change "theoretically" in the above email to "in practice".


And the test script:





# variables used in many parts of the script

disk1=/dev/data/btrfs1
disk2=/dev/da

Re: [Dng] Important changes in Linux 3.20 (4.0?)

[Peter Maloney]

On 02/15/2015 05:40 PM, Hendrik Boom wrote:
> On Sun, Feb 15, 2015 at 10:26:01AM -0500, Gravis wrote:
>>> Kernel live patching makes KDBUS and systemD support mandatory!
That would make it a circular dependency... and circular dependencies
always kill themselves. :)

Also, it (hopefully) won't depend on systemd-udev, systemd-logind, etc.
only some interface that you can clone somewhere else. The big problem
is that the interface is not standard, modular, or community driven; I
expect it won't kill other inits unless the maintainers are lazy.
>> i'm weary of KDBUS but live patching is something i consider too dangerous.
>> --Gravis
> But why would it have to depend on systemd?
>
> -- hendrik
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng