Same issue, 21,10 using Unity, and the apparmor workaround fixes it for
me as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1915910
Title:
evince does not print (apparmor, pxgsettings)
To
** Changed in: vsftpd (Ubuntu)
Status: Invalid = New
--
pasv_min_port,pasv_max_port does not work if client uses PASV
https://bugs.launchpad.net/bugs/130682
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vsftpd in ubuntu.
--
Same problem on Ubuntu 10.04 server with vsftpd. I'm using a Cisco 1811
router with ports 20 and 21 statically NATed and a NAT pool for the PASV
ports. This works fine in standard FTP mode, but when I switch to PASV
mode in FTPES, it uses a port outside the range specified by the min/max
port
Not a big deal for me, since I reboot the server rarely and have added
this to /etc/rc.local, but FWIW, I have encountered this strange
behavior as well. Using 10.04 Server and vsftpd. Can provide more
detailed info if needed.
--
vsftpd fails to start on boot when using pasv_addr_resolve
Whoops. Found a flaw in my .conf file. I had copied the pasv_min_port
to a different spot while troubleshooting another issue, and had two
values for min, with no value for max. Works fine now in both modes.
Setting status back the way I found it.
** Changed in: vsftpd (Ubuntu)
Status:
** Changed in: vsftpd (Ubuntu)
Status: Invalid = New
--
pasv_min_port,pasv_max_port does not work if client uses PASV
https://bugs.launchpad.net/bugs/130682
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Same problem on Ubuntu 10.04 server with vsftpd. I'm using a Cisco 1811
router with ports 20 and 21 statically NATed and a NAT pool for the PASV
ports. This works fine in standard FTP mode, but when I switch to PASV
mode in FTPES, it uses a port outside the range specified by the min/max
port
Not a big deal for me, since I reboot the server rarely and have added
this to /etc/rc.local, but FWIW, I have encountered this strange
behavior as well. Using 10.04 Server and vsftpd. Can provide more
detailed info if needed.
--
vsftpd fails to start on boot when using pasv_addr_resolve
Whoops. Found a flaw in my .conf file. I had copied the pasv_min_port
to a different spot while troubleshooting another issue, and had two
values for min, with no value for max. Works fine now in both modes.
Setting status back the way I found it.
** Changed in: vsftpd (Ubuntu)
Status:
NeCod, do be careful not to let the mobo re-write that HPA. From my
(very bad) experience with that Gigabyte board, a reset of the CMOS, a
BIOS flash, a bad stick of RAM, or just playing around with the BIOS
backup tools in the wrong way can cause it to do this without warning
you. (the driver
This same message is appearing to me in 10.04 with Firefox. My first
attempt to go ahead with running the app has resulted in Firefox going
to a gray busy lockup condition, and it is still in that state on that
machine. More specific data was available, and I will post everything
in a few
I had to kill Firefox to unlock it.
Ubuntu 10.04 x64
Firefox version 3.6.3
Mozilla Firefox for Ubuntu canonical 1.0
Plugins highlights:
IcedTea NPR Web Browser Plugin (IcedTea6 1.8 (6b18-1.8-0ubuntu1))
Shockwave Flash 10.0 r45
Silverlight Plug-In 3.0.40818.0 (I had to do some research on M$
1. I tried it first on the Ubuntu 9.10 machine with sun-java6-jre
installed but not with sun-java6-plugin. The same error message
appeared. I will not repeat the details.
When I hit run, the applet loaded, and it appears to be functioning
normally.
2. I installed both sun-java6-jre and
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: joe2396 F pulseaudio
/dev/snd/pcmC0D0c: joe2396 F...m pulseaudio
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xeb20 irq 22'
Mixer name : 'Realtek ALC889A'
** Attachment added: AlsaDevices.txt
http://launchpadlibrarian.net/42242381/AlsaDevices.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: AplayDevices.txt
http://launchpadlibrarian.net/42242382/AplayDevices.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: BootDmesg.txt
http://launchpadlibrarian.net/42242443/BootDmesg.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: ArecordDevices.txt
http://launchpadlibrarian.net/42242383/ArecordDevices.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs,
** Attachment added: Card0.Amixer.values.txt
http://launchpadlibrarian.net/42242452/Card0.Amixer.values.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
** Attachment added: Card0.Codecs.codec.2.txt
http://launchpadlibrarian.net/42242456/Card0.Codecs.codec.2.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of
** Attachment added: CurrentDmesg.txt
http://launchpadlibrarian.net/42242463/CurrentDmesg.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/42242465/Dependencies.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: PciMultimedia.txt
http://launchpadlibrarian.net/42242466/PciMultimedia.txt
--
Volume control headphone switch works, but causes loud pops in speakers
https://bugs.launchpad.net/bugs/318642
You received this bug notification because you are a member of Ubuntu
Bugs, which
Since the time I posted this issue, I have upgraded this machine to 64
bit 9.10. Under this release, with all updates installed as of today,
the problem is different.
Now the machine no longer detects when the headphones are plugged into
the front jack, and treats them the same as the main
** Attachment added: XsessionErrors.txt
http://launchpadlibrarian.net/42242467/XsessionErrors.txt
** Changed in: alsa-driver (Ubuntu)
Status: Incomplete = New
** Tags added: apport-collected
--
Volume control headphone switch works, but causes loud pops in speakers
*** This bug is a duplicate of bug 413168 ***
https://bugs.launchpad.net/bugs/413168
This is happening on my HP HDX16 with Nvidia 9600M graphics. xset dpms
force off shuts off the light for 30-60 seconds, then the backlight
comes back on. This appears to be different from the earlier bug,
I've tried both methods (Mick's and Aaron's) and both result in gnome-
rdp becoming unresponsive when it is restarted.
I had encountered this same problem when going from 7.04 to 8.10 and
solved it in a similar way, by re-importing the database in a different
version (I'll edit in the reference
Scratch that last post: Mick's script worked on the second try after a
reboot. I was using several different backups of the original .gnome-
rdp.db to try the different methods and probably used one that had been
partially processed already as the seed for the script.
Aaron's method still did
Public bug reported:
I have a strange problem in 64 bit 8.10 Intrepid Ibex, which I have not
been able to find reported anywhere else in spite of extensive
searching.
Whenever the headphones are plugged in, the main speakers automatically
mute, as they should, but if any sound is played across
I have found a utility that will avoid you having to use the workaround
for HPA. This utility will allow you to remove the HPA from your hard
drive permanently in most cases. You have to have the hard drive on a
SATA port that is in AHCI mode, not in RAID mode when you run this
bootdisk and
I didn't have the file, either. All you have to do is create the empty
(and writable) file libata-options in /etc/modprobe.d/ and then open it
with your favorite text editor and add options libata ignore_hpa=0.
That's the only line that needs to be in there.
Once you've done that, the sudo
Thanks Phillip! That worked for me as well!
I can now sudo mount /dev/dm-1 /media/RAID and read and write to it
without breaking the array.
The issue where the RAID is shown as broken after a soft reboot is
resolved as well.
Some of the research that I did on this issue since my last post
The kernel parameter does not appear to have had the intended effect. I
added this entry to menu.lst in /boot/grub and cold-booted to it:
title Ubuntu 8.04, kernel 2.6.24-16-generic (RAID fix)
root(hd0,4)
kernel /boot/vmlinuz-2.6.24-16-generic
I'll have to inform Gigabyte of the problem, then. The BIOS I have is
F4, which is the release version, but also the most recent version
available for this board. With such a new product, I guess that's the
danger. In the meantime, I'd like to see this work at least once, just
so we can confirm
Thanks, I didn't see your last message before I posted, there. I'll
give that kernel parameter a try this evening.
I still think Gigabyte needs to act on this, especially if they've got
an old version of the RAID BIOS. I think I will send them to this
thread directly.
--
ich9R raid array not
I tried breaking the array, reformatting both drives with mkfs (ext2)
and then rebuilding the array. This time dmraid would only see one
drive of the mirror, and not the other one. I'm including my info dump
in a text file.
Perhaps this version of the Intel driver only needs to mark one drive?
I have a gentoo live CD lying around somewhere, so I'll give that a try
tonight.
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I will try this procedure this evening and post the results.
Do you want me to run this procedure on sda as well? In my current
configuration, sda is not a RAID member, and it serves as my boot disk.
sdb and sdc are the members of the RAID.
One correction, dmraid does not work correctly after a
Phillip,
I have attached the results of your suggested procedure. I took the
chance to look at them, and found that while the sig data does exist on
both drives, it is also located in very different spots on each. This
seems very strange to me, but also suggests an easy workaround and fix.
For
I moved the signature data on sdb to the same offset as that on sdc (and
zeroed out its old position.) (I moved the data from sdb to sdb, even
though it looked like the sigs on the two drives were identical.) This
resulted in the BIOS seeing the RAID as degraded, with one member disk,
and one
Masa, what you are seeing seems to agree with my most recent test.
I once again deleted the array in BIOS and re-created it, only this
time, I named it NewRAID1
When I ran dmraid -n it showed the first disk as being a part of
NewRAID1 and the second as being a part of RAID1, which was the name
I tried that the first time I saw this happen, because the offline
member message when I rebooted made me think the raid had been broken
by dmraid. On a later attempt, (when I actually had some data on that
array to test) I tried a cold boot, and both Windows and the bios
recognized the array as
I have the same problem, won't recognize he RAID 1 array on my ICH9R,
(Intel X48, Gigabyte X48T-DQ6) warm reboot gives member offline for
both member disks, but a cold reboot restores them to normal operational
status. Using 8.04 Live CD. This RAID works fine under Windows.
A similar problem
43 matches
Mail list logo
