printscreen key does not work????
Hi, I am trying to get screenshots using printscreen and alt+printscreen as per Gnome manual. But for some reason it does not work. It looks as if the printscreen key is disabled: I can assign the functionality to other keys and they work. How do I get my printscreen key working? TIA Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl
RE: printscreen key does not work????
Is there an equivalent to KDE's ksnapshot within Gnome. Ksnapshot rocks!!! -Original Message- From: Joost Kraaijeveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 17, 2006 11:05 PM To: Debian-Amd64 (E-mail) Cc: Debian users (E-mail) Subject: printscreen key does not work Hi, I am trying to get screenshots using printscreen and alt+printscreen as per Gnome manual. But for some reason it does not work. It looks as if the printscreen key is disabled: I can assign the functionality to other keys and they work. How do I get my printscreen key working? TIA Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
install-mbr on amd64?
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
Kilian wrote: 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? 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. Run grub, then from the grub prompt (and assuming your boot partition is the first partition on the disk): MBR on the first disk: grub root (hd0,0) grub setup (hd0) MBR on the second disk: grub root (hd1,0) grub setup (hd1) And then you're done: grub quit Grub supports tab completion, so if you put in grub root (hd and hit the tab key, it will show the valid drive numbers. It will do the same for the partitions if you hit tab after: grub root (hd1, to help you pick the correct partition. Remember, all numbers are zero-origin, so if the parition holding /boot is /dev/sda1, its partition number will be 0 in grub. And, as always, a bootable grub disk as a safety measure is highly recommended. -Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
Scott Reese wrote: Kilian wrote: 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? 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. 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 http://juerd.nl/site.plp/debianraid 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: printscreen key does not work????
On Thu, May 18, 2006 at 08:05:12 +0200, Joost Kraaijeveld wrote:
Hi,
I am trying to get screenshots using printscreen and
alt+printscreen as per Gnome manual. But for some reason it does not
work. It looks as if the printscreen key is disabled: I can assign
the functionality to other keys and they work.
How do I get my printscreen key working?
You probably have a keyboard misconfiguration. The first step to
diagnose it is running xev from a terminal window. It will show you
the events which are registered by X when you press and release a key.
I get the following for my PrtSc key:
KeyPress event, serial 31, synthetic NO, window 0x281,
root 0x7e, subw 0x0, time 1196949250, (168,-13), root:(219,14),
state 0x0, keycode 111 (keysym 0xff61, Print), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 31, synthetic NO, window 0x281,
root 0x7e, subw 0x0, time 1196949427, (168,-13), root:(219,14),
state 0x0, keycode 111 (keysym 0xff61, Print), same_screen YES,
XLookupString gives 0 bytes:
The first thing to check is therefore if the key is also registered as
Print on your system. The output of the following two commands
xmodmap
cat /etc/X11/{XF86Config-4,xorg.conf} | awk '/Section
InputDevice/,/EndSection/'
will also help to track down the problem.
--
Regards,
Florian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Jim Crilly wrote: It seems to be normal, but I'd probably still say it's a bug in the SCSI system. It is possible to reset the number by reloading the scsi_mod module, but you have to umount all of the SCSI filesystems to do that so it's not a great solution. Unloading the SCSI module is what I did, and the counter is increased each time I reload the module. But there's also the gdth module for the SATA RAID controller, generating SCSI devices, which cannot be unloaded unless the server could run diskless ... GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: printscreen key does not work????
Hi Florian,
Florian Kulzer wrote:
You probably have a keyboard misconfiguration. The first step to
diagnose it is running xev from a terminal window. It will show you
the events which are registered by X when you press and release a key.
I get the following for my PrtSc key:
KeyPress event, serial 31, synthetic NO, window 0x281,
root 0x7e, subw 0x0, time 1196949250, (168,-13), root:(219,14),
state 0x0, keycode 111 (keysym 0xff61, Print), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 31, synthetic NO, window 0x281,
root 0x7e, subw 0x0, time 1196949427, (168,-13), root:(219,14),
state 0x0, keycode 111 (keysym 0xff61, Print), same_screen YES,
XLookupString gives 0 bytes:
This are my results, which seems to suggest that the key as such is recognised.
I can also use the printscreen key to configure it with the Gnome applet to
define Keyboard Shortcuts.
KeyPress event, serial 26, synthetic NO, window 0x361,
root 0x64, subw 0x362, time 20138966, (57,36), root:(1713,117),
state 0x10, keycode 111 (keysym 0xff61, Print), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x361,
root 0x64, subw 0x362, time 20139090, (57,36), root:(1713,117),
state 0x10, keycode 111 (keysym 0xff61, Print), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
xmodmap
cat /etc/X11/{XF86Config-4,xorg.conf} | awk '/Section
InputDevice/,/EndSection/'
OK.
What I also noticed (and it may be related) is that I cannot assign the
eurosign to the 5 key. As soon as I enter that in the Gnome Keyboard applet,
Gnome restarts and I cannot login anymore. I have to edit the gconf.xml file an
remove the configuration. Changing my keybord from U.S. English to US intl is
also impossible.
TIA
Groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: [EMAIL PROTECTED]
web: www.askesis.nl
nForce3 /usbstorage : deadly slow
I have a problem with my debian system on my Asus K8N board, which is nForce3 250 based:whenever i plug in a USB2.0-enabled storage device (in my case recently a 1GB Creative Muvo TX SE), the kernel recognizes it as USB-2.0 device, the ehci_hcd module gets loaded, usbview and all other sources tell me that it is a 480MB/s device : Speed: 480Mb/s (high) USB Version: 2.00But: I never even reach a transfer rate of 800kB/s (which would only be 1/600 of the maximum thinkable speed). Instead, it writes files with about 200 kB/s, until after a few seconds, the transfer rate collapses to 80kB/s, which is not only bad but ugly. On the same machine, booted with an i386 2.6-kernel from CDROM (Knoppix 4.0.1), the device is only recognized as USB1.1 full speed device, but still transfers a lot faster than under debian/amd64.I examined my loaded modules and wasn't able to make out any chipset-specific modules, only some i2c-nforce modules (lsmod output attached), are there any modules I have to load /unload to make it work or do You have any other suggestion? Thanks,Marcus Müller Module Size Used by nls_iso8859_1 5568 1 nls_cp437 7296 1 vfat 13440 1 fat51824 1 vfat sd_mod 17880 2 vmnet 30552 7 vmmon 181944 0 binfmt_misc12176 1 thermal15308 0 fan 5384 0 button 7840 0 processor 24600 1 thermal ac 5704 0 battery10760 0 lp 12864 0 ipv6 252256 17 reiserfs 226352 3 dm_mod 53800 0 nvram 8392 0 i2c_dev10720 0 msr 3976 0 nvidia 4856084 18 aes27112 0 cryptoloop 4288 0 loop 15760 1 cryptoloop it87 24356 0 hwmon_vid 3008 1 it87 i2c_isa 5952 1 it87 ide_generic 1600 0 [permanent] usb_storage80128 1 usbhid 34720 0 snd_intel8x0 34536 1 snd_ac97_codec102012 1 snd_intel8x0 snd_ac97_bus2880 1 snd_ac97_codec analog 10784 0 snd_pcm_oss51296 0 snd_mixer_oss 17472 1 snd_pcm_oss psmouse39308 0 i2c_nforce2 7808 0 serio_raw 7748 0 ide_cd 40224 1 cdrom 36280 1 ide_cd gameport 15824 1 analog snd_mpu401 9440 0 snd_mpu401_uart 7872 1 snd_mpu401 snd_pcm89932 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss i2c_core 23064 4 i2c_dev,it87,i2c_isa,i2c_nforce2 shpchp 45120 0 pci_hotplug11716 1 shpchp forcedeth 23876 0 ehci_hcd 30344 0 ohci_hcd 19716 0 parport_pc 36592 1 parport38860 2 lp,parport_pc snd_rawmidi26400 1 snd_mpu401_uart snd_seq_device 9744 1 snd_rawmidi snd_timer 23944 1 snd_pcm snd_page_alloc 11344 2 snd_intel8x0,snd_pcm snd57984 12 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_mpu401,snd_mpu401_uart,snd_pcm,snd_rawmidi,snd_seq_device,snd_timer soundcore 10720 1 snd pcspkr 3784 0 floppy 65664 0 ext3 128272 4 jbd54184 1 ext3 mbcache 9352 1 ext3 ide_disk 16256 9 sata_nv10628 0 libata 60760 1 sata_nv scsi_mod 144856 3 sd_mod,usb_storage,libata amd74xx15280 0 [permanent] generic 5636 0 [permanent] ide_core 139160 6 ide_generic,usb_storage,ide_cd,ide_disk,amd74xx,generic evdev 10944 0
Re: install-mbr on amd64?
On Thursday 18 May 2006 08:41, Kilian wrote:
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
Just install an MBR on one disk, and then use dd to copy it. A master boot
record is always 512 bytes long. Assuming you are using SATA disks and the
MBR was installed on the first, the command would be
# dd if=/dev/sda of=/dev/sdb bs=512 count=1
To test it, shut down cleanly {so the RAID integrity is maintained}, and
physically swap the drives.
--
AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
On Thu, May 18, 2006 at 09:41:27AM +0200, Kilian wrote: 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! I use grub-install /dev/sda and grub-install /dev/sdb. I see no reason for the mbr package on my systems. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
On Thu, May 18, 2006 at 02:18:14PM +0200, Kilian wrote: 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 http://juerd.nl/site.plp/debianraid 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? Unless you also have windows on the system, there is no reason to not put the boot loader in the MBR directly rather than on to one of the partitions. Both lilo and grub can install directly to the MBR and work from there without the install-mbr at all. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nForce3 /usbstorage : deadly slow
Dear Marcus, could you send also the lines in /var/log/messages related to the hardware detection of the usb storage and to the device associated to it? Something similar to: ... May 11 09:25:49 xxx kernel: usb 4-1.1: new high speed USB device using ehci_hcd and address 5 May 11 09:25:49 xxx kernel: Initializing USB Mass Storage driver... May 11 09:25:49 xxx kernel: scsi0 : SCSI emulation for USB Mass Storage devices May 11 09:25:49 xxx kernel: usbcore: registered new driver usb-storage May 11 09:25:49 xxx kernel: USB Mass Storage support registered. May 11 09:25:54 xxx kernel: sda: assuming drive cache: write through May 11 09:25:54 xxx kernel: sda: assuming drive cache: write through May 11 09:25:54 xxx kernel: sda: sda1 ... Ciao Leonardo Marcus Müller wrote: I have a problem with my debian system on my Asus K8N board, which is nForce3 250 based: whenever i plug in a USB2.0-enabled storage device (in my case recently a 1GB Creative Muvo TX SE), the kernel recognizes it as USB-2.0 device, the ehci_hcd module gets loaded, usbview and all other sources tell me that it is a 480MB/s device : Speed: 480Mb/s (high) USB Version: 2.00 But: I never even reach a transfer rate of 800kB/s (which would only be 1/600 of the maximum thinkable speed). Instead, it writes files with about 200 kB/s, until after a few seconds, the transfer rate collapses to 80kB/s, which is not only bad but ugly. On the same machine, booted with an i386 2.6-kernel from CDROM (Knoppix 4.0.1), the device is only recognized as USB1.1 full speed device, but still transfers a lot faster than under debian/amd64. I examined my loaded modules and wasn't able to make out any chipset-specific modules, only some i2c-nforce modules (lsmod output attached), are there any modules I have to load /unload to make it work or do You have any other suggestion? Thanks, Marcus Müller Module Size Used by nls_iso8859_1 5568 1 nls_cp437 7296 1 vfat 13440 1 fat51824 1 vfat sd_mod 17880 2 vmnet 30552 7 vmmon 181944 0 binfmt_misc12176 1 thermal15308 0 fan 5384 0 button 7840 0 processor 24600 1 thermal ac 5704 0 battery10760 0 lp 12864 0 ipv6 252256 17 reiserfs 226352 3 dm_mod 53800 0 nvram 8392 0 i2c_dev10720 0 msr 3976 0 nvidia 4856084 18 aes27112 0 cryptoloop 4288 0 loop 15760 1 cryptoloop it87 24356 0 hwmon_vid 3008 1 it87 i2c_isa 5952 1 it87 ide_generic 1600 0 [permanent] usb_storage80128 1 usbhid 34720 0 snd_intel8x0 34536 1 snd_ac97_codec102012 1 snd_intel8x0 snd_ac97_bus2880 1 snd_ac97_codec analog 10784 0 snd_pcm_oss51296 0 snd_mixer_oss 17472 1 snd_pcm_oss psmouse39308 0 i2c_nforce2 7808 0 serio_raw 7748 0 ide_cd 40224 1 cdrom 36280 1 ide_cd gameport 15824 1 analog snd_mpu401 9440 0 snd_mpu401_uart 7872 1 snd_mpu401 snd_pcm89932 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss i2c_core 23064 4 i2c_dev,it87,i2c_isa,i2c_nforce2 shpchp 45120 0 pci_hotplug11716 1 shpchp forcedeth 23876 0 ehci_hcd 30344 0 ohci_hcd 19716 0 parport_pc 36592 1 parport38860 2 lp,parport_pc snd_rawmidi26400 1 snd_mpu401_uart snd_seq_device 9744 1 snd_rawmidi snd_timer 23944 1 snd_pcm snd_page_alloc 11344 2 snd_intel8x0,snd_pcm snd57984 12 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_mpu401,snd_mpu401_uart,snd_pcm,snd_rawmidi,snd_seq_device,snd_timer soundcore 10720 1 snd pcspkr 3784 0 floppy 65664 0 ext3 128272 4 jbd54184 1 ext3 mbcache 9352 1 ext3 ide_disk 16256 9 sata_nv10628 0 libata 60760 1 sata_nv scsi_mod 144856 3 sd_mod,usb_storage,libata amd74xx15280 0 [permanent] generic 5636 0 [permanent] ide_core 139160 6 ide_generic,usb_storage,ide_cd,ide_disk,amd74xx,generic
Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]
I could send dmesg-output, but I just -err- fixed the problem:I found out that the loss of speed is due to the sync option for mount.I didn't think of mount options at first, but after I tried to format the stick with more obscure file system, the speed went up. So I examined the mount options, and after a few trials I found out that the sync option slowed the whole thing down by about factor 10 (or even more), and disabled it (/etc/usbmount/...).The problem is, that without sync, unplugging an un- umounted device is datacide. umounting the device after transferring 700 MB takes about 24sec, what seems to be long. Any idea why sync is _that_ slow with vfat (fat32)? Does it always have to rewrite the whole both FATs including analyzing the actual contents of the disk whenever a file is written? Well, I can live with having to umount usb-sticks, but I can't let my young relatives use my usbsticks :( Thanks, Marcus MüllerOn 5/18/06, Leonardo Lanzi [EMAIL PROTECTED] wrote: Dear Marcus,could you send also the lines in /var/log/messages related to thehardware detection of the usb storage and to the device associated to it?Something similar to:...May 11 09:25:49 xxx kernel: usb 4-1.1: new high speed USB device usingehci_hcd and address 5May 11 09:25:49 xxx kernel: Initializing USB Mass Storage driver...May 11 09:25:49 xxx kernel: scsi0 : SCSI emulation for USB Mass Storagedevices May 11 09:25:49 xxx kernel: usbcore: registered new driver usb-storageMay 11 09:25:49 xxx kernel: USB Mass Storage support registered.May 11 09:25:54 xxx kernel: sda: assuming drive cache: write throughMay 11 09:25:54 xxx kernel: sda: assuming drive cache: write through May 11 09:25:54 xxx kernel: sda: sda1...CiaoLeonardoMarcus Müller wrote: I have a problem with my debian system on my Asus K8N board, which is nForce3 250 based: whenever i plug in a USB2.0-enabled storage device (in my case recently a 1GB Creative Muvo TX SE), the kernel recognizes it as USB-2.0 device, the ehci_hcd module gets loaded, usbview and all other sources tell me that it is a 480MB/s device : Speed: 480Mb/s (high)USB Version:2.00 But: I never even reach a transfer rate of 800kB/s (which would only be 1/600 of the maximum thinkable speed). Instead, it writes files with about 200 kB/s, until after a few seconds, the transfer rate collapses to 80kB/s, which is not only bad but ugly. On the same machine, booted with an i386 2.6-kernel from CDROM (Knoppix 4.0.1 ), the device is only recognized as USB1.1 full speed device, but still transfers a lot faster than under debian/amd64. I examined my loaded modules and wasn't able to make out any chipset-specific modules, only some i2c-nforce modules (lsmod output attached), are there any modules I have to load /unload to make it work or do You have any other suggestion? Thanks, Marcus Müller ModuleSizeUsed by nls_iso8859_1 55681 nls_cp437 72961 vfat 134401 fat518241 vfat sd_mod 178802 vmnet305527 vmmon 1819440 binfmt_misc121761 thermal153080 fan 53840 button78400 processor246001 thermal ac57040 battery107600 lp 128640 ipv625225617 reiserfs2263523 dm_mod 538000 nvram 83920 i2c_dev107200 msr 39760 nvidia 485608418 aes271120 cryptoloop42880 loop 157601 cryptoloop it87 243560 hwmon_vid 30081 it87 i2c_isa 59521 it87 ide_generic 16000 [permanent] usb_storage801281 usbhid 347200 snd_intel8x0 345361 snd_ac97_codec1020121 snd_intel8x0 snd_ac97_bus28801 snd_ac97_codec analog 107840 snd_pcm_oss512960 snd_mixer_oss174721 snd_pcm_oss psmouse393080 i2c_nforce2 78080 serio_raw 77480 ide_cd 402241 cdrom362801 ide_cd gameport 158241 analog snd_mpu40194400 snd_mpu401_uart 78721 snd_mpu401 snd_pcm899323 snd_intel8x0,snd_ac97_codec,snd_pcm_oss i2c_core 230644 i2c_dev,it87,i2c_isa,i2c_nforce2 shpchp 451200 pci_hotplug117161 shpchp forcedeth238760 ehci_hcd 303440 ohci_hcd 197160 parport_pc 365921 parport388602 lp,parport_pc snd_rawmidi264001 snd_mpu401_uart snd_seq_device97441 snd_rawmidi snd_timer239441 snd_pcm snd_page_alloc 113442 snd_intel8x0,snd_pcm snd5798412 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_mpu401,snd_mpu401_uart,snd_pcm,snd_rawmidi,snd_seq_device,snd_timer soundcore107201 snd pcspkr37840 floppy 656640 ext31282724 jbd541841 ext3 mbcache 93521 ext3 ide_disk 162569 sata_nv106280 libata 607601 sata_nv scsi_mod1448563 sd_mod,usb_storage,libata amd74xx152800 [permanent] generic 56360 [permanent] ide_core1391606 ide_generic,usb_storage,ide_cd,ide_disk,amd74xx,generic evdev109440
Re: Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]
The problem is, that without sync, unplugging an un- umounted device is datacide. umounting the device after transferring 700 MB takes about 24sec, what seems to be long. You can manually run sync to flush stuff out to disk. The long delay you're seeing on unmount is because copying the 700Mb probably kept most of it in cache, and it hadn't finished writing it back by the time you tried to unmount the disk. Any idea why sync is _that_ slow with vfat (fat32)? Does it always have to rewrite the whole both FATs including analyzing the actual contents of the disk whenever a file is written? The sync option ensures the data is always consistent on the drive, so I'm not surprised you're seeing a large slowdown. Each write probably requires several round-trips to update the FAT. Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
Kilian wrote: 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 http://juerd.nl/site.plp/debianraid 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 Without console access to the machine, lilo or grub is going to be something of a moot point because you are going to have to get the configuration correct the first time or you are completely out of luck. The nice thing about grub is that it has a console at boot where you can modify the booting kernel and the parameters, which is nice if you got you /boot/grub/menu.lst wrong in some way. But without a console, you only get what's in your menu.lst - so if that's wrong it won't boot. What you're saying sounds do-able, but you'll have to get everything completely right the first time. You're assuming that your chrooted build on /dev/sdb will boot. In the situation you're talking about, you don't really need an MBR on /dev/sdb. The only reason you would need an MBR on /dev/sdb would be if /dev/sda had a failure. For what you are describing, you need a properly set up MBR on /dev/sda which defaults to booting your root partition on /dev/sdb?. On a side note, if this is an important machine to you, you might to check out some sort of lights-out remote access which would get you remote access to the machine's console. It's a real life-saver when you can't get to the machine easily. Good luck. -Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install-mbr on amd64?
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.
MfG
Goswin
PS: Dear maintainer, consider this a notification of intent to NMU
your package.
--
diff -u mbr-1.1.5/debian/control mbr-1.1.5/debian/control
--- mbr-1.1.5/debian/control
+++ mbr-1.1.5/debian/control
@@ -3,10 +3,10 @@
Priority: optional
Maintainer: Santiago Garcia Mantinan [EMAIL PROTECTED]
Standards-Version: 3.6.1
-Build-Depends: bin86
+Build-Depends: bin86, libc6-dev-i386 [amd64], ia32-libs [amd64]
Package: mbr
-Architecture: i386
+Architecture: i386 amd64
Depends: ${shlibs:Depends}
Description: Master Boot Record for IBM-PC compatible computers.
This is used in booting Linux from the hard disk.
diff -u mbr-1.1.5/debian/changelog mbr-1.1.5/debian/changelog
--- mbr-1.1.5/debian/changelog
+++ mbr-1.1.5/debian/changelog
@@ -1,3 +1,24 @@
+mbr (1.1.5-2.1) unstable; urgency=low
+
+ * NMU: Port to amd64 (closes: #330190)
++ debian/rules: set CC and LD
++ debian/rules: add -W to CFLAGS for proper warnings
++ debian/control: Build-Depend on libc6-dev-i386 [amd64] and
+ (temporary) on ia32-libs [amd64] for dpkg-shlibdeps to work
+ * Fix potentialy harmfull warnings
++ harness/args.c:57: warning: suggest parentheses around arithmetic in
operand of ^
++ harness/output.c:22: warning: comparison between signed and unsigned
++ harness/process.c:25: warning: implicit declaration of function 'exit'
++ install-mbr.c:617: warning: return type defaults to 'int'
++ install-mbr.c:702: warning: comparison between signed and unsigned
++ install-mbr.c:1357: warning: format '%d' expects type 'int', but
argument 4 has type 'char *'
+ * Enable testsuite partialy
++ remove tests for non existing old mbrs
++ conditionaly remove runtime test that fail on amd64
+ * Fix typo in manpage found by A Costa [EMAIL PROTECTED] (Closes: #311235)
+
+ -- Goswin von Brederlow [EMAIL PROTECTED] Thu, 18 May 2006 18:43:42 +
+
mbr (1.1.5-2) unstable; urgency=low
* The we are no longer required for anything release.
diff -u mbr-1.1.5/debian/rules mbr-1.1.5/debian/rules
--- mbr-1.1.5/debian/rules
+++ mbr-1.1.5/debian/rules
@@ -3,8 +3,12 @@
package = mbr
docdir = debian/tmp/usr/share/doc/$(package)
-CC = gcc
-CFLAGS = -g -Wall
+KERNEL_ARCH := $(shell uname -m)
+
+CC = gcc -m32
+LD = ld -melf_i386
+
+CFLAGS = -g -Wall -W
INSTALL_PROGRAM = install
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -17,7 +21,13 @@
build:
$(checkdir)
./configure --prefix=/
- $(MAKE) CC=$(CC) CFLAGS=$(CFLAGS)
+ $(MAKE) CC=$(CC) LD=$(LD) CFLAGS=$(CFLAGS)
+ifneq (,$(findstring x86_64,$(KERNEL_ARCH)))
+ # Limit the tests on x86_64 kernels
+ $(MAKE) TESTS=tests/inst-1 tests/inst-3 tests/inst-4 tests/inst-6
tests/inst-7 tests/inst-8 check-TESTS
+else
+ $(MAKE) check-TESTS
+endif
touch build
clean:
only in patch2:
unchanged:
--- mbr-1.1.5.orig/Makefile.in
+++ mbr-1.1.5/Makefile.in
@@ -71,7 +71,7 @@
man_MANS = install-mbr.8
-TESTS = tests/version tests/inst-1 tests/inst-2 tests/inst-3 tests/inst-4
tests/inst-5 tests/inst-6 tests/inst-7 tests/inst-8 tests/mbr-1 tests/mbr-2
tests/mbr-3 tests/mbr-4 tests/mbr-5 tests/mbr-6
+TESTS = tests/inst-1 tests/inst-3 tests/inst-4 tests/inst-6 tests/inst-7
tests/inst-8 tests/mbr-1 tests/mbr-2 tests/mbr-3 tests/mbr-4
tests/mbr-5 tests/mbr-6
TESTS_ENVIRONMENT = sh ${srcdir}/wraptest
@@ -478,13 +478,7 @@
check-TESTS: \
table.b \
- mbr.b \
- mbr-1.1.3.b \
- mbr-1.1.2.b \
- mbr-1.1.1.b \
- mbr-1.1.0.b \
- mbr-1.0.1.b \
- mbr-1.0.0.b
+ mbr.b
.PRECIOUS: mbr.b
only in patch2:
unchanged:
--- mbr-1.1.5.orig/Makefile.am
+++ mbr-1.1.5/Makefile.am
@@ -7,21 +7,15 @@
man_MANS = install-mbr.8
-TESTS = tests/version tests/inst-1 tests/inst-2 tests/inst-3 \
-tests/inst-4 tests/inst-5 tests/inst-6 tests/inst-7 tests/inst-8 \
+TESTS = tests/inst-1 tests/inst-3 \
+tests/inst-4 tests/inst-6 tests/inst-7 tests/inst-8 \
tests/mbr-1 tests/mbr-2 tests/mbr-3 tests/mbr-4 \
Re: counting scsi hosts
On 05/18/06 02:41:31PM +0200, H. Wilmer wrote: Jim Crilly wrote: It seems to be normal, but I'd probably still say it's a bug in the SCSI system. It is possible to reset the number by reloading the scsi_mod module, but you have to umount all of the SCSI filesystems to do that so it's not a great solution. Unloading the SCSI module is what I did, and the counter is increased each time I reload the module. But there's also the gdth module for the SATA RAID controller, generating SCSI devices, which cannot be unloaded unless the server could run diskless ... GH 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. 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. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]
Thanks!Calling sync automated every 2 seconds (using watch) only slightly decreased performance, while speeding up the umount process extremely, and giving the feeling that the worst case scenario of an usb storage device being unplugged in the middle of a file transition loses a lot of its effect. (Note: I use my USB devices most of the time with only one to maybe 5 files simultaniously accessed, so there is not that much lost in that case, running fsck usually does the job quite well, but without any syncing the unwritten buffers would propably have been too large) GreetingsMarcus MüllerOn 5/18/06, Paul Brook [EMAIL PROTECTED] wrote: The problem is, that without sync, unplugging an un- umounted device is datacide. umounting the device after transferring 700 MB takes about 24sec, what seems to be long.You can manually run sync to flush stuff out to disk. The long delay you're seeing on unmount is because copying the 700Mbprobably kept most of it in cache, and it hadn't finished writing it back bythe time you tried to unmount the disk. Any idea why sync is _that_ slow with vfat (fat32)? Does it always have to rewrite the whole both FATs including analyzing the actual contents of the disk whenever a file is written?The sync option ensures the data is always consistent on the drive, so I'm not surprised you're seeing a large slowdown. Each write probably requiresseveral round-trips to update the FAT.Paul
Debian Installer daily builds use offial mirrors for AMD64
Today a new version of choose-mirror was uploaded that contains an updated mirrorlist and also has the normal mirrors as default for AMD64 instead of amd64.debian.net. As AMD64 is not yet installable from testing, this may break network based installations. Installations (in expert mode) of unstable should probably be alright. The switch has _not_ yet been made for debian-cd, so full CDs should still be alright. You can of course also enter the old AMD64 mirror manually during mirror selection. Cheers, FJP pgpPdXUIUXY0Q.pgp Description: PGP signature
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
[Ccing: amd64 and dpkg developers as they are concerned by this subject] Hi all, [Short introduction to understand the problem] I am asking here for help to take a decision. As some of you may know, on amd64, the main libraries are installed into (/usr)/lib, with (/usr)/lib64 being a symlink to (/usr)/lib, the symlink being shipped by libc6. This is necessary, because as the FHS defines (/usr)/lib64 as the libraries for 64-bit binaries, so some tools (and the linker), may search some file there. 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 point of this thread is not to discuss about that. If you want to, please start a *new* thread. [Let's come back to the 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. 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. Could you please give me your opinion on that, so that I can take a decision? Thanks, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
