|
101 | Core | Bug Report | High | Cannot unmount SD card or USB stick through the GUI | Closed | |
Task Description
When I rightclick and select "unmount" I always get an error, see below.
unmounting from a terminal window works fine.
Also see:
http://www.gp32x.com/board/index.php?/topic/54353-unmount-sd-card-hdd/
"Unable to unmount .... Cannot open /media/.hal-mtab" |
|
226 | Core | Feature Request | High | Boot from /dev/sda devices requested | Closed | |
Task Description
Boot from usb hard disk not supported. This should be a rather simple fix of adding the sdx devices and adjust the boot scripts??
I was able to put this autoboot.txt on mmc 0:1
setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K
ext2load sda 0:1 0x80300000 /boot/uImage
bootm 0x80300000
This failed with amongst other things "Block device sda 0 not supported" and something about failing to load kernel
So I then changed the autoboot file to this
setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K
ext2load mmc 0:3 0x80300000 /boot/uImage
bootm 0x80300000
All this did was die after the kernel loaded.
I believe I could much better make use of this device if I could boot from some faster storage, please advise :) |
|
38 | Core | Bug Report | High | ALSA crashes every so often | Closed | |
Task Description
EDIT: Doesn't seem to be crashing. Looks like the amp hasn't been setup properly.
There is a fix by notaz:
http://notaz.gp2x.de/tmp/uImage
Use that with the latest image (Feb 13th) to test it out.
ALSA crashes pretty often. Not sure, but I think it does this when something is eating up a lot of CPU.
ALSA starts to spit out buffer_underrun errors and occasionally crashes with an input/output error.
Then no sound will come from an SDL app.
You can reinitialize it by playing a song with XMMS. |
|
188 | Core | Bug Report | High | "rdate" sets the time exactly 3 hours in advance | Closed | |
Task Description
"rdate -s time.ien.it" will set the date (hour) 3 hours in advance.
The time (and timezone) can be adjusted manually using the "Settings -> Date and Time" tool, but on the next rdate-update the issue will occur again |
|
108 | Base OS | Feature Request | Critical | TUN/TAN-Driver | Closed | |
Task Description
There is no TUN/TAN Driver installed. This is recommanded for some encrypted wireless lan connections, especially for eduroam, a world wide access point for the education community. Also, a tun-driver is also recommended for vpnc. |
|
58 | Core | Bug Report | Critical | Pandora has not been shipped yet. | Closed | |
Task Description
Pandora has not been shipped yet. |
|
82 | Base OS | Bug Report | Critical | Network Manager - Wifi Can't Reconnect | Closed | |
Task Description
When wifi drops out, or you have disconnected from it and wish to reconnect, you cant reconnect using network-manager.
The connecting icon spins for a while, then it pops up the 'Password' Dialog. If you enter your password, the cycle begins again. |
|
263 | Application | Bug Report | Critical | MiniMenu with "Auto discover pnd apps?" set to NO hangs ... | Closed | |
Task Description
BUG DESCRIPTION:
On my SD card with Pandora OS 1.6.4 I changed MiniMenu's setting "Auto discover pnd apps?" to NO, and then the program remained in an endless loop showing "Setting up menu...", crashing, "Setting up menu...", crashing, and so on.
BUG REPRODUCTION:
The variable filesystem.do_pnd_disco set to the value 0 definetely causes the crash, but maybe only in conjunction with some of my other settings?!
Therefore see my attached config file mmpref.conf.
Maybe related to FS#79 , hard to tell, as this is a very minimal report.
Definitely not related to my previously reported MiniMenu bug FS#262
WORKAROUND:
1) If your default GUI is:
a) MiniMenu: Then after rebooting, MiniMenu will still be caught in an endless loop! Therefore boot up from an auxilary/temporary volume rather than your volume with the damaged MiniMenu! If your ruined system is on the NAND boot from an SD card, if the ruined system is on SD card, boot from NAND or another SD card. In doubt read: http://pandorawiki.org/Running_Linux_from_an_SD_card
b) Other than MiniMenu such as XFCE: Then you are lucky. Simply start into XFCE, and continue with the next step.
2) Open ~/.mmpref.conf with a text editor and set the variable filesystem.do_pnd_disco to the value 1.
3) Reboot into your healed volume. |
|
208 | Core | Bug Report | Critical | HOTFIX 4 and 5 Slow WIFI | Closed | |
Task Description
I'm getting 5kb/s with bursts up to 10kb/s if I am lucky.
I have attempted every channel on my router.
Tried every encryption even no encryption.
Tested with the router's wifi speed: 300Mbps 154Mbps and 45Mbps
I'm running Hotfix 5 RC2.
Wifi works fine with my android smartphone, and other wireless devices such as a laptop. |
|
237 | Core | Bug Report | Critical | /dev/mmcblkN - N sometimes points to left, sometimes to ... | Closed | |
Task Description
SPECIFICATION:
According to http://pandorawiki.org/SD_compatibility_list
/dev/mmcblk0 is the left SD card slot (the one being closer to the headphone check)
/dev/mmcblk1 is the right SD card slot
I trusted that device path specification.
And it was correct MOST of the time.
But sadly only most of the time, NOT ALWAYS!!!
This bug is severely dangerous, as a (possibly critical) command could unexpectedly affect a device other than the one you intended it for!
BUG INCIDENT:
Sadly, I realized this bug at the worst possible moment!
I issued the command: shred -fvz /dev/mmcblk0
but it erased the card in the RIGHT slot.
I realized that because the card inserted on the left has 16GB, and the one on the right 128MB.
I checked both the card positions and my entered command, to exclude my own mistake. Sadly it was not a clumsy mistake: This severe bug really exists!
BUG REPRODUCIBILITY:
I already slightly witnessed this bug during the last days, but thought it was just a coincidence.
I.e. in GParted the larger card showed up at the wrong device path.
I did a refresh and/or ejected/re-inserted the card, and the expected device path was back again, and I did not think further about this incident.
Only today with this fatal shred incident, I eventually realized this behavior is a bug.
Luckily I had my data backed up. |
|
55 | Core | Bug Report | Critical | .xinitrc problems (image from Feb 22nd) | Closed | |
Task Description
Loading a GUI from slim fails, as .xinitrc is broken.
Seems to have been edited using a windows editor? From line 50 on, there are newline characters that shouldn't be there.
Removing them makes XFCE4 loading fine. |
