@FarhanKarim Have you tries this : edwiget.name/2011/05/backtrack-5 part "Fix prepare-kernel-sources" ?

@Gilles is it just me, or does is unix.stackexchange.com/questions/83457/… already in the 12th inning...

@derobert at least the guy has a genuine problem and is following up on requests in comments

but it is the sort of thing where it helps a lot to be in front of the machine

Yes. Its just not a case where the SE software works so well for. Tempted to try to get him into chat, but I think we're all in much different time zones.

I am most definitely not going to confuse the issue by pointing out that you can get at data by using a loop mount with an offset.

any help??

@derobert I am just learning. If I am "abusing" the platform, let me please know. I can summarise, shorten things. Thanks, Nikos

@derobert Hi! It certainly would be better to chat rather than to fill up the comments. I am available (almost) anytime requested. Thanks.

@NikosAlexandris No, you're not abusing it, it's just a weakness in the platform...

@derobert Thanks. I consider the Q&A as of the most advanced platform out there. So, re-syncing completed. I can't find a clear description (from what I read and understand of course) of what exactly --update=resync does. I guess it does the right thing, though, I might have misfired again: I did not zeroed the superblocks before re-assembling.

If it did a full sync, it should be fine

@derobert I am trying to identify the erroneous number the Gilles spoted, so as to compare with the current status.

Not sure what's going on with the different block count, Funtoo must have done something weird.

But the array itself seems fine, since mdadm will assemble it after boot.

I'm trying to install a Funtoo VM here to quickly test, but, well, installing Funtoo is not quick.

Even on a fast i7.

its still working on "emerge debian-sources", and has been for a while

:D No, Funtoo is real Fun (though)!

I mean, it's been doing that for longer than the entire Debian install on the host machine took, but... :-P

So, it seems ok now: mdadm -E /dev/sde1 reports "Array Size : 1953382208 (1862.89 GiB 2000.26 GB)" and cat /proc/mdstat reads "md0 : active raid1 sde1[3] sdc1[2]" and, next line "1953382208 blocks super 1.2 [2/2] [UU]".

My only experiences with Gentoo and derivatives before has been helping a coworker fix his Gentoo install each time it broke. We did find a permanent fix for it eventually, we installed Debian.

@NikosAlexandris have you given that update-initramfs a try?

@derobert :D Oh, no. I am not abandoning Funtoo. Not that easy. I waited 2 days to learn and get a working system. But it is so solid...

I am doing it now...

Ehm.. heck, I might need to emerge it (or the package that includes it) or it is called something else in Gentoo/Funtoo!

no, if you don't have it, you don't need it

A-ha.

do you know if you're using an initial ramfs?

What other double-checks can I perform?

It sure looks healthy from the mdadm perspective.

@derobert I think yes, I've seen a couple of references on the web and in the funtoo.forums. As well, as I can see stuff related to mdadm in the file /usr/share/genkernel/gen_initramfs.sh

But I don't know it (exactly)!

you can check your bootloader config...

See if it has initrd lines (if you're using grub)

hmm... I can see there is bootlogd -- useful for after (re-)booting I guess.

you can check if you have a /var/log/boot

I am not familiar with the boot-loader in Funtoo. I need to go step by step.

No there are not.

I did already!

Grub config is probably in /boot/grub/grub.cfg

Hem... ok, there is /etc/boot.conf

But I can't locate any grub.conf except for the sample file

Did you install by following this guide? funtoo.org/wiki/Funtoo_Linux_Installation

Yes.

boot-update? Irrelevant, right?

that just got spit out from my vm... I wonder what that domdadm argument does.

Me too!

Didn't see any reference to it elsewhere in the Funtoo wiki.

Here <http://forums.gentoo.org/viewtopic-t-775025-start-0.html> in the kernel line

That answer looks suspicious. "line raid autodetect" isn't recommended (check the mdadm manpage, for example)

Here as well <http://forums.gentoo.org/viewtopic-t-775025-start-0.html>

Oh man, a bit complicated!

"Note: With latest genkernel, you should pass domdadm option to kernel. In case if busybox can't find /etc/mdadm.conf, it will try to autodetect arrays." from <http://en.gentoo-wiki.com/wiki/Software_RAID_Install>

Worth a try, I guess.

I haven't been able to figure out how you tell it to regenerate the initramfs

my vm is now emerging boot-update

Ok, I found /boot/grub/grub.cfg

locate didn't look into /boot I guess (?)

So, I might only need to add it there? i.e. as per (yet another Gentoo-Wiki page) <http://en.gentoo-wiki.com/wiki/RAID/Software>:

GRUB_CMDLINE_LINUX_DEFAULT="dolvm domdadm"

Well, I only need the latter.

you can just hit edit in grub to test it

ok, I am going for it.

install finished

WoW! That was a quick installation!

it didn't boot, though

apparently it built an initramfs w/o virtio...

Hmm...

I am not yet sure as to where I should add the line

there is no simple 'grub' command, if you mean that.

when you boot up, you get a grub menu, which lists the kernels you can boot

press e instead of enter

aaaa, right!

ok

The I am rebooting!

It goes on the linux line, just put it at the end

O-K. Will be back... I did thank you for your time, didn't I? Well, if there is another way than inexpensive thank yous, let me know what I can do.

It doesn't play nice!

Again, some disk missing.

did you spot anything in the boot messages?

anything mentioning md or mdadm or raid?

No, too fast. The only error is that some local filesystem(s) didn't mount

And now, manually... gets to "Assembly, now, doesn't find both disks."

I can access the data of course.

Hmmm. I have in /etc/fstab:

/dev/md0 geo xfs defaults 0 2

The system said, however, before assembling manually that there is no md0

hmmm, what if you change /dev/md/0 to /dev/md0 in your /etc/mdadm/mdadm.conf ?

That was my idea -- but I thought it's simply silly.

(still trying to get my VM to boot. Apparently the option labeled "include all modules" didn't actually mean all modules...)

Sorry that I can't be of any help.

Should I restart the md0 after altering mdadm.conf?

you can stop and start it, I'm pretty sure it'll still work.

real question is if that makes it work on bootup

Right, I am just slightly worried because this time...

mdadm --assemble -v --scan

ends up with

mdadm: /dev/md/0 has been started with 1 drive (out of 2).

did it say why it didn't add the other drive?

mdadm: /dev/sdc1 is busy - skipping

did you do mdadm --stop /dev/md0 first?

Yes, I stopped it.

or whatever raid device showed in /proc/mdstat

Let me check the history.

busy means its part of a currently-assembled raid array

1st thing I did before anything else after boot:

oh, 127? It's confused itself

yeah, changing /dev/md/0 to /dev/md0 should help with that.

Perfect! :-)

I changed it.

do a mdadm --stop /dev/md127

a-ha...

...

what does /proc/mdstat show now?

Ehm, I stopped it.

assemble it again, leave it assembled. We're going to have to add that disk back.

it should assemble with 1 drive out of the 2.

...

yes, now does it show up in /proc/mdstat?

yes

ok, and it shows with only sde1?

yes

ok, try mdadm -a /dev/md0 /dev/sdc1

ehmm

it's recovering...

are we sure it's opl

are we sure it's ok?

When the array got assembled with only one disk a minute ago, that one disk became more "recent" than the other

Shouldn't the sdc1 be the source?

So it's rebuilding to fix that.

That's not very good.

Well, they contain the same data. It doesn't matter which is the source.

I am not sure that sde1 is the "latest". For testing I did add some files in sdc1, mounted of course ad /md/0

Bad thing?

but you let it rebuild after that, right?

Yes, I did I think the complete --update=resync. It took 3 hours+

I am still not sure though... just worried.

Yeah. That copied all the data from one disk to the other.

You can go ahead and mount it—you don't have to wait for the rebuild

Can't we reverse this?

I mean the "date"?

Well, it's already started copying...

As far as I can remember, all is there.

if you want to pause it, echo 0 > /proc/sys/dev/raid/speed_limit_max

I do have a lot of stuff there of course...

if you pause it, you can look around

paused

looking...

echo 200000 to that file to resume the sync

(well, any number you want, 200000 is the default, I believe)

ok

All seems fine.

Another sync? Well, recovery...

I need a break...

I hope someone will reply in the funto.forums as well.

I will come back after the recovery... !

Make sure you unpaused it, and check /proc/mdstat to confirm its going again

Just another question: does copying data when md is active, apply to both sdc1 and sde1 at the same time?

Yes, it works

I am watch -d cat /proc/mdstat

  [>....................]  recovery =  4.2% (83603200/1953382208) finish=168.1min speed=185341K/sec

@NikosAlexandris Yes, as long as you do it through /dev/md0

ok, no need to worry then.

Phew!

Once /proc/mdstat says the sync is done, the disks will have the same data. Even if you modify it during the sync

You can use the array while its syncing.

Hem... well let's see. Interesting story...

I am going out of desk for a while. Catch some fresh air.

You are pretty close to that 200k number, echoing a higher number (say, 400000) to the file might speed it up some

I'll try to pop back into chat later.

thanks.

I give up on this VM :-(

Anyway, BBL.

@derobert Sorry :-/

The recover process completed. Successfully I guess. To re-boot or not... is the question :-)

I see a short set of in structions over at <http://www.funtoo.org/wiki/Rootfs_over_encrypted_lvm_over_raid-1_on_GPT#Encrypting_the_raid-1>

No offense, but where should this set of instructions be added for enabling the activation of RAID during the boot process?

The Wiki-page is, imho, not clean.