Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. WKR Hinnerk signature.asc Description: Digital signature
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
on 08/24/2014 10:43 PM Alon Bar-Lev wrote the following: before you install everything, try to boot from installcd, extract stage3 over your rootfs, Wouldn't that also override his /var/lib/portage/world file? chroot to rootfs, then: # emerge --emptytree @world
Re: [gentoo-user] Execute udev rule before net.* scripts
On Sun, Aug 24, 2014 at 1:05 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 24/08/14 20:05, Tom H wrote: On Sun, Aug 24, 2014 at 8:59 AM, Grant emailgr...@gmail.com wrote: SUBSYSTEM==net, KERNEL==enp3s0u1, NAME=net0 enp3s0u1 isn't a kernel name; it's an ID_NET_NAME_PATH attribute. That's what came to my mind too, that's why I instructed him away from it. Yeah, I saw your email after I sent mine. I now have to figure out why you're recommending a 80 prefix when I thought that a 80 prefix is necessary in order AFAIK to override /lib/udev/rules.d/80-net-setup-link.rules. I tried 75- instead of 85- this morning before leaving for work and the interfaces were renamed properly so I'm clearly wrong...
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On 25/08/2014 08:17, Hinnerk van Bruinehsen wrote: On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. gcc is also in /usr which happily guarantees that nothing can be fixed without unpacking a stage first -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
Alan McKinnon wrote: On 25/08/2014 08:17, Hinnerk van Bruinehsen wrote: On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. gcc is also in /usr which happily guarantees that nothing can be fixed without unpacking a stage first It seems moving so much critical stuff to /usr was a really bright move. lots of sarcasm there Dale :-) :-)
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On 25/08/2014 11:11, Dale wrote: Alan McKinnon wrote: On 25/08/2014 08:17, Hinnerk van Bruinehsen wrote: On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. gcc is also in /usr which happily guarantees that nothing can be fixed without unpacking a stage first It seems moving so much critical stuff to /usr was a really bright move. lots of sarcasm there and, rm -rf /usr is not a user error one can reasonably expect to recover from -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Software RAID-1
On Sunday 24 August 2014 19:22:40 Kerin Millar wrote: On 24/08/2014 14:51, Peter Humphrey wrote: ---8 So I decided to clean up /etc/mdadm.conf by adding these lines: DEVICE /dev/sda* /dev/sdb* ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7 ARRAY /dev/md9 devices=/dev/sda9,/dev/sdb9 Perhaps you should not include /dev/md5 here. I wondered about that. As you have made a point of building the array containing the root filesystem with 0.99 metadata, ... ...as was instructed in the howto at the time... I would assume that it is being assembled in kernelspace as a result of CONFIG_MD_AUTODETECT being enabled. Yes, I think that's what's happening. Alternatively, perhaps you are using an initramfs. Nope. Either way, by the time the mdraid init.d script executes, the /dev/md5 array must - by definition - be up and mounted. Does it make a difference if you add the following line to the config? AUTO +1.x homehost -all That will prevent it from considering arrays with 0.99 metadata. No, I get the same result. Just a red asterisk at the left end of the line after Starting up RAID devices... Now that I look at /etc/init.d/mdraid I see a few things that aren't quite kosher. The first is that it runs mdadm -As 21, which returns null after booting is finished (whence the empty line before the asterisk). Then it tests for the existence of /dev/md_d*. That also doesn't exist, though /dev/md* does: # ls -l /dev/md* brw-rw 1 root disk 9, 0 Aug 25 10:03 /dev/md0 brw-rw 1 root disk 9, 5 Aug 25 10:03 /dev/md5 brw-rw 1 root disk 9, 7 Aug 25 10:03 /dev/md7 brw-rw 1 root disk 9, 9 Aug 25 10:03 /dev/md9 /dev/md: total 0 lrwxrwxrwx 1 root root 6 Aug 25 10:03 5_0 - ../md5 lrwxrwxrwx 1 root root 6 Aug 25 10:03 7_0 - ../md7 lrwxrwxrwx 1 root root 6 Aug 25 10:03 9_0 - ../md9 Looks like I have some experimenting to do. I forgot to mention in my first post that, on shutdown, when the script runs mdadm -Ss 21 I always get Cannot get exclusive access to /dev/md5... I've always just ignored it until now, but perhaps it's important? On a related note, despite upstream's efforts to make this as awkward as possible, it is possible to mimic the kernel's autodetect functionality in userspace with a config such as this: HOMEHOST ignore DEVICE partitions AUTO +1.x -all Bear in mind that the mdraid script runs `mdadm --assemble --scan`. There is no need to specifically map out the properties of each array. This is what the metadata is for. Thanks for the info, and the help. The fog is dispersing a bit... -- Regards Peter
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On 25/08/14 17:19, Alan McKinnon wrote: On 25/08/2014 11:11, Dale wrote: Alan McKinnon wrote: On 25/08/2014 08:17, Hinnerk van Bruinehsen wrote: On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. gcc is also in /usr which happily guarantees that nothing can be fixed without unpacking a stage first It seems moving so much critical stuff to /usr was a really bright move. lots of sarcasm there and, rm -rf /usr is not a user error one can reasonably expect to recover from and wasnt many of the file system changes being made because some folks wanted a read only /usr but were not there yet? BillK
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On 25 August 2014 12:19:02 CEST, Bill Kenworthy bi...@iinet.net.au wrote: On 25/08/14 17:19, Alan McKinnon wrote: On 25/08/2014 11:11, Dale wrote: Alan McKinnon wrote: On 25/08/2014 08:17, Hinnerk van Bruinehsen wrote: On Sun, Aug 24, 2014 at 11:58:36PM +0430, behrouz khosravi wrote: Hi. I just accidentally removed the /usr folder! And I am sure the /usr/bin and several other folders are gone! Should I go for a complete re-install or there is any other solution? Thanks and I hope that I wont find that blade that I am looking for! You should be able to get away with an emerge @system @world -evDN instead of a complete re-install. You should first get a copy of a minimal working /usr though (like from a stage3 tarball), otherwise you will run into errors as /usr/bin is where python and other stuff resides that you'll need for installation. gcc is also in /usr which happily guarantees that nothing can be fixed without unpacking a stage first It seems moving so much critical stuff to /usr was a really bright move. lots of sarcasm there and, rm -rf /usr is not a user error one can reasonably expect to recover from and wasnt many of the file system changes being made because some folks wanted a read only /usr but were not there yet? BillK Actually. Not being allowed to have /usr on a seperate filesystem as was the case for a very long time made mounting /usr read only near impossible. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Software RAID-1
On Monday 25 August 2014 10:22:31 Peter Humphrey wrote: On Sunday 24 August 2014 19:22:40 Kerin Millar wrote: On 24/08/2014 14:51, Peter Humphrey wrote: ---8 So I decided to clean up /etc/mdadm.conf by adding these lines: DEVICE /dev/sda* /dev/sdb* ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7 ARRAY /dev/md9 devices=/dev/sda9,/dev/sdb9 Perhaps you should not include /dev/md5 here. I wondered about that. As you have made a point of building the array containing the root filesystem with 0.99 metadata, ... ...as was instructed in the howto at the time... I would assume that it is being assembled in kernelspace as a result of CONFIG_MD_AUTODETECT being enabled. Yes, I think that's what's happening. Alternatively, perhaps you are using an initramfs. Nope. Either way, by the time the mdraid init.d script executes, the /dev/md5 array must - by definition - be up and mounted. Does it make a difference if you add the following line to the config? AUTO +1.x homehost -all That will prevent it from considering arrays with 0.99 metadata. No, I get the same result. Just a red asterisk at the left end of the line after Starting up RAID devices... Now that I look at /etc/init.d/mdraid I see a few things that aren't quite kosher. The first is that it runs mdadm -As 21, which returns null after booting is finished (whence the empty line before the asterisk). Then it tests for the existence of /dev/md_d*. That also doesn't exist, though /dev/md* does: # ls -l /dev/md* brw-rw 1 root disk 9, 0 Aug 25 10:03 /dev/md0 brw-rw 1 root disk 9, 5 Aug 25 10:03 /dev/md5 brw-rw 1 root disk 9, 7 Aug 25 10:03 /dev/md7 brw-rw 1 root disk 9, 9 Aug 25 10:03 /dev/md9 /dev/md: total 0 lrwxrwxrwx 1 root root 6 Aug 25 10:03 5_0 - ../md5 lrwxrwxrwx 1 root root 6 Aug 25 10:03 7_0 - ../md7 lrwxrwxrwx 1 root root 6 Aug 25 10:03 9_0 - ../md9 Looks like I have some experimenting to do. Well, it was simple. I just said rc-update del mdraid boot and all is now well. I'd better revisit the docs to see if they still give the same advice. -- Regards Peter
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On Mon, Aug 25, 2014 at 3:57 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: and now you know why you should have added --buildpkg to your default emerge options. Yeah, I am happy that I did it. I really don't like to compile chromium or libreoffice again!
RE: [gentoo-user] Intermittent USB device failures
From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Thursday, August 21, 2014 12:41 PM you said you used 6 different kernel versions - which one? Did you use vanilla or gentoo sources? And... maybe config? I've used all gentoo-sources so far, but I can give vanilla a try. According to my portage logs, I've installed: sys-kernel/gentoo-sources-3.10.17 sys-kernel/gentoo-sources-3.12.6 sys-kernel/gentoo-sources-3.12.7 sys-kernel/gentoo-sources-3.12.8 sys-kernel/gentoo-sources-3.13.1 sys-kernel/gentoo-sources-3.13.2 sys-kernel/gentoo-sources-3.14.1 sys-kernel/gentoo-sources-3.14.5-r1 sys-kernel/gentoo-sources-3.16.0 I think I may have skipped a couple of the minor revisions in there but that's about the right range of versions I've tried since I started. Config for the latest working kernel (3.16.0 with OHCI EHCI) is: http://pastebin.com/PrgwNZYH Thanks, --Mike
Re: [gentoo-user] Software RAID-1
On 25/08/2014 10:22, Peter Humphrey wrote: On Sunday 24 August 2014 19:22:40 Kerin Millar wrote: On 24/08/2014 14:51, Peter Humphrey wrote: ---8 So I decided to clean up /etc/mdadm.conf by adding these lines: DEVICE /dev/sda* /dev/sdb* ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7 ARRAY /dev/md9 devices=/dev/sda9,/dev/sdb9 Perhaps you should not include /dev/md5 here. I wondered about that. As you have made a point of building the array containing the root filesystem with 0.99 metadata, ... ...as was instructed in the howto at the time... I would assume that it is being assembled in kernelspace as a result of CONFIG_MD_AUTODETECT being enabled. Yes, I think that's what's happening. Alternatively, perhaps you are using an initramfs. Nope. Either way, by the time the mdraid init.d script executes, the /dev/md5 array must - by definition - be up and mounted. Does it make a difference if you add the following line to the config? AUTO +1.x homehost -all That will prevent it from considering arrays with 0.99 metadata. No, I get the same result. Just a red asterisk at the left end of the line after Starting up RAID devices... It since dawned upon me that defining AUTO as such won't help because you define the arrays explicitly. Can you try again with the mdraid script in the default runlevel but without the line defining /dev/md5? Now that I look at /etc/init.d/mdraid I see a few things that aren't quite kosher. The first is that it runs mdadm -As 21, which returns null after booting is finished (whence the empty line before the asterisk). Then it tests Interesting. I think that you should file a bug because the implication is that mdadm is returning a non-zero exit status in the case of arrays that have already been assembled. Here's a post from the Arch forums suggesting the same: https://bbs.archlinux.org/viewtopic.php?pid=706175#p706175 Is the exit status something other than 1? Try inserting eerror $? immediately after the call to mdadm -As. Granted, it's just an annoyance but it looks silly, not to mention unduly worrying. for the existence of /dev/md_d*. That also doesn't exist, though /dev/md* does: # ls -l /dev/md* brw-rw 1 root disk 9, 0 Aug 25 10:03 /dev/md0 brw-rw 1 root disk 9, 5 Aug 25 10:03 /dev/md5 brw-rw 1 root disk 9, 7 Aug 25 10:03 /dev/md7 brw-rw 1 root disk 9, 9 Aug 25 10:03 /dev/md9 /dev/md: total 0 lrwxrwxrwx 1 root root 6 Aug 25 10:03 5_0 - ../md5 lrwxrwxrwx 1 root root 6 Aug 25 10:03 7_0 - ../md7 lrwxrwxrwx 1 root root 6 Aug 25 10:03 9_0 - ../md9 I think this has something to do with partitionable RAID. Yes, it is possible to superimpose partitions upon an md device, though I have never seen fit to do so myself. For those that do not, the md_d* device nodes won't exist. Looks like I have some experimenting to do. I forgot to mention in my first post that, on shutdown, when the script runs mdadm -Ss 21 I always get Cannot get exclusive access to /dev/md5... I've always just ignored it until now, but perhaps it's important? I would guess that it's because a) the array hosts the root filesystem b) you have the array explicitly defined in mdadm.conf and mdadm is being called with -s/--scan again. On a related note, despite upstream's efforts to make this as awkward as possible, it is possible to mimic the kernel's autodetect functionality in userspace with a config such as this: HOMEHOST ignore DEVICE partitions AUTO +1.x -all Bear in mind that the mdraid script runs `mdadm --assemble --scan`. There is no need to specifically map out the properties of each array. This is what the metadata is for. Thanks for the info, and the help. The fog is dispersing a bit...
Re: [gentoo-user] Software RAID-1
On 25/08/2014 13:18, Kerin Millar wrote: snip No, I get the same result. Just a red asterisk at the left end of the line after Starting up RAID devices... It since dawned upon me that defining AUTO as such won't help because you define the arrays explicitly. Can you try again with the mdraid script in the default runlevel but without the line defining /dev/md5? Sorry, I wasn't clear. Would you remove/comment the line describing /dev/md5 but also include this line:- AUTO +1.x -all --Kerin
Re: [gentoo-user] Software RAID-1
On 25/08/2014 12:17, Peter Humphrey wrote: snip Well, it was simple. I just said rc-update del mdraid boot and all is now well. I'd better revisit the docs to see if they still give the same advice. -- Regards Peter Very interesting indeed. I now wonder if this is a race condition between the init script running `mdadm -As` and the fact that the mdadm package installs udev rules that allow for automatic incremental assembly? Refer to /lib/udev/rules.d/64-md-raid.rules and you'll see that it calls `mdadm --incremental` for newly added devices. With that in mind, here's something else for you to try. Doing this will render these udev rules null and void: # touch /etc/udev/rules.d/64-md-raid.rules Thereafter, the mdraid script will be the only agent trying to assemble the 1.x metadata arrays so make sure that it is re-enabled. I'm not actually sure that there is any point in calling mdadm -As where the udev rules are present. I would expect it to be one approach or the other, but not both at the same time. Incidentally, the udev rules were a source of controversy in the following bug. Not everyone appreciates that they are installed by default. https://bugs.gentoo.org/show_bug.cgi?id=401707 --Kerin
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
On Mon, Aug 25, 2014 at 7:52 AM, behrouz khosravi bz.khosr...@gmail.com wrote: On Mon, Aug 25, 2014 at 3:57 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: and now you know why you should have added --buildpkg to your default emerge options. Yeah, I am happy that I did it. I really don't like to compile chromium or libreoffice again! There aren't a lot of great options in this situation, especially if your toolchain is broken. The simple solution is to copy /usr over from a stage3, but you're going to end up with lots of orphans/etc that way. It isn't super-clean, but if you do an immediate emerge -e world and then clean up orphans in /usr that will probably take care of you. A cleaner solution might be to set up your paths so that it searches /usr first, and then the stage3. Then you could bootstrap your root as if you were building a Gentoo Prefix install: 1. Set up your search paths to include the intact prefix/usr at the end. 2. Do an emerge -e @system. Maybe do it twice. 3. Remove your search paths so that you're using your root /usr. 4. Consider doing an extra emerge -e @system to ensure internal consistency. 5. Do an emerge -e world. Variations on this might involve building binpkgs from a chroot and installing those using the search path to let portage run. One of these days I'll have to nuke /usr in a container and play around with restoring it. -- Rich
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
behrouz khosravi: On Mon, Aug 25, 2014 at 3:57 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: and now you know why you should have added --buildpkg to your default emerge options. Yeah, I am happy that I did it. I really don't like to compile chromium or libreoffice again! Those methods are all not safe if you happen to randomly delete system folders by accident. The only relatively safe methods are rsync to a remote (or similar) or file system level backups like zfs has.
Re: [gentoo-user] Intermittent USB device failures
Am 22.08.2014 um 02:05 schrieb Mike Edenfield: From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Thursday, August 21, 2014 12:41 PM you said you used 6 different kernel versions - which one? Did you use vanilla or gentoo sources? And... maybe config? I've used all gentoo-sources so far, but I can give vanilla a try. According to my portage logs, I've installed: sys-kernel/gentoo-sources-3.10.17 sys-kernel/gentoo-sources-3.12.6 sys-kernel/gentoo-sources-3.12.7 sys-kernel/gentoo-sources-3.12.8 sys-kernel/gentoo-sources-3.13.1 sys-kernel/gentoo-sources-3.13.2 sys-kernel/gentoo-sources-3.14.1 sys-kernel/gentoo-sources-3.14.5-r1 sys-kernel/gentoo-sources-3.16.0 I think I may have skipped a couple of the minor revisions in there but that's about the right range of versions I've tried since I started. Config for the latest working kernel (3.16.0 with OHCI EHCI) is: http://pastebin.com/PrgwNZYH Thanks, --Mike please post the config here. Not pastebin. Never pastebin. Dumb question: are you really sure you booted the different kernels - and not just installing the kernel sources and maybe some make'ing Also: if you have a problem that might be kernel related: always(!) try vanilla sources first. The bug might go away - and if it does not go away, you can go straight to lkml.
[gentoo-user] openjdk-6-jdk
Hello, I working on a new version of the apache mesos (debelopment_overlay) ebuild. Slowly, I'm putting together an ebuild (EAPI=5) for mesos on gentoo. I'm assuming I can use maven-bin, since it does not seem be in a src-compile version in the portage tree? For openjdk-6-jdk [1] I'm not sure what my options are as it (or a newer version?) is required by mesos-0.19-1. I did see these in portage: dev-java/sun-jdk [Masked] dev-java/soylatte-jdk-bin dev-java/oracle-jdk-bin dev-java/ibm-jdk-bin (and many more jdk's in portage) Some discussion and guidance would be keenly appreciated, as I'm not at all up on the current gentoo java issues. TIA, James [1] http://mesos.apache.org/gettingstarted/
Re: [gentoo-user] Software RAID-1
On Monday 25 August 2014 13:35:11 Kerin Millar wrote: On 25/08/2014 12:17, Peter Humphrey wrote: snip Well, it was simple. I just said rc-update del mdraid boot and all is now well. I'd better revisit the docs to see if they still give the same advice. Very interesting indeed. You wrote this e-mail after the other two, so I'll stick to this route, leaving the other idea for later if needed. I now wonder if this is a race condition between the init script running `mdadm -As` and the fact that the mdadm package installs udev rules that allow for automatic incremental assembly? Isn't it just that, with the kernel auto-assembly of the root partition, and udev rules having assembled the rest, all the work's been done by the time the mdraid init script is called? I had wondered about the time that udev startup takes; assembling the raids would account for it. Refer to /lib/udev/rules.d/64-md-raid.rules and you'll see that it calls `mdadm --incremental` for newly added devices. # ls -l /lib/udev/rules.d | grep raid -rw-r--r-- 1 root root 2.1K Aug 23 10:34 63-md-raid-arrays.rules -rw-r--r-- 1 root root 1.4K Aug 23 10:34 64-md-raid-assembly.rules With that in mind, here's something else for you to try. Doing this will render these udev rules null and void: # touch /etc/udev/rules.d/64-md-raid.rules I did that, but I think I need instead to # touch /etc/udev/rules.d/63-md-raid-arrays.rules # touch /etc/udev/rules.d/64-md-raid-assembly.rules I'll try it now... Thereafter, the mdraid script will be the only agent trying to assemble the 1.x metadata arrays so make sure that it is re-enabled. Right. Here's the position: 1. I've left /etc/init.d/mdraid out of all run levels. I have nothing but comments in mdadm.conf, but then it's not likely to be read anyway if the init script isn't running. 2. I have empty /etc/udev rules files as above. 3. I have kernel auto-assembly of raid enabled. 4. I don't use an init ram disk. 5. The root partition is on /dev/md5 (0.99 metadata) 6. All other partitions except /boot are under /dev/vg7 which is built on top of /dev/md7 (1.x metadata). 7. The system boots normally. I'm not actually sure that there is any point in calling mdadm -As where the udev rules are present. I would expect it to be one approach or the other, but not both at the same time. That makes sense to me too. Do I even need sys-fs/mdadm installed? Maybe I'll try removing it. I have a little rescue system in the same box, so it'd be easy to put it back if necessary. Incidentally, the udev rules were a source of controversy in the following bug. Not everyone appreciates that they are installed by default. https://bugs.gentoo.org/show_bug.cgi?id=401707 I'll have a look at that - thanks. -- Regards Peter
Re: [gentoo-user] Software RAID-1
On 25/08/2014 17:51, Peter Humphrey wrote: On Monday 25 August 2014 13:35:11 Kerin Millar wrote: On 25/08/2014 12:17, Peter Humphrey wrote: snip Well, it was simple. I just said rc-update del mdraid boot and all is now well. I'd better revisit the docs to see if they still give the same advice. Very interesting indeed. You wrote this e-mail after the other two, so I'll stick to this route, leaving the other idea for later if needed. I now wonder if this is a race condition between the init script running `mdadm -As` and the fact that the mdadm package installs udev rules that allow for automatic incremental assembly? Isn't it just that, with the kernel auto-assembly of the root partition, and udev rules having assembled the rest, all the work's been done by the time the mdraid init script is called? I had wondered about the time that udev startup takes; assembling the raids would account for it. Yes, it's a possibility and would constitute a race condition - even though it might ultimately be a harmless one. As touched upon in the preceding post, I'd really like to know why mdadm sees fit to return a non-zero exit code given that the arrays are actually assembled successfully. After all, even if the arrays are assembled at the point that mdadm is executed by the mdraid init script, partially or fully, it surely ought not to matter. As long as the arrays are fully assembled by the time mdadm exits, it should return 0 to signify success. Nothing else makes sense, in my opinion. It's absurd that the mdraid script is drawn into printing a blank error message where nothing has gone wrong. Further, the mdadm ebuild still prints elog messages stating that mdraid is a requirement for the boot runlevel but, with udev rules, I don't see how that can be true. With udev being event-driven and calling mdadm upon the introduction of a new device, the array should be up and running as of the very moment that all the disks are seen, no matter whether the mdraid init script is executed or not. Refer to /lib/udev/rules.d/64-md-raid.rules and you'll see that it calls `mdadm --incremental` for newly added devices. # ls -l /lib/udev/rules.d | grep raid -rw-r--r-- 1 root root 2.1K Aug 23 10:34 63-md-raid-arrays.rules -rw-r--r-- 1 root root 1.4K Aug 23 10:34 64-md-raid-assembly.rules With that in mind, here's something else for you to try. Doing this will render these udev rules null and void: # touch /etc/udev/rules.d/64-md-raid.rules I did that, but I think I need instead to # touch /etc/udev/rules.d/63-md-raid-arrays.rules # touch /etc/udev/rules.d/64-md-raid-assembly.rules Ah, yes. Looks like the rules have changed in =mdadm-3.3. I'm still using mdadm-3.2.6-r1. I'll try it now... Thereafter, the mdraid script will be the only agent trying to assemble the 1.x metadata arrays so make sure that it is re-enabled. Right. Here's the position: 1. I've left /etc/init.d/mdraid out of all run levels. I have nothing but comments in mdadm.conf, but then it's not likely to be read anyway if the init script isn't running. 2. I have empty /etc/udev rules files as above. 3. I have kernel auto-assembly of raid enabled. 4. I don't use an init ram disk. 5. The root partition is on /dev/md5 (0.99 metadata) 6. All other partitions except /boot are under /dev/vg7 which is built on top of /dev/md7 (1.x metadata). 7. The system boots normally. I must confess that this boggles my mind. Under these circumstances, I cannot fathom how - or when - the 1.x arrays are being assembled. Something has to be executing mdadm at some point. I'm not actually sure that there is any point in calling mdadm -As where the udev rules are present. I would expect it to be one approach or the other, but not both at the same time. That makes sense to me too. Do I even need sys-fs/mdadm installed? Maybe I'll try removing it. I have a little rescue system in the same box, so it'd be easy to put it back if necessary. Yes, you need mdadm because 1.x metadata arrays must be assembled in userspace. In Gentoo, there are three contexts I know of in which this may occur:- 1) Within an initramfs 2) As a result of the udev rules 3) As a result of the mdraid script Incidentally, the udev rules were a source of controversy in the following bug. Not everyone appreciates that they are installed by default. https://bugs.gentoo.org/show_bug.cgi?id=401707 I'll have a look at that - thanks. --Kerin
[gentoo-user] Re: openjdk-6-jdk
James wireless at tampabay.rr.com writes: For openjdk-6-jdk [1] I'm not sure what my options are as it (or a newer version?) is required by mesos-0.19-1. I did see these in portage: Some discussion and guidance would be keenly appreciated, as I'm not at all up on the current gentoo java issues. Ok, so I found the gentoo java wiki [1]. So if I'm comprehending this correctly, icedtea is openjdk it just uses 100% open source tools to build the jdk as opposed to the fact that openjdk uses proprietary tools to build? I'm still a bit confused on the options for jdk, (openjdk) any limitations, gotchas, thnings_to_avoid; so some recommendations would be beneficial. James [1] http://wiki.gentoo.org/wiki/Java#Installing_a_JRE.2FJDKs
[gentoo-user] MESOS compiling! Re: openjdk-6-jdk
Folks, It's and early hack but mesos-0.19.1.ebuild is compiling out of my /usr/local/portage. I've got to get a few things done before I can upload it somewhere to an overlay; mostly reading up on just how (whichone) to upload to. If anyone wants to build mesos from a hacked (EAPI=5) overlay, drop me a line and I'll email the ebuild to you. Surely it needs work (polish?) but it is compiling now oops it just completed compiling with no errors? (didn't see this coming. gotta run! hth, James James wireless at tampabay.rr.com writes: Hello, I working on a new version of the apache mesos (debelopment_overlay) ebuild. Slowly, I'm putting together an ebuild (EAPI=5) for mesos on gentoo. I'm assuming I can use maven-bin, since it does not seem be in a src-compile version in the portage tree? For openjdk-6-jdk [1] I'm not sure what my options are as it (or a newer version?) is required by mesos-0.19-1. I did see these in portage: dev-java/sun-jdk [Masked] dev-java/soylatte-jdk-bin dev-java/oracle-jdk-bin dev-java/ibm-jdk-bin (and many more jdk's in portage) Some discussion and guidance would be keenly appreciated, as I'm not at all up on the current gentoo java issues. TIA, James [1] http://mesos.apache.org/gettingstarted/
[gentoo-user] Is LLVM bytecode the future ?
This has little to do with Gentoo , but still it is a interesting debate . You can compile a great sort of programing lenguages to llvm bytecode : C(++) , java , Objetive C(++) , C# , Haskell , Rust ... And a lot more . On the other side , you CAN'T compile , lenguages like python or perl . The interesting part is that a feature under developement : It can decompile C(++) code to LLVM bytecode , (only if it not use plataform specific libraries or assembly code ) So , you can easily port your favourite X86 privative application to ARM or PPC , Just wonderfull .
[gentoo-user] Re: Is LLVM bytecode the future ?
Sorry , i accidentally send it . What i wanted to say is that , Theoretically , you can : 1) Native compile statically typed non-native lenguages 2) Recompile binaries for another architecture and even plataforms . 3) Achive a .NET like CLI , but even better . And , notice , that the LLVM garbage collector is a little precary . 2014-08-25 19:45 GMT+00:00 Ivan Viso Altamirano ivanviso...@gmail.com: This has little to do with Gentoo , but still it is a interesting debate . You can compile a great sort of programing lenguages to llvm bytecode : C(++) , java , Objetive C(++) , C# , Haskell , Rust ... And a lot more . On the other side , you CAN'T compile , lenguages like python or perl . The interesting part is that a feature under developement : It can decompile C(++) code to LLVM bytecode , (only if it not use plataform specific libraries or assembly code ) So , you can easily port your favourite X86 privative application to ARM or PPC , Just wonderfull .
[gentoo-user] Re: Is LLVM bytecode the future ?
Ivan Viso Altamirano ivanviso123 at gmail.com writes: This has little to do with Gentoo , but still it is a interesting debate . You can compile a great sort of programing lenguages to llvm bytecode : C(++) , java , Objetive C(++) , C# , Haskell , Rust ... And a lot more . On the other side , you CAN'T compile , lenguages like python or perl . I was just reading about Clang on the gentoo wiki and llvm. It seems that most of the portage tree now compiles with Clang. Some packages, although not listed, do compile but give runtime errors. It'd be great to know what does not compile and what compiles but has run problems with the code. The interesting part is that a feature under developement : It can decompile C(++) code to LLVM bytecode , (only if it not use plataform specific libraries or assembly code ) So , you can easily port your favourite X86 privative application to ARM or PPC , Just wonderfull . There are many methodologies for running codes develop for one system on top of another system. Gentroid is another example [1]. Massively parallel Arm based servers are much closer than most realize; they will have several mechanisms to run many popular binaries to provide for quick penetration into the server/workstation markets. In less than a year, many complex softwares will be re-worked to take advantage some some very powerful new paradigms in processor, memory and buss semantics. hth, James [1] https://code.google.com/p/gentroid/ [2] posted to gentoo embedded: Little update on my project Gentroid: gentroid is now in the layman remote list, also I made a video, which show the Hello World app running on Gentoo: https://www.youtube.com/watch?v=8mdiUHNbPFs, but the source code is not yet available because the main repository is too big. I sent a request to the google code hosting team and I hope they will raise the limit, so I can upload the complete source code. Regards, Simon
Re: [gentoo-user] Re: openjdk-6-jdk
2014-08-25 12:44 GMT-06:00 James wirel...@tampabay.rr.com: James wireless at tampabay.rr.com writes: For openjdk-6-jdk [1] I'm not sure what my options are as it (or a newer version?) is required by mesos-0.19-1. I did see these in portage: Some discussion and guidance would be keenly appreciated, as I'm not at all up on the current gentoo java issues. Ok, so I found the gentoo java wiki [1]. So if I'm comprehending this correctly, icedtea is openjdk it just uses 100% open source tools to build the jdk as opposed to the fact that openjdk uses proprietary tools to build? I'm still a bit confused on the options for jdk, (openjdk) any limitations, gotchas, thnings_to_avoid; so some recommendations would be beneficial. James [1] http://wiki.gentoo.org/wiki/Java#Installing_a_JRE.2FJDKs Just dropping and idea for your ebuild, you might have this planned but anyway, I would put something like 'virtual/jdk:1.6' in RDEPEND, so if things work as they should(but that's not realistic), any of the java implementations in the tree would provide jdk6 for your ebuild.
[gentoo-user] Re: openjdk-6-jdk
Jc García jyo.garcia at gmail.com writes: Just dropping and idea for your ebuild, you might have this planned but anyway, I would put something like 'virtual/jdk:1.6' in RDEPEND, so if things work as they should(but that's not realistic), any of the java implementations in the tree would provide jdk6 for your ebuild. I installed icedtea-bin for now. From the ebuild (which is a hack) I have : DEPEND=net-misc/curl dev-libs/cyrus-sasl python? ( dev-lang/python dev-python/boto ) java? ( virtual/jdk ) It seems would not compile until I installed the maven-bin package..Which is not a requisite in the ebuild but I saw that maben was a required code for building mesos on another distro Like I said, it's a hack, but I'll get it cleaned up; because nobody else seemed motivated to get mesos running on gentoo. Now it off to get spark[1] and the hadoop[2] happy on gentoo... happy, happy happy James [1] https://spark.apache.org/ [2] http://hadoop.apache.org/
Re: [gentoo-user] Versioned world dependencies and subslot rebuilds
On Sat, 9 Aug 2014 14:38:12 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Fri, 8 Aug 2014 17:37:52 -0700, Bryan Gardiner wrote: I'm setting up a chroot for doing some Haskell work. This chroot is so that I can test my package against old versions of my dependencies. I thought I would be okay with putting the following in my world file: =dev-haskell/cabal-1.16* ~dev-haskell/mtl-2.1.1 ~dev-haskell/gtk-0.12.0 ~dev-haskell/hunit-1.2.4.2 ~dev-haskell/parsec-3.1.3 =dev-lang/ghc-7.4.2 it might be cleaner, and easier to maintain, to put these in a set. Excellent idea. I never think to use them. Thanks. -- Go game editor :: http://khumba.net/projects/goatee :: AGPL, Haskell I: [pulseaudio] main.c: Fresh high-resolution timers available! Bon appetit!
Re: [gentoo-user] Versioned world dependencies and subslot rebuilds
On Sat, 9 Aug 2014 16:23:30 +0300
Sergei Trofimovich sly...@gentoo.org wrote:
On Fri, 8 Aug 2014 17:37:52 -0700
Bryan Gardiner b...@khumba.net wrote:
Happy Friday gentoo-user,
I'm setting up a chroot for doing some Haskell work. This chroot is
so that I can test my package against old versions of my
dependencies. I thought I would be okay with putting the following in
my world file:
=dev-haskell/cabal-1.16*
~dev-haskell/mtl-2.1.1
~dev-haskell/gtk-0.12.0
~dev-haskell/hunit-1.2.4.2
~dev-haskell/parsec-3.1.3
=dev-lang/ghc-7.4.2
But when I do emerge -puvD --changed-use @world I get:
# emerge -puvDN @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild rR] dev-lang/ghc-7.4.2:0/7.4.2::gentoo-haskell USE=binary
doc gmp -ghcbootstrap -ghcmakebinary -llvm 0 kB
[ebuild rR] dev-haskell/cabal-1.16.0.3:0/1.16.0.3 USE=-profile
{-test} 0 kB
[ebuild rR] dev-haskell/ghc-paths-0.1.0.9::gentoo-haskell
USE=-profile 0 kB
[ebuild rR] dev-haskell/xhtml-3000.2.1-r1:0/3000.2.1::gentoo-haskell
USE=hoogle hscolour -doc -profile 0 kB
[ebuild rR] dev-haskell/glib-0.12.4-r1:0/0.12.4 USE=doc hscolour
-profile 0 kB
[ebuild rR] dev-haskell/utf8-string-0.3.7-r1:0/0.3.7 USE=doc
hscolour -profile 0 kB
[ebuild rR] dev-haskell/deepseq-1.3.0.1:0/1.3.0.1::gentoo-haskell
USE=doc hoogle hscolour -profile 0 kB
[ebuild rR]
dev-haskell/transformers-0.3.0.0-r1:0/0.3.0.0::gentoo-haskell USE=doc
hoogle hscolour -profile 0 kB
[ebuild rR] dev-haskell/mtl-2.1.1 USE=doc hscolour -profile 0 kB
[ebuild rR] dev-haskell/text-0.11.3.1:0/0.11.3.1 USE=doc hscolour
-developer -profile {-test} 0 kB
[ebuild rR] dev-haskell/cairo-0.12.5.0-r1:0/0.12.5.0 USE=doc
hscolour pdf postscript svg -profile 0 kB
[ebuild rR] dev-haskell/gio-0.12.4-r1:0/0.12.4 USE=doc hscolour
-profile 0 kB
[ebuild rR] dev-haskell/pango-0.12.4-r1:0/0.12.4 USE=doc hscolour
-profile 0 kB
[ebuild N ] dev-haskell/gtk-0.12.4-r1:2/0.12.4 USE=doc gio
hscolour -profile 0 kB
Total: 14 packages (1 new, 13 reinstalls), Size of downloads: 0 kB
* IMPORTANT: 5 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
(I haven't gotten gtk to install just yet.) I can't figure out what's
causing the rebuilds. If I rebuild them, then they continue wanting
to rebuild. If I instead put the unversioned atoms in world and stick
the following in package.mask, then the rebuilds disappear:
=dev-haskell/cabal-1.17
=dev-haskell/mtl-2.1.2
=dev-haskell/gtk-0.12.1
=dev-haskell/hunit-1.2.4.3
=dev-haskell/parsec-3.1.4
=dev-lang/ghc-7.4.3
I've attached the output of emerge -puvD --changed-use --debug
@world for the rebuilding case. I see:
13993 Exiting... (dev-lang/ghc-7.4.2::gentoo-haskell, ebuild scheduled
for merge)
18458 @__auto_slot_operator_replace_installed__ depends on
...
18463 (dev-lang/ghc-7.4.2::gentoo-haskell, ebuild scheduled for merge)
(buildtime_slot_op)
18697 forced reinstall atoms:
18698root: /
...
18711 atom: dev-lang/ghc:0
but don't understand why. What's causing the rebuilds?
Hia Bryan!
It looks like very old portage bug:
https://bugs.gentoo.org/show_bug.cgi?id=439688
USE=doc might be a trigger of this bug (due to circular nature of doc haskell
depends)
What portage version you are using?
Fresh portage is able to show which packages exactly trigger rebuild.
Interesting (and yes, old) bug. I'm on portage-2.2.8-r1 but maybe
this is a related issue. I tried disabling my dev-haskell/* doc USE
line, changed the world lines to exact versions, and moved them to a
set as Neil suggested, but I still get rebuilds, and Portage doesn't
say why.
(Fewer rebuilds now, independent of the USE=-doc change:)
# emerge -puvD --changed-use @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild rR] dev-haskell/mtl-2.1.1 USE=hscolour -doc -profile 0 kB
[ebuild rR] dev-haskell/gio-0.12.4-r1:0/0.12.4 USE=hscolour -doc
-profile 0 kB
[ebuild rR] dev-haskell/cairo-0.12.4-r1:0/0.12.4 USE=hscolour svg -doc
-profile 0 kB
[ebuild rR] dev-haskell/pango-0.12.4-r1:0/0.12.4 USE=hscolour -doc
-profile 0 kB
[ebuild rR] dev-haskell/gtk-0.12.4-r1:2/0.12.4 USE=gio hscolour -doc
-profile 0 kB
Total: 5 packages (5 reinstalls), Size of downloads: 0 kB
* IMPORTANT: 5 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
Thanks!
Bryan
--
Go game editor :: http://khumba.net/projects/goatee :: AGPL, Haskell
I: [pulseaudio] main.c: Fresh high-resolution timers available! Bon appetit!
