I'd be more inclined to check into the driver. I use kde and have no issues at all with wifi, nor do the vast majority of my users, assuming I'd hear something if there were issues. Given that the entire comms stack works fine with different hardware, the difference is the driver. Check for proprietary drivers if the open source one is screwy. On Tue, Oct 21, 2025, 9:15 PM Ket ket@users.sourceforge.net wrote: An update. The wifi issue I worked around by assigning unique SSIDs to the 2.4GHz and 5GHz...
What I provide is a starter kit. You finish it to your requirements. It's not possible to provide every driver for every piece of hardware. Perhaps I provide too much, leaving folks with the impression that this is a shrink-wrapped product... On Tue, Oct 21, 2025, 12:09 AM Ket ket@users.sourceforge.net wrote: Titles gives the premise, in short what little I could use of this distro seems promising, but sadly across several builds, at least 6 of them, I have persistent wireless connectivity issues....
That's because not enough people use USB WiFi sticks anymore to justify their inclusion. I've built and pushed a few drivers for rtl (realtek) devices. Not sure how many more might be available. Check the specs on your device, or use dmesg and find its discovery, and get the chip model number, then Google it along with the terms "arch linux" and "driver". If arch supports it, the search will find it. If not, try the search without the "arch" and see if any Linux supports it. Gparted can only be run...
To be clear, you are the first person to ask for a driver for a USB wifi dongle - they're not used much anymore, given how ubiquitous wifi has become. That's why I provide no drivers for this type of hardware. Typically, if you have a special piece of hardware, you'd look for it in Arch's AUR and build it yourself. If there's one you need and you're not comfortable building it yourself, let me know what it is and I'll add it to my repository. Do not expect me to dig up, build and provide every driver...
Thank you, Feruci. Are there any particular drivers you're looking for? I maintain a repository for my distro and have no issue with adding packages to it, and maintaining them going forward. Let me know what you need. Cheers On Fri, Aug 15, 2025, 11:36 AM Feruci Samersonsen fragatak@users.sourceforge.net wrote: Respekt Ihr Betriebssystem ist von vielen getesteten Betriebssystem bis jetzt echt die Nummer 1 der linux-kerne des top-aktuell alle Programme sind. Top-aktuell, ich habe sehr große Respekt...
VMSvga has been working again as expected since one of the kernel updates a couple of months ago. On Wed, Aug 6, 2025, 6:58 AM David Clark davidclark23@users.sourceforge.net wrote: Try enabling 3D acceleration in VirtualBox settings for the VM, and make sure the Guest Additions are installed. Also, 128MB video memory is good, but BlueStar may still need that 3D boost to fully load the GUI. No desktop with live ISO https://sourceforge.net/p/bluestarlinux/discussion/general/thread/7e23a0ac14/?limit=25#1dd3...
Cairo-dock does not work with Wayland. You will need X11. On Wed, Jul 23, 2025, 4:11 PM Scott R mach28@users.sourceforge.net wrote: Congratulations to the BlueStar team! I have installed this distro using Virtualbox. I'm not that familiar with Plasma, but when I login using Wayland the mouse moves very jaggy and slow. Also, under Wayland, the dock doesn't show as under X11. Both Wayland and X11 are installed by default. If I graduate to a bare metal install, I will need Wayland. Is there anything...
Change your display device to VboxSvga. For some reason VMSvga has stopped working. On Wed, Jun 4, 2025, 10:42 PM Eric the Grey ericthegrey@users.sourceforge.net wrote: I attempted to install BlueStar in a VirtualBox image and only get so far as a "Reached Target Graphical Interface. I tried switching consoles using the virtual keyboard, but all except tty1 is just a standard console. I'm not terribly familiar (read, not at all) with Arch, but wanted to try this release because it is gorgeous! Could...
Hi Saleem. I've double checked the repository and the file format is fine. Maybe try 'pacman -Syy' to re-download the database files - it is possible I was in the middle of a repository update when you grabbed an incomplete file. Unfortunately, I have no control over sourceforge and its mirrors, and moving everything somewhere else isn't an option, so there's nothing there I can fix. All I can suggest is to keep trying. On Wed, Oct 9, 2024, 8:27 AM saleem drmarwat@users.sourceforge.net wrote: This...
Archlinux32 is a bit of a mess which means bslx32 is pretty much impossible to build. I don't have a full time job I can devote to fixing archlinux32, not to mention that it's definitely not my task to maintain archlinux32. Until the folks in charge of maintaining archlinux32 get everything fixed, dependencies taken care of and provided, and it's stabilized, I cannot build bslx32. So the answer is that for now, you're on your own. The last version I uploaded is still good to install without internet....
@Locutus - for detailed documentation, please check out the arch wiki. pgp is included with the release, and the assumption is that either one knows how to use it or one checks the man page: "gpg --recv-keys key" is the syntax. as for uid, the linux utility, useradd, assigns user IDs starting at 1001. no. if you took a quick look around you'll notice their are no discussions, so I'm not sure what exactly would lead you to believe that anyone monitors this page. discussions are at the facebook page...
bslx : user root : admin but, your default permissions are also good for sudo or su. just type su at the terminal prompt and you'll be root: $ su cheers On 2/10/23 16:44, Locutus wrote: I found a great review for Bluestar and would love to give it a go, especially I only run Arch based distros with Plasma. The problem is I went to edit partition.conf so Bluestar would install using BTRFS and no matter whgat I use for the password in the live environment I can't save my changes. I have tried just...
I cannot guarantee the outcome, but if you run the installer and choose not to format your existing partitions (you'll still have to set them up with mount points), and both systems are up-to-date, the installation should have the effect of overwriting what it needs to, but leaving there whatever is outside of the installation packaging/files. The root and /home are the file systems/directories that will be affected. But. I can't guarantee that you can do here what you want to do without consequences....
I cannot guarantee the outcome, but if you run the installer and choose not to format your existing partitions (you'll still have to set them up with mount points), and both systems are up-to-date, the installation should have the effect of overwriting what it needs to, but leaving there whatever is outside of the installation packaging/files. The root and /home are the file systems/directories that will be affected. But. I can't guarantee that you can do here what you want to do without consequences....
I cannot guarantee the outcome, but if you run the installer and choose not to format your existing partitions (you'll still have to set them up with mount points), and both systems are up-to-date, the installation should have the effect of overwriting what it needs to, but leaving there whatever is outside of the installation packaging/files. But. I can't guarantee that that can be done without consequences.
Well, sorry about that, bud. You should be good now. Let me know if you have any other issues. Cheers
Well, sorry about that, bud. You should be good now. Let me know if you have any issues. Cheers
Hi Danny. I'm not even sure how you ended up with a bluestar-plasma repository reference in your /etc/pacman.conf file. I think at one point in time I created a local repository of that name to test some alternate plasma packaging, but the resulting collection of alternates would have ended up in bluestar-override. In any case, you are free to remove it from the config file. It doesn't exist. Cheers
hey Danny. glad to hear you resolved your issue. i guess cables do give out sometimes. nice catch. np re working on the gma500 solution. i've needed to explore that route for a long time and was happy to find out that the driver finally works without a wonky vsync. i checked the code changes and saw that at some point they separated out the cedarview logic. apparently they even inserted the native gpu code that patrik jakobsen had worked on years ago, although they removed it again since it was slower...
np, Danny. whenever you can get to it is fine.
thanks, bud. was just checking for the "video=LVDS-?:d" parameter so i'd know how to change your command line. man, you are running an old installation aren;t you. i think i'd prefer to have you change it via the grub boot menu, though. that way we can test it and make it permanent afterwards. the first thing to do is to edit your /etc/mkinitcpio.conf file and add gma500_gfx to the MODULES entry: MODULES="gma500_gfx" then run (as root) 'mkinitcpio -p linux'. that's easy enough to back out if we need...
ok, Danny. could you please send me your kernel command line from /etc/default/grub?
well. good news. the gma500_gfx driver now works: [root@jghodd-cedartrailplatform Pictures]# lsmod Module Size Used by dm_mod 167936 0 ccm 20480 9 tun 61440 2 8021q 40960 0 garp 16384 1 8021q mrp 20480 1 8021q stp 16384 1 garp llc 16384 2 stp,garp b43 466944 0 uvcvideo 118784 0 cordic 16384 1 b43 bcma 69632 1 b43 videobuf2_vmalloc 20480 1 uvcvideo videobuf2_memops 20480 1 videobuf2_vmalloc videobuf2_v4l2 36864 1 uvcvideo mac80211 1183744 1 b43 videobuf2_common 69632 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops...
yeah. that's why i'm trying a different approach. i'd like to see if the latest version of gma500_gfx can be made to work now if configured correctly. that would be good for you and good for me. i'd prefer dropping support for uvesafb if the actual driver can be made to work.
the issue on your system is that something is grabbing that I/O port range (0x3c0=0x3e0) before the kernel gets to loading uvesafb. i don;t know what that might be. could be part of the core kernel. could be another kernel module. i know it's not happening on my d2500 system, so whatever it is, i'm not using whatever it is that's interfering with your uvesafb module. that means i can't replicate your error condition.
no. you need the gma500_gfx module. here's my module listing: [root@bluestar bslx]# lsmod Module Size Used by ccm 20480 6 8021q 40960 0 garp 16384 1 8021q mrp 20480 1 8021q stp 16384 1 garp llc 16384 2 stp,garp b43 466944 0 iTCO_wdt 16384 0 cordic 16384 1 b43 intel_pmc_bxt 16384 1 iTCO_wdt at24 24576 0 bcma 69632 1 b43 iTCO_vendor_support 16384 1 iTCO_wdt uvcvideo 118784 0 mac80211 1183744 1 b43 videobuf2_vmalloc 20480 1 uvcvideo videobuf2_memops 20480 1 videobuf2_vmalloc videobuf2_v4l2 36864 1 uvcvideo...
yeah, i've known all about the gma500_gfx driver pretty much since its inception. it should be there. hypothetically, we should be able to use only that graphics driver, and in fact it kinda worked for a long time, but its vsync was dodgy when used with the D2xxx atom processors. it is linux's official gma3600 driver. unfortunately, it seems to have stopped working completely now. i used to be able to boot up the live system from the generic boot entry (with dodgy vsync), but now i just get a blank...
not so good news on my testing, Danny. mine loaded without any problems on a D2500 netbook (same gma3600 graphics hardware). that message is basically telling you that something else in your system has already reserved those particular I/O ports (0x3c0-0x3e0) - i'm assuming another graphics driver. could you run 'lsmod' on your system and let me know what's returned?
thanks, bud. there should be a uvesafb.0 directory there and, obviously, there's not. i checked out the signature checking and that appears to be a non-issue, so next i'll take a look at the code itself. i have a little atom netbook like yours that i haven't turned on for a while - the fan's messed up - but i'll see if it also fails and if so, if it leaves more to find in the logs.
thanks, bud. there should be a uvesafb.0 directory there and, obviously, it's not. i checked out the signature checking and that appears to be a non-issue, so next i'll take a look at the code itself. i have a little atom netbook like yours that i haven't turned on for a while - the fan's messed up - but i'll see if it also fails and if so, if it leaves more to find in the logs.
hey Danny. could you list /sys/bus/platform/drivers/uvesafb and let me know what's in there?
hi Danny. the issue may be the changes i had to make for 1.0.4. a little over a year ago the arch64 folks removed an option from the kernel config file that provided the video buffer modes used by uvesafb. i opened a bug report to have them restored, but at the time i received no response. in fact, it took about 9 months before they finally fixed it. meanwhile, i had to cut the vb modes from the older kernel source code and paste it into the uvesafb-dkms code base so that it could continue to be...
Hi Danny. You can use this email address for support. So, I'm guessing some update, probably an updated kernel driver, changed the display device or how it's chosen. I haven't changed anything related to display choice in a looong time. LVDS can be specified via your grub config (kernel command line), and you can change it easily if you can log in via ssh. The addition to the command line is " video=LVDS-N:c", where N is the display number (0 or 1 usually) and 'c' is the command - 'd' for disable,...
I'll fix that tonight when I get home. Cheers On Tue, Nov 5, 2019, 5:27 PM Lode Van Beethoven lode-runner@users.sourceforge.net wrote: Meanwhile still no sollution found ... tried two times again yesterday and today [tickets:#1] https://sourceforge.net/p/bluestarlinux/tickets/1/ unable to upgrade due to missing file in 3 consecutive days* Status: open Milestone: 1.0 Created: Mon Nov 04, 2019 08:57 PM UTC by Lode Van Beethoven Last Updated: Mon Nov 04, 2019 08:57 PM UTC Owner: bluestarlinux 485 packages...