Opened 9 years ago
Closed 8 years ago
#42 closed task (fixed)
Make fail aria2
Reported by: | anonymous | Owned by: | bas |
---|---|---|---|
Priority: | major | Milestone: | SALI 1.6.0 |
Component: | sali kernel/initrd | Version: | trunk |
Keywords: | debian, debian wheezy | Cc: |
Description
Hi, I'm trying to compile sali in a debian wheezy (now is testing but I need it to install de nvidia drivers for cuda) and it fails to compile aria2
In file included from FtpConnection.cc:44:0: util.h: In instantiation of ‘void aria2::util::divide(std::pair<std::pair<T, T>, std::pair<T, T> >&, InputIterator, InputIterator, char) [with InputIterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char> >]’: FtpConnection.cc:408:75: required from here
It seems to be a bug from using GCC 4.7 and it's reported in Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667102
Source: aria2
Source-Version: 1.14.2-2
We believe that the bug you reported is fixed in the latest version of
aria2, which is due to be installed in the Debian FTP archive:
So, the idea of this ticket is to ask for an upgrade of aria version to that working version.
Thanks.
Attachments (0)
Change History (15)
comment:1 in reply to: ↑ description Changed 9 years ago by anonymous
comment:2 in reply to: ↑ description Changed 9 years ago by dmontaldo@dc.uba.ar
Replying to anonymous:
So, the idea of this ticket is to ask for an upgrade of aria version to that working version.
The Debian wheezy version of aria2 is 1.15.1-1
http://packages.debian.org/wheezy/aria2
I don't know if you need that version but at least the 1.14.2-2 it doesn't have that reported bug.
Thanks!
comment:3 Changed 9 years ago by dmontaldo@dc.uba.ar
- Owner changed from dmontaldo@dc.uba.ar to anonymous
- Status changed from new to assigned
comment:4 Changed 9 years ago by dmontaldo@dc.uba.ar
- Keywords debian debian wheezy added
- Summary changed from Make fail to Make fail aria2
comment:5 follow-up: ↓ 8 Changed 9 years ago by bas
Thanks for reporting. When we switch to wheezy for building SALI/ we will upgrade aria. Dou you have to build your own version of SALI can't you use the current SALI release?
comment:6 Changed 9 years ago by bas
- Component changed from sali to sali kernel/initrd
- Owner changed from anonymous to bas
- Status changed from assigned to accepted
- Type changed from defect to task
comment:7 Changed 9 years ago by dennis
- Priority changed from blocker to major
comment:8 in reply to: ↑ 5 ; follow-up: ↓ 11 Changed 9 years ago by dmontaldo@dc.uba.ar
Replying to bas:
Thanks for reporting. When we switch to wheezy for building SALI/ we will upgrade aria. Dou you have to build your own version of SALI can't you use the current SALI release?
I try it for the first time and it doesn't work, at least for me.
I don't remember exactly why, because it was a headache to use system imager to build the image and then found sali to deploy it.
I start deploying the images whit the SI scripts too and then I ask about this in the si-suite mailing list and then I switch completely to sali (thanks for your work!)
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...
I could give a try now to this binaries in wheezy but keep in mind too that squeeze its very old for some new hardware (like the ones with GPUs).
Thanks and excuse me if I submit to many tickets if you don't plan to compile sali yet in wheezy.
comment:9 follow-up: ↓ 10 Changed 9 years ago by bas
We are always interested in updates and patches for SALI and we appreciate your efforts.
First of all SALI has nothing todo with debian squeeze. we only use it to compile and develop SALI. SALI uses a modern linux kernel (3.1.4) and udev if there are missing device drivers we will add them. The combo of kernel and udev is also important one you are already experiencing this. We use SALI to install our images and we have also a GPU cluster. SALI is responsible for detecting hardware like network controllers, disk controllers so we can install the cloned image. The cloned image has all the proper GPU device drivers.
Or do you use SALI differently?
comment:10 in reply to: ↑ 9 Changed 9 years ago by dmontaldo@dc.uba.ar
Replying to bas:
We are always interested in updates and patches for SALI and we appreciate your efforts.
First of all SALI has nothing todo with debian squeeze. we only use it to compile and develop SALI. SALI uses a modern linux kernel (3.1.4) and udev if there are missing device drivers we will add them.
I know and I think that this is the big advantage to switch to sali.
The combo of kernel and udev is also important one you are already experiencing this. We use SALI to install our images and we have also a GPU cluster.
But I can't install the nvidia proprietary drivers and cuda toolkit in debian wheezy and that is why I have to upgrade from squeeze to wheezy.
May be it was my mistake but it has an old kernel compared to the one that uses nvidia to compile their modules.
SALI is responsible for detecting hardware like network controllers, disk controllers so we can install the cloned image. The cloned image has all the proper GPU device drivers.
May be this is a technical question but which drivers are you using? the debian package for nvidia drivers?
Or do you use SALI differently?
No, just to deploy the images.
comment:11 in reply to: ↑ 8 ; follow-up: ↓ 12 Changed 9 years ago by dmontaldo@dc.uba.ar
Replying to dmontaldo@…:
Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...
Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*
And change the verbose level to don't show the progress transfered files (I want verbose, but not pass the {VERBOSE_GETIMAGE_OPT} to the rsync)
And add --stats and --human-readable ;)
comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 9 years ago by bas
Replying to dmontaldo@…:
Replying to dmontaldo@…:
Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...
Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*
Why? You can exclude this directories when you makeing a image from your golden node. No need to patch these files. What commands do you use to clone a node. There you must exclude these directories.
And change the verbose level to don't show the progress transfered files (I want verbose, but not pass the {VERBOSE_GETIMAGE_OPT} to the rsync)
And add --stats and --human-readable ;)
The different VERBOSE levels are explained in:
comment:13 in reply to: ↑ 12 Changed 9 years ago by dmontaldo@dc.uba.ar
Replying to bas:
Replying to dmontaldo@…:
Replying to dmontaldo@…:
Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...
Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*
Why? You can exclude this directories when you makeing a image from your golden node. No need to patch these files. What commands do you use to clone a node. There you must exclude these directories.
It fails the rsync when I was in the chrooted image because I have to mount /dev, /sys, /proc etc
I made a script to chroot the images in a "nice way".
Do you have something to do that?
comment:14 Changed 9 years ago by dennis
- Milestone set to SALI 1.6.0
comment:15 Changed 8 years ago by dennis
- Resolution set to fixed
- Status changed from accepted to closed
This has been fixed in the current trunk version, which will be released as version 1.6.0
Replying to anonymous:
This is the complete error: