linux-image 2.6.16-12 and /dev/shm

[Alexander Samad]

Hi

Just recently upgraded to linux-image-2.6.16-12

on reboot, it complains about not being able to load /dev/shm

do i need it and what do I do to get it back ?

Alex


signature.asc
Description: Digital signature

Re: Bug#367402: Tyan S2865

[Karl Schmidt]

Tried the debian-testing-amd64-netinst.iso from the may 17th build.

It fails at  install base system - with DeBootstrap error - failed to determine 
codename for release.




Karl Schmidt EMail [EMAIL PROTECTED]
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th StreetPh (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434


Misdirection is the key to being a good magician. Magicians tell
you they are doing something while they do something quite
different; much like politicians -- except we can afford magicians.
-KPS



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Goswin von Brederlow]

[EMAIL PROTECTED] (Lennart Sorensen) writes:

> On Fri, May 19, 2006 at 04:29:36PM +0200, Goswin von Brederlow wrote:
>> You have to trick grub-install. Say /boot is on /dev/md0, a raid1 of
>> /dev/sda1 and /dev/sdb1. Then you can put /dev/sda1 into devices.map,
>> instal-grub, repeat for sdb1. You might have to change fstab and/or
>> mtab as well. Can't remeber if that is truely needed.
>> 
>> But grub-install also has some special code for raids. Why it doesn't
>> work or isn't good enough should be someones TODO. Maybe we could make
>> that a NM job :)
>
> grub-install works fine here with /boot on a raid1.  It has ever since
> sarge was released (raid1 support was added sometime in early 2005 it
> seems).  No tricks required.
>
> Len Sorensen

Then pull a disk (the right one) and see it stop booting. From
grub-install:

# Usage: getraid_mdadm mddevice
# Routine to find a physical device from an md device
# If found, the first grub BIOS device (from device.map) is returned 
# If no BIOS drives match the RAID devices, the first device returned
# from mdadm -D is returned

Only one of your disks is bootable. By setting up each device in
device.map in turn you get grub on each of them.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: X700 + fglrx + debian-amd64 + xorg7.0 = running ?

[Andrea Bertagna]

Hi everybody,
I have the same problem with an Acer Aspire 5024WLMi (Radeon
X700). After upgrading to xorg 7 my old fglrx stopped working,
as expected, but I'm not even able to let xserver-xorg-video-ati
driver work: X starts regularly (all processes are running as they
should) but the screen is blank.

How long should we wait for an Ati serious support?

Bye
Andrea


On Tuesday 16 May 2006 21:33, Fielder George Dowding wrote:
> Greetings Hans and everybody,
>
> I have an HP Presario zv6000 series (zv6201cl to be exact) which has an
> ATI Radeon XPRESS 200M 5955 (PCIE) video chip. I was able to use the
> proprietary ATI driver (fglrx) up through the 6.9 version of xorg. I
> never could get the ATI Control feature to work although it installed
> without complaint. I don't know about 3D effects having no applications
> (games?) that required such. I was satisfied with the screen resolution
> of 1280x800 that is native to the "widescreen" LCD monitor (13 inch;
> 333mm). The only other xorg (<=6.9) driver that would work was the VESA
> driver which produced 1024x768 resolution - horrible!
>
> I am running sid/unstable as I assume you are also. So, when the update
> to xorg 7.0 arrived, I found the old proprietary driver did not work.
> Actually, many things did not work. I had to do a completely new
> installation (separate /home partition so I lost nothing there). The
> move to the official Debian mirrors took place about that time, so I
> don't blame the disaster on the xorg upgrade alone. Never the less, when
> I got the new installation running, I found the ATI stuff (binary and
> source) would not work. So I was without a GUI for a week or so until
> the xserver-xorg-video-ati (6.5.8.0-1) module became available.
>
> xorg 7.x is apparently excuciatingly modular. Actually, I think this is
> the greatest thing since sliced bread. Unfortunately, the transition
> left me hanging out to dry for a week or ten days.
>
> The xserver-xorg-video-ati does not do 3D effects, so if that is what
> your are seeking, you will have to pursue the fglxr proprietary driver,
> at least for now. I do hope the xorg people (and the rest of us) can
> convince the ATI leadership that FOSS/GPL is the way to go.
>
> Grüße, fgd
>
> Hans wrote:
> > Hello all,
> >
> > does anyone got Xorg7.0 and ATI Card X700 (or similar) with ATI´s "fglrx"
> > driver running ? I do, but without acceleration. Does anyone have
> > acceleration got working on a pure 64-bit-system ?
> >
> > If yes, I would like to see his entries in xorg.conf.
> >
> > For me the driver works only without the kernel-module. If I start with
> > the kernel-module (this one starts fine), my screen becomes blank.
> >
> > I suppose, the proprietrary driver part is 32-bit, the built one
> > kernel-module is 64-bit. So tehey will not play together. Could that be ?
> >
> > (My ATI-driver version is 8.24.8)
> >
> >
> > Best regards
> >
> > Hans
>
> --
> Fielder George Dowding, Chief Iceworm.^.   Debian/GNU Linux
> dba Iceworm Enterprises, Anchorage, Alaska   /v\   "etch" Testing
> Since 1976 - Over 30 Years of Service.  /( )\  User Number 269482
> ^^-^^  "irad" 301256

Re: install-mbr on amd64?

[Goswin von Brederlow]

Kilian <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> tag 330190 + patch
>> thanks
>> Kilian <[EMAIL PROTECTED]> writes:
>>
>>> Dear All,
>>>
>>> I'm trying to set up a software RAID 1 (two disks) with Debian on a
>>> system with an AMD x86_64 Athlon processor. To install the MBR on both
>>> discs, I need install-mbr (http://packages.debian.org/stable/base/mbr)
>>> if I'm correct, but this package does not exist in the amd64 port... I
>>> then tried to compile it myself, which fails, obviously, because the
>>> package has not been ported to x86_64 yet as it seems (and I lack the
>>> knowledge to do so...).
>>>
>>> I'm a bit stuck now.. what other tools can I use?
>>>
>>> Thanks for any hint!
>>>
>>> Greetz,
>>> Kilian
>> I went ahead and fixed mbr up for amd64. Apart from the obvious
>> (Build-depends, gcc -m32) I also fixed up some of the more serious
>> warnings and included running the testsuite as much as possible.
>> The package compiles but someone has to risk his/her system and
>> install the mbr now.
>
> Thanks a lot for your work! I'd be willing to do that, unfortunately
> it doesn't compile on my box; I get:
>
> Making all in harness
> make[1]: Entering directory `/usr/local/src/mbr-1.1.5.orig/harness'
> gcc -DPACKAGE=\"mbr\" -DVERSION=\"1.1.5\"  -I. -I.  -Wall
> -Wstrict-prototypes -Wmissing-prototypes -g -c bios.c

Did you apply the patch?

This should be "gcc -m32" there. Without it it will create 64bit code
which won't work.

> In file included from bios.c:2:
> vm86.h:4:22: asm/vm86.h: No such file or directory

sh-3.1# cat /usr/include/asm/vm86.h 
/* All asm/ files are generated and point to the corresponding
 * file in asm-x86_64 or asm-i386.
 */

#ifdef __i386__
# include 
#else
# error This header is not available for x86_64
#endif

sh-3.1# dpkg -S /usr/include/asm/vm86.h 
linux-kernel-headers: /usr/include/asm/vm86.h

And you don't seem to be on sid. I don't have that file either on
sarge so it won't work there.

http://mrvn.homeip.net/mbr/mbr_1.1.5-2.1_amd64.deb

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: updated howto

[Francesco Pietra]

I forgot to mention that the Tyan bears also a scsi card for an external HD, 
CD, scanner (a set to be exchanged with the 32bit PC). I imagine that this 
scsi card has to be configured into the chroot as described below. Correct?

Hi Roberto:
Thanks again. I regret now asking what has already been answered on this list 
but I can't trace where.

Finally I got all parts, so that I assembled the workstation with two amd64 
opterons on TyanK8WE S2895 and a couple of HD (for raid1).

Basically it is an OS installation for chemical calculations, and therefore 
pure amd64 debian to gain in floating point. However, it may also be a 
resource should my PC (i386 debian testing/unstable) stop running. Therefore, 
I also plan to have a chroot installation of 32bit programs. I do not 
remember if KDE is 64bit or has to be out into this chroot.

That said, should I point directly to 
http://www.debian.org/devel/debian-installer/
or
http://www.debian.org/debian-installer/
and, once installed Sarge, do upgrading to testing? 

If you patient enough, which files should I download to build an iso and than 
make a bootable installer CD? I have a fst connection to internet to complete 
a net installation. These problems arise with people, like me, that come to 
installations seldom, forgetting steps that more or less they were already 
passed through.

Thanks a lot
Francesco Pietra


On Friday 12 May 2006 10:46, Roberto Pariset wrote:
> Francesco Pietra wrote:
> > Having to install debian amd64 on opeton/tyan, may i ask whether this is
> > the latest complete guideline, or should it anyway be in part updated?
> > thank you
> > francesco pietra
>
> Yes, go for it. Some things still need to be updated, but I believe it's
> not misleading. Good luck with your new installation and check the IRC
> channel if real time support is needed.
> Roberto


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Goswin von Brederlow]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> Hi,
>
>> I'm not suggesting splitting the dirs. Just the way the link is setup.
>> 
>> I'm suggesting creating it in the maintainer scripts instead of the
>> data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
>> libc6 unupgradable.
>
> On debootstrap install, libc6 postinst isn't actually ran that early,
> and if this change is made, probably require some hacks within
> debootstrap/cdebootstrap.
>
>
> regards,
>   junichi

Yes, preinst (or postinst) would have to "mv /lib64/* /lib/;
/lib/ld-linux.so.* ln -s lib /lib64" and the same for /usr/lib64.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Lennart Sorensen]

On Fri, May 19, 2006 at 04:29:36PM +0200, Goswin von Brederlow wrote:
> You have to trick grub-install. Say /boot is on /dev/md0, a raid1 of
> /dev/sda1 and /dev/sdb1. Then you can put /dev/sda1 into devices.map,
> instal-grub, repeat for sdb1. You might have to change fstab and/or
> mtab as well. Can't remeber if that is truely needed.
> 
> But grub-install also has some special code for raids. Why it doesn't
> work or isn't good enough should be someones TODO. Maybe we could make
> that a NM job :)

grub-install works fine here with /boot on a raid1.  It has ever since
sarge was released (raid1 support was added sometime in early 2005 it
seems).  No tricks required.

Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: More libs for libc6-i386?

[Goswin von Brederlow]

Graham Cobb <[EMAIL PROTECTED]> writes:

> Goswin,
>
> Are you accepting requests for more libs to be included in the libc6-i386 
> package?  Should I submit a bug report or something?
>
> The particular libraries I am looking for (at the moment) are:
>
> libssl.so.0.9.8
> libcrypto.so.0.9.8
>
> Graham

libc6-i386 will only ever include libc6.

You mean ia32-libs and yes I do (via bugreports to ia32-libs).

You should include why you want them included. What software needs
them?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Kilian]

Goswin von Brederlow wrote:

tag 330190 + patch
thanks

Kilian <[EMAIL PROTECTED]> writes:


Dear All,

I'm trying to set up a software RAID 1 (two disks) with Debian on a
system with an AMD x86_64 Athlon processor. To install the MBR on both
discs, I need install-mbr (http://packages.debian.org/stable/base/mbr)
if I'm correct, but this package does not exist in the amd64 port... I
then tried to compile it myself, which fails, obviously, because the
package has not been ported to x86_64 yet as it seems (and I lack the
knowledge to do so...).

I'm a bit stuck now.. what other tools can I use?

Thanks for any hint!

Greetz,
Kilian


I went ahead and fixed mbr up for amd64. Apart from the obvious
(Build-depends, gcc -m32) I also fixed up some of the more serious
warnings and included running the testsuite as much as possible.

The package compiles but someone has to risk his/her system and
install the mbr now.


Thanks a lot for your work! I'd be willing to do that, unfortunately it 
doesn't compile on my box; I get:


Making all in harness
make[1]: Entering directory `/usr/local/src/mbr-1.1.5.orig/harness'
gcc -DPACKAGE=\"mbr\" -DVERSION=\"1.1.5\"  -I. -I.  -Wall 
-Wstrict-prototypes -Wmissing-prototypes -g -c bios.c

In file included from bios.c:2:
vm86.h:4:22: asm/vm86.h: No such file or directory
bios.c: In function `handle_int_10':
bios.c:73: error: dereferencing pointer to incomplete type
[...]
bios.c: In function `handle_int_e4':
bios.c:243: error: dereferencing pointer to incomplete type
bios.c:243: error: dereferencing pointer to incomplete type
make[1]: *** [bios.o] Error 1
make[1]: Leaving directory `/usr/local/src/mbr-1.1.5.orig/harness'
make: *** [all-recursive] Error 1

Obviously, asm/vm86.h is not found; I located this file in 
/usr/include/i386-linux/asm, tried to be ugly and changed the include 
statement in bios.c to the full path of vm86.h, but then I get:


Making all in harness
make[1]: Entering directory `/usr/local/src/mbr-1.1.5.orig/harness'
gcc -DPACKAGE=\"mbr\" -DVERSION=\"1.1.5\"  -I. -I.  -Wall 
-Wstrict-prototypes -Wmissing-prototypes -g -c bios.c

bios.c: In function `handle_int_13':
bios.c:103: error: `CF' undeclared (first use in this function)
bios.c:103: error: (Each undeclared identifier is reported only once
bios.c:103: error: for each function it appears in.)
bios.c: In function `handle_int_16':
bios.c:214: error: `ZF' undeclared (first use in this function)
make[1]: *** [bios.o] Error 1
make[1]: Leaving directory `/usr/local/src/mbr-1.1.5.orig/harness'
make: *** [all-recursive] Error 1

I'm really sorry but my knowledge does not go that far as making a smart 
interpretation of the above... can you help?


Linux 2.6.8-11-amd64-k8, x86_64, Debian Sarge, gcc version 3.3.5 (Debian 
1:3.3.5-13)


Thanks a lot!

-- Kilian


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Goswin von Brederlow]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Fri, May 19, 2006 at 04:29:36PM +0200, Goswin von Brederlow wrote:
>
>> You have to trick grub-install. Say /boot is on /dev/md0, a raid1 of
>> /dev/sda1 and /dev/sdb1. Then you can put /dev/sda1 into devices.map,
>> instal-grub, repeat for sdb1. You might have to change fstab and/or
>> mtab as well. Can't remeber if that is truely needed.
>
> ... and that's why I do not use grub whith software raid. It is much
> more awkward to set up than lilo, there is no documentation, and it is
> less reliable. Lilo at least displays some letters when something goes
> wrong so you know what did you do wrong; grub just hangs without any
> messages at all.
>
> If you want fancy boot, go with grub. If you want reliable boot from an
> md device, go with lilo.
>
> Gabor

Lilo can't boot because of bios checksum errors. Ever since then I use
grub.

I think I will look into grub stage0 code and grub-install concerning
raid support this weekend. It really can't be that hard to patch in
better support for it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Junichi Uekawa]

Hi,

> I'm not suggesting splitting the dirs. Just the way the link is setup.
> 
> I'm suggesting creating it in the maintainer scripts instead of the
> data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
> libc6 unupgradable.

On debootstrap install, libc6 postinst isn't actually ran that early,
and if this change is made, probably require some hacks within
debootstrap/cdebootstrap.


regards,
junichi
-- 
[EMAIL PROTECTED],debian.org}


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rxvt won't start

[Mike Reinehr]

On Sunday 07 May 2006 12:02 pm, Russ Cook wrote:
> Russ Cook wrote:
> > Gnu-Raiz wrote:
> >> On Friday 28 April 2006 15:48, Russ Cook wrote:
> >>> Aaron M. Ucko wrote:
>  Russ Cook <[EMAIL PROTECTED]> writes:
> > I'm running gnome.  From a xterminal, I try to start rxvt, and
> > get this message:
> > rxvt: can't load color "Black"
> > rxvt: can't load color "Black"
> > rxvt: aborting
> >
> > Has anyone seen this problem, and can you tell me what I
> > should check?
> 
>  You may have managed to hit http://bugs.debian.org/343389 . Try
>  reinstalling the x11-common package with dpkg
>  --force-confmiss:
> 
>  dpkg -i --force-confmiss
>  /var/cache/apt/archives/x11-common_*.deb
> >>>
> >>> Aaron,
> >>>   Thank you for the reply.  I did as you suggested, but the error
> >>> remains the same.
> >>> Thanks though!
> >>
> >> Is their any special reason your using rxvt? You can make the changes
> >> to x-term to make it look exactly like rxvt!
> >> Example code:
> >>
> >> xterm -sb -sl 200 -leftbar -fg black -bg white &
> >>
> >> I do agree that if rxvt does not work right maybe you should file a
> >> bug report.  If I remember correctly rxvt is a subset to xterm, and
> >> might not have implemented everything yet.
> >>
> >> Gnu_Raiz
> >
> > Gnu_Raiz,
> >  Thank you for your reply.  Below is what the system tells me when I
> > executed the command
> > string you suggested, from within a Konsole window.  It appears I have
> > a configuration problem of some sort.
> >
> > [EMAIL PROTECTED]:~$ xterm -sb -sl 200 -leftbar -fg black -bg white &
> > [1] 7723
> > [EMAIL PROTECTED]:~$ Warning: Color name "white" is not defined
> > Warning: Cannot convert string "nil2" to type FontStruct
> > Warning: Unable to load any usable ISO8859 font
> > Warning: Unable to load any usable ISO8859 font
> > Warning: Color name "black" is not defined
> > xterm: Cannot allocate color green
> > xterm: Cannot allocate color red
> >
> > [1]+  Donexterm -sb -sl 200 -leftbar -fg black -bg
> > white
>
> After a recent 'apt-get upgrade' with no change to my sources.list file,
> rxvt now works.  I have no idea what has changed, but I'm now a 'happy
> camper'.

Sorry for the late response, but I've been out of town & have gotten way 
behind on this list.

IIRC I had similar problem on an I386 system a month or two ago which turned 
out to have a simple answer. The file /etc/X11/rgb.txt had gone missing. 
Reinstalling x11-common did not solve the problem, but copying the file over 
from another system did.

Cheers!

cmr
-- 
Debian 'Sarge': Registered Linux User #241964

"More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: updated howto

[Francesco Pietra]

Hi Roberto:
Thanks again. I regret now asking what has already been answered on this list 
but I can't trace where.

Finally I got all parts, so that I assembled the workstation with two amd64 
opterons on TyanK8WE S2895 and a couple of HD (for raid1).

Basically it is an OS installation for chemical calculations, and therefore 
pure amd64 debian to gain in floating point. However, it may also be a 
resource should my PC (i386 debian testing/unstable) stop running. Therefore, 
I also plan to have a chroot installation of 32bit programs. I do not 
remember if KDE is 64bit or has to be out into this chroot.

That said, should I point directly to 
http://www.debian.org/devel/debian-installer/
or
http://www.debian.org/debian-installer/
and, once installed Sarge, do upgrading to testing? 

If you patient enough, which files should I download to build an iso and than 
make a bootable installer CD? I have a fst connection to internet to complete 
a net installation. These problems arise with people, like me, that come to 
installations seldom, forgetting steps that more or less they were already 
passed through.

Thanks a lot
Francesco Pietra


On Friday 12 May 2006 10:46, Roberto Pariset wrote:
> Francesco Pietra wrote:
> > Having to install debian amd64 on opeton/tyan, may i ask whether this is
> > the latest complete guideline, or should it anyway be in part updated?
> > thank you
> > francesco pietra
>
> Yes, go for it. Some things still need to be updated, but I believe it's
> not misleading. Good luck with your new installation and check the IRC
> channel if real time support is needed.
> Roberto


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 repository for debian-marillat

[Greg Madden]

On Friday 19 May 2006 05:50, Gerardo E. Bossi wrote:
> debian-marillat

google 'debian-marillat' 
-- 
Greg Madden


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Gabor Gombas]

On Thu, May 18, 2006 at 07:05:56PM +0200, Goswin von Brederlow wrote:

> I went ahead and fixed mbr up for amd64. Apart from the obvious
> (Build-depends, gcc -m32) I also fixed up some of the more serious
> warnings and included running the testsuite as much as possible.
> 
> The package compiles but someone has to risk his/her system and
> install the mbr now.

Heh, I downloaded the mbr source yesterday and hoped to be able to do
the same this weekend, but it seems I'm already late :-)

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Gabor Gombas]

On Fri, May 19, 2006 at 04:29:36PM +0200, Goswin von Brederlow wrote:

> You have to trick grub-install. Say /boot is on /dev/md0, a raid1 of
> /dev/sda1 and /dev/sdb1. Then you can put /dev/sda1 into devices.map,
> instal-grub, repeat for sdb1. You might have to change fstab and/or
> mtab as well. Can't remeber if that is truely needed.

... and that's why I do not use grub whith software raid. It is much
more awkward to set up than lilo, there is no documentation, and it is
less reliable. Lilo at least displays some letters when something goes
wrong so you know what did you do wrong; grub just hangs without any
messages at all.

If you want fancy boot, go with grub. If you want reliable boot from an
md device, go with lilo.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

More libs for libc6-i386?

[Graham Cobb]

Goswin,

Are you accepting requests for more libs to be included in the libc6-i386 
package?  Should I submit a bug report or something?

The particular libraries I am looking for (at the moment) are:

libssl.so.0.9.8
libcrypto.so.0.9.8

Graham


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Gabor Gombas]

On Thu, May 18, 2006 at 08:02:11AM -0400, Scott Reese wrote:

> You don't say what boot loader you're using, but if you are using grub,
> you can simply install the MBR to the second disk using the grub terminal.

I needed install-mbr when I wanted to kill grub in favor of lilo a few
weeks ago. The solution was to boot from a 32-bit Knoppix CD and run
install-mbr from there.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Gabor Gombas]

On Fri, May 19, 2006 at 10:58:33AM +0200, Goswin von Brederlow wrote:

> Local admins are already allowed to convert directories into links,
> e.g. to move parts ot the directory tree to another disk.

According to Steve Langasek in
Message-ID: <[EMAIL PROTECTED]>
that's not allowed and you should use bind mounts instead.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: counting scsi hosts

[Jim Crilly]

On 05/19/06 01:45:34PM +0200, H. Wilmer wrote:
> Jim Crilly wrote:
> 
> >Reloading a SCSI host driver (i.e. gdth, aic7xxx, etc) will increase the
> >counter, reloading the SCSI core itself (scsi_mod) will reset the counter
> >back to zero.
> 
> There's no such module; I think SCSI support is compiled into the kernel.

That would probably be a valid assumption.

> 
> I would also have compiled the gdth support in, but unfortunately it was 
> only possible to compile it as a module. That in turn required to use an 
> initrd.image :(
> 

Well to even attempt reloading anything you need it as a module, infact I
prefer to make everything possible a module and use an initrd. But in this
case it wouldn't make a difference since you can't umount the filesystem to
be able to reload the module anyway.

> >Are you sure you're using gdth for your root? I thought it was just for
> >SCSI controllers, I didn't know any SATA controllers used chipsets
> >supported by that driver.
> 
> Yes, the Vortex is an SATA RAID controller and needs the gdth module:
> 
> 
> :02:02.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10)
> :03:01.0 RAID bus controller: ICP Vortex Computersysteme GmbH GDT NEWRX
> 
> 
> There are no other disks than those attached to the RAID controller in 
> the server. The only device on the Adaptec is a tape changer.
> 
> 
> I can recommend the Vortex controller, no problems with it in about two 
> years. It's running a RAID5, 1TB on 4 disks plus one spare.
> 
> If a disk fails, it will beep, so you _will_ notice. You replace the 
> disk and that's all. --- I've had a disk failing in another server that 
> also has a Vortex after about 3 months. It beeped and kicked in the 
> spare; the replaced disk is now the spare, so it gets away with only one 
> rebuild.
> 
> 3wares are a little cheaper and work also (no problems except for a disk 
> starting to fail in about 3 years, running RAID1 with two IDE disks), 
> but they don't have a beeper.
> 
> A beeper is definitely worthwhile.
> 
> 
> GH

I was under the false impression that the gdth driver was just for some
older legacy cards, the card definitely sounds nice I'll have to consider
one next time I need a RAID controller.

Jim.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 repository for debian-marillat

[Jonathan Kaye]

Gerardo E. Bossi wrote:

> Could you send me the deb ftp repository for downloading the MP3 files
> for an AMD64 pc. Yours
> Gerardo E. Bossi
Hi Gerardo,
I'm not sure I understand your question. Debian amd64 uses the same mp3
files that every other architecture uses. Do you mean mp3 music tracks? If
so, just get them where you usually get them and use your favourite mplayer
on Debian amd64: xmms, noatun, mplayer, etc.
cheers,
Jonathan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems update libc6

[Goswin von Brederlow]

"Hans-J. Ullrich" <[EMAIL PROTECTED]> writes:

> Hello all,
> I had slight problems to upgrade to libc6-2.3.6-8 as this package did not 
> want 
> to install. Hereby I have a slight understanding problem. Can someone 
> explain, what now is the correct way ?
>
> Short description:
>
> I have a chroot, as described on the debian-AMD64 site. There you wrote:
>
> "You also need a link to your 32bit linker in the /lib path. Change in to 
> directory /lib and create a link to the 32bit linker library of your chroot: 
> (The name of the 64bit linker is ld-linux-x86-64.so.2)"
>
> I did so, when I first installed this computer.

Don't do that. Just install ia32-libs (sarge) or libc6-i386 (etch/sid)
which contain the linker. You probably end up with them installed
anyway for some reason and then the link can only confuse matters.

> Now to upgrade libc6 I had to delete this link, otherwise I could not install 
> the new libc6, and, now the link does not point any more 
> to /var/chroot/sid-ia32/lib/libc-2.3.6 any more, but to /lib/libc-2.3.6-8.

I heard about the libc6 complaining with the manual linking but since
I never did that I never saw it myself. Using the ia32-libs or
libc6-i386 package has no such effect.

> Is this information on the AMD64-site deprecated ?

Just in needs of slight improvements.

> For your information, here the relevant links
>
> 45056040 lrwxrwxrwx  1 root root  11 2006-03-12 19:57 ld-linux-so.2 
> -> 
> ld-2.3.6.so
> 45056030 lrwxrwxrwx  1 root root  11 2006-05-19 14:54 
> ld-linux-x86-64.so.2 -> ld-2.3.6.so
> 45057590 lrwxrwxrwx  1 root root  25 2006-05-02 09:28 
> ld-lsb-x86-64.so.3 -> /lib/ld-linux-x86-64.so.2
>
>
> I want to run 32-bit and 64-bit programs. How is the status now ?
>
> Is chroot still needed ? Should I use chroot any more because it is easier to 
> manage ? 

You can run 32bit programs with ia32-libs. But if you want to use
apt-get to install 32bit programs then you need a chroot. It depends
on what you want to do.

> Please help me to understand the policy after this.
>
> Thanks and best regards
>
> Hans

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Goswin von Brederlow]

"Dmitry I. Kulagin" <[EMAIL PROTECTED]> writes:

> Hi!
> I use ms-sys with "-s" option just a week ago in simular situation.
> As far as I know, you can't indicate grub to load from /dev/md0, only
> lilo can do this.
> And there is no need to recompile the kernel, the debian distributed
> kernel with the yaird as
> initrd creator can load the system in your situation.

You have to trick grub-install. Say /boot is on /dev/md0, a raid1 of
/dev/sda1 and /dev/sdb1. Then you can put /dev/sda1 into devices.map,
instal-grub, repeat for sdb1. You might have to change fstab and/or
mtab as well. Can't remeber if that is truely needed.

But grub-install also has some special code for raids. Why it doesn't
work or isn't good enough should be someones TODO. Maybe we could make
that a NM job :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 repository for debian-marillat

[Gerardo E. Bossi]

Could you send me the deb ftp repository for downloading the MP3 files
for an AMD64 pc. Yours
Gerardo E. Bossi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Problems update libc6

[Hans-J. Ullrich]

Hello all,
I had slight problems to upgrade to libc6-2.3.6-8 as this package did not want 
to install. Hereby I have a slight understanding problem. Can someone 
explain, what now is the correct way ?

Short description:

I have a chroot, as described on the debian-AMD64 site. There you wrote:

"You also need a link to your 32bit linker in the /lib path. Change in to 
directory /lib and create a link to the 32bit linker library of your chroot: 
(The name of the 64bit linker is ld-linux-x86-64.so.2)"

I did so, when I first installed this computer.

Now to upgrade libc6 I had to delete this link, otherwise I could not install 
the new libc6, and, now the link does not point any more 
to /var/chroot/sid-ia32/lib/libc-2.3.6 any more, but to /lib/libc-2.3.6-8.

Is this information on the AMD64-site deprecated ?

For your information, here the relevant links

45056040 lrwxrwxrwx  1 root root  11 2006-03-12 19:57 ld-linux-so.2 -> 
ld-2.3.6.so
45056030 lrwxrwxrwx  1 root root  11 2006-05-19 14:54 
ld-linux-x86-64.so.2 -> ld-2.3.6.so
45057590 lrwxrwxrwx  1 root root  25 2006-05-02 09:28 
ld-lsb-x86-64.so.3 -> /lib/ld-linux-x86-64.so.2


I want to run 32-bit and 64-bit programs. How is the status now ?

Is chroot still needed ? Should I use chroot any more because it is easier to 
manage ? 

Please help me to understand the policy after this.

Thanks and best regards

Hans



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Stephen Frost]

* Aurelien Jarno ([EMAIL PROTECTED]) wrote:
> The FHS is actually not very clear, as it says 64-bit libraries should 
> be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib. 
> This is a contradiction for a pure 64-bit system.

The FHS is very clear about the path to the 64bit linker, and that goes
through /lib64, getting rid of that isn't an option.

> - I am not sure that creating the link in postinst will work. Creating 
> it in preinst looks safer to me.

I'd be a little nervous about creating it in postinst too, honestly.

> - If you can install files in (/usr)/lib64, the files will end up in 
> (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other 
> tools won't work correctly.

Yeah, I'm not sure it really makes sense to need to install into both...
It would have been much more useful for you to include the *reasoning*
behind Goswin's request rather than just your reasons for not wanting to
do what he's asking.

> - If you have two packages providing the same files in (/usr)/lib and 
> (/usr)/lib64, then the files will be overwritten without warning. This 
> is IMHO not acceptable.

My guess is that his intent was actually to allow *seperate* packages to
install into either /lib or /lib64 on a package-by-package basis.  This
might resolve some bugs in packages which, when they detect they're
being compiled for amd64, default to installing into /lib64 instead of
/lib.  Personally I think that's something that just needs to be dealt
with and those packages should be fixed but that's my guess as to where
the question came from.  It's also possible a given package wants to
install some things in /lib64 (say, actual libraries) and other things
in /lib (say, helper programs, ala blah-config).

> Could you please give me your opinion on that, so that I can take a 
> decision?

The link itself certainly can't go away.  I'd be more inclined to say
"progams on a pure 64bit platform shouldn't install into /lib64" than to
have some things installing into /lib and others into /lib64.  Part of
this comes from the concern that this will bring out other bugs in
packages where having this distinction might cause overlaps as mentioned
above.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: counting scsi hosts

[H. Wilmer]

Jim Crilly wrote:


Reloading a SCSI host driver (i.e. gdth, aic7xxx, etc) will increase the
counter, reloading the SCSI core itself (scsi_mod) will reset the counter
back to zero.


There's no such module; I think SCSI support is compiled into the kernel.

I would also have compiled the gdth support in, but unfortunately it was 
only possible to compile it as a module. That in turn required to use an 
initrd.image :(



Are you sure you're using gdth for your root? I thought it was just for
SCSI controllers, I didn't know any SATA controllers used chipsets
supported by that driver.


Yes, the Vortex is an SATA RAID controller and needs the gdth module:


:02:02.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10)
:03:01.0 RAID bus controller: ICP Vortex Computersysteme GmbH GDT NEWRX


There are no other disks than those attached to the RAID controller in 
the server. The only device on the Adaptec is a tape changer.



I can recommend the Vortex controller, no problems with it in about two 
years. It's running a RAID5, 1TB on 4 disks plus one spare.


If a disk fails, it will beep, so you _will_ notice. You replace the 
disk and that's all. --- I've had a disk failing in another server that 
also has a Vortex after about 3 months. It beeped and kicked in the 
spare; the replaced disk is now the spare, so it gets away with only one 
rebuild.


3wares are a little cheaper and work also (no problems except for a disk 
starting to fail in about 3 years, running RAID1 with two IDE disks), 
but they don't have a beeper.


A beeper is definitely worthwhile.


GH


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: install-mbr on amd64?

[Dmitry I. Kulagin]

Hi!
I use ms-sys with "-s" option just a week ago in simular situation.
As far as I know, you can't indicate grub to load from /dev/md0, only 
lilo can do this.
And there is no need to recompile the kernel, the debian distributed 
kernel with the yaird as

initrd creator can load the system in your situation.



Thanks a lot for your reply!

I'm using lilo as bootloader, but as grub is way more modern, I might 
just switch to grub.


The thing is, the machine I'm working on is remote and I have no 
console access, so everything is a bit tricky. It's already running, 
has two identical SATA disks, the second one (sdb) is not used. What I 
want to do is create a RAID 1 array with only sdb (but with the 
possibility to add sda later). Then I boot from this new RAID array, 
repartition sda and add it to the RAID array. I've gotten so far as 
setting up the RAID array, chrooting into it and bootstrap a Debian 
system on it, compile an new kernel, but when it comes to set up 
bootloaders, the howto I'm using  
tells me to run:


 $ lilo
 $ install-mbr /dev/sda
 $ install-mbr /dev/sdb

Do you think I could accomplish the same result by only using grub?

-- Kilian






--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
   -- Benjamin Franklin, 1759


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

issues with vim 7

[Andrei Mikhailovsky]

Hello,

Is it only me or there are some problems with the new vim 7? I've
replaced my config file with the default one that comes with the
package. The syntax highlighting no longer works and it doesn't save the
position of line in the files, so every time i open a document, it
always positions the cursor on the first line.

Is it likely to be the problem with the default config file or the vim
itself?

Many thanks

Andrei


signature.asc
Description: This is a digitally signed message part

Re: how to help building amd64 d-i images

[Geert Stappers]

On Thu, May 18, 2006 at 11:25:42AM +0200, Bjoern Boschman wrote:
> 
> Geert: Sorry I did not know about those logfiles - I thought the images 
> are really build _daily_.
> 

No worries mate!

It did took me a month to find out that d-i for amd64 was not build.
I have no clue how many people made the same mistake,
meanwhile it is visable at http://wiki.debian.org/DebianInstaller/Today
( dated april 9th ) With some luck it will now be noticed.


> How may I support making daily d-i builds?

Good question.

IMO is the problem that it is not visible what is going on.
There is now http://wiki.debian.org/DebianInstaller/Amd64Todo
to help making visisble what is done and what is needed (beside patience)

Start building d-i as documented
on http://wiki.debian.org/DebianInstaller/Build and update
the d-i wiki page Amd64Todo


Cheers
Geert Stappers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Andreas Jochens]

On 06-May-19 11:02, Goswin von Brederlow wrote:
> Andreas Jochens <[EMAIL PROTECTED]> writes:
> > Anything which makes it easier to violate this simple policy
> > will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently
> > to problems which could be difficult to disentangle later.
> 
> The goal would be to actualy get everything into (/usr)/lib64 while
> intermittendly allowing a mixed usage. That would allow for FHS
> compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*,
> lib32asound, ia32-libs and more to come.

Yes, I understand that it is your goal get everything into /usr/lib64.

But this means that every single library package has to be changed to 
use /usr/lib64 instead /usr/lib. You will probably not achieve that in 
an etch or even in an etch+1 time frame. You will just get an ugly
mixture of /usr/lib and /usr/lib64 usage.

If you really want to do this, I suggest that you set up a test archive
and convert everything to use /usr/lib64 and collect all the patches
that are necessary to achieve this. Then these patches can be reviewed
and it can be decided if this is the way to go. However, this has been 
tried before. The result was that this does not work well.

Regards
Andreas Jochens


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Goswin von Brederlow]

Andreas Jochens <[EMAIL PROTECTED]> writes:

> Hello Aurelien,
>
> On 06-May-19 04:15, Aurelien Jarno wrote:
>> [Ccing: amd64 and dpkg developers as they are concerned by this subject]
>> Currently the (/usr)/lib64 -> /lib symlink is shipped in the libc6 
>> package. Goswin von Brederlow asked for this link to be created in the 
>> postinst instead, so that packages could install files in both 
>> (/usr)/lib and (/usr)/lib64 directories.
>> 
>> 
>> Could you please give me your opinion on that, so that I can take a 
>> decision?
>
> please do not change the status quo regarding the lib64 symlinks.
>
> During the porting of Debian to amd64 quite a few alternatives
> regarding the lib64 issue were discussed and tested. The biarch approach 
> with /usr/lib and /usr/lib64 as two different directories failed badly.

I'm not suggesting splitting the dirs. Just the way the link is setup.

I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.

>> I have concerns about that:
>> - I don't really want to add something specific to amd64 in postinst. 
>> But ok, that's not an argument.
>> - I am not sure that creating the link in postinst will work. Creating 
>> it in preinst looks safer to me.
>> - If you can install files in (/usr)/lib64, the files will end up in 
>> (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other 
>> tools won't work correctly.
>> - If you have two packages providing the same files in (/usr)/lib and 
>> (/usr)/lib64, then the files will be overwritten without warning. This 
>> is IMHO not acceptable.
>
> I share these concerns.
>
>
> The current policy which requires all packages to install native 
> amd64 libraries in /usr/lib is simple and sane. This should not be
> changed. 
>
> Anything which makes it easier to violate this simple policy
> will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently
> to problems which could be difficult to disentangle later.

The goal would be to actualy get everything into (/usr)/lib64 while
intermittendly allowing a mixed usage. That would allow for FHS
compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*,
lib32asound, ia32-libs and more to come.

> This is just my personal opinion.
>
> Regards
> Andreas Jochens

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Goswin von Brederlow]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> Currently the (/usr)/lib64 -> /lib symlink is shipped in the libc6
> package. Goswin von Brederlow asked for this link to be created in the
> postinst instead, so that packages could install files in both
> (/usr)/lib and (/usr)/lib64 directories.
>
> I have concerns about that:
> - I don't really want to add something specific to amd64 in
> postinst. But ok, that's not an argument.
> - I am not sure that creating the link in postinst will work. Creating
> it in preinst looks safer to me.

yes.

> - If you can install files in (/usr)/lib64, the files will end up in
> (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other
> tools won't work correctly.

Local admins are already allowed to convert directories into links,
e.g. to move parts ot the directory tree to another disk.

We had problems with that for the (/usr)/lib32 link used on amd64 and
for example dpkg-shlibs was afaik patched to deal with it
correctly. dpkg -S isn't but that could/should be fixed.

> - If you have two packages providing the same files in (/usr)/lib and
> (/usr)/lib64, then the files will be overwritten without warning. This
> is IMHO not acceptable.
>
> Could you please give me your opinion on that, so that I can take a
> decision?
>
> Thanks,
> Aurelien

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]