You are not logged in.
In the same manner Your Bluestar stops, at the same time, the same thing
Let's keep this out of the discussion here. If and when we get past this issue - and I believe it should be solvable via the kernel command line - and you want to pursue that option, you can join my forum and we can discuss it there. :-)
Offline
Tried it also, earlier. I can choose 686, i can choose x86_64, result is the same with 11.2013 iso. Stops at the mentioned place on earlier screens.
No, I didn't think this would solve anything. It was just an FYI.
Let me take a look around. I believe entirely this is a matter of a missing kernel param (although it could be your bios - let's hope it's the kernel param).
EDIT: By any chance, have you checked to see if there's an update for your BIOS?
Last edited by jghodd (2013-11-03 22:38:02)
Offline
I haven't seen on Acer website anything about never bios for it. I'm not sure even it this AOD270 is not right now an EOL (end of line, closed production). I would have to try booting up newest Kubuntu, see cat /proc/cmdline, maybe it will shed some light into this matter, but not right now, when i have time.
Thank you again for and advices, it's time for me. Till free time
Offline
I can do a kubuntu download and check it for you tonight.
Offline
For the record, as far as I know, the Arch .iso does not use grub at all - in either boot mode. That is, unless they've altered it recently.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It uses syslinux. In UEFI mode it uses gummiboot, but I know that there was talk on [arch-projects] about making that use syslinux-efi as soon as it was stable enough to be a viable alternative. I have had syslinux-efi set up for quite some time now, and have found that it works great, but I think there were issues with the pxe capabilities or something.
Offline
That makes sense. I knew the UEFI menu wasn't syslinux, but it sure didn't look like grub either, even though it responded to 'e' to edit the kernel command line like grub.
Offline
Ok. Tried kubuntu and it was a bust. It wouldn't boot on my cedartrail platform, and when booted on my pentium M laptop, /proc/cmdline doesn't give you any useful information. Apparently ubuntu uses their own "preseed" system of setting things up. Although I went so far as to unwrap initrd, there was no way I could possibly figure out what they're doing with a couple of hours of sifting through shell scripts. The preseed config file wasn't at all helpful.
However, I did discover a couple of known issues with the Acer Aspire AOD270 vis-a-vis Linux, and some options we can try.
First, there is a known issue with backlighting. You can try these options to address this issue:
acpi_backlight=vendor acpi_osi=Linux
The second option is not as important as the first. You might want to try just the first one, then add the second if it doesn't work. If no combination of these works, back them out - this probably isn't your problem.
Another issue is related to booting from a live iso. Apparently this will cause your boot to hang according to Fedora's documentation on booting various Acer models. Try this option to address this issue:
ssb.blacklist=1
If these fail, we should try upping the boot logging. Check out this page for the kernel options you need to increase debugging output:
https://wiki.archlinux.org/index.php/Boot_Debugging
There are several levels to choose from - you might want to try the basic verbose option first (remember to remove quiet), and then increase it one level at a time until something useful shows up on your console.
Last edited by jghodd (2013-11-04 08:06:47)
Offline
First, there is a known issue with backlighting. You can try these options to address this issue:
acpi_backlight=vendor acpi_osi=Linux
The second option is not as important as the first. You might want to try just the first one, then add the second if it doesn't work. If no combination of these works, back them out - this probably isn't your problem.
I had it, doesen't fix the problem.
Another issue is related to booting from a live iso. Apparently this will cause your boot to hang according to Fedora's documentation on booting various Acer models. Try this option to address this issue:
ssb.blacklist=1
If these fail, we should try upping the boot logging. Check out this page for the kernel options you need to increase debugging output:
https://wiki.archlinux.org/index.php/Boot_Debugging
There are several levels to choose from - you might want to try the basic verbose option first (remember to remove quiet), and then increase it one level at a time until something useful shows up on your console.
You want me to add ssb.blacklist=1 at the kernel line on installed system, right ( i won't be able to add it to a usb iso because of black screen problem)? I should put it where is "rw quiet" line, right?
About debugging - what is the point of doing that when i won't be able to see it on installed system bacause of lost screen during boot after "welcome to arch linux" (my earlier screen)?
I have to say it: i won't be able to do anything at all, either on usb iso or installed newest Arch because of "screen problem". I could only boot older iso, and chroot it in order to do something with it. I could add debug options, ssb and so on but my Arch stops at "welcome to arch linux" - my screens that i posted above.
Last edited by firekage (2013-11-04 10:43:55)
Offline
I should put it where is "rw quiet" line, right?
Do not replace or remove "rw". Remove "quiet" and add in "verbose". As we increase the level of console logging you will be adding to "verbose".
About debugging - what is the point of doing that when i won't be able to see it on installed system bacause of lost screen during boot after "welcome to arch linux" (my earlier screen)?
We don't know how much information is actually available before and after the Welcome message. This is why we want to add debugging. Your kernel is loading and starting the boot process, so we know that more information than what you are seeing should be available. What we don't want to do is to dump more information than we need - it'll scroll right off your screen and that won;t be of much use to us. At the same time, we do need enough information to determine what might be going wrong, so we need to increase error logging to the console one step at a time.
Please don't fixate on the fact that you see nothing after the Welcome message. We have not yet determined that this is a graphics issue - in fact it's probably not. At least not at this point in the process - it might be later when we get to adding graphics. Your screen isn't going dark - nothing is being output to your console after the Welcome message. Those are two very different conditions. It's more likely that your boot is hanging, so your kernel is most probably in an infinite error loop - increasing the debugging output will let us know what errors it's currently dumping to the logs.
You want me to add ssb.blacklist=1 at the kernel line on installed system, right
No. We're working with the clean iso - the live system. If ssb is the problem, your boot won't hang. If it's not the problem, your boot will hang in the same place.
Offline
I added "verbose" after rw on my installed arch kernel line (e at Arch on ghrub) - stops in the same place. I had not see something more in output because after Welcome to Arch Linux i have only blinking cursor on the left. I'm not sure if i did it correctly, also with the "live system" - i placed cursor on the Boot Arch Linux (i686) hit tab, line was shown:
> .linux boot/i686/vmlinuz archisobasedir=arch archisolabel=ARCH201311 initrd=boot/i686/archiso.img
after archiso.img i added verbose: there werent anything new during boot. I added then debug, there were shown more lines during boot process, at debug but it to many of them to see if there are some errors and were going too fast.
Is there a way to store output of this to shown here or on pastebin?. In debug mode Arch stops at [13.087957] systemd [1] "set hostname to <archiso>, ending with blinking cursor.
Last edited by firekage (2013-11-04 22:49:30)
Offline
Do remember to remove the "quiet" option - this will prevent the kernel from logging certain information.
I added then debug, there were shown more lines during boot process, at debug but it to many of them to see if there are some errors and were going too fast.
Yeah, that's what I was warning you about. However, the most important information should come at the end, when the boot hangs, so we're still good. The "keep" option might help some. If anyone has any good ideas for capturing the debug output, now would be a good time to chime in...
I'd still like you to go farther though. Next add the "ignore_log_level" ("verbose debug ignore_log_level earlyprintk=vga,keep"), and if that doesn't tell us something more, go to the extreme level:
debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug
Interesting stopping point though... maybe we'll get some more information at the next level.
EDIT: Hm. The code line got clipped. This is the entire line: "debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug"
Last edited by jghodd (2013-11-04 23:07:13)
Offline
I added it, output was larger, but it comes too fast. I will try to write what is on the last lines of output, and post here. It will take much time, will do it later.
Offline
Post it when you can. The more information we have at the point of failure, the better. Also let me know if you see anything else on the screen that looks like it might be important - like the last device it was accessing/probing, etc... assuming it hasn't scrolled away.
Offline
I added it, output was larger, but it comes too fast. I will try to write what is on the last lines of output, and post here. It will take much time, will do it later.
You could also photograph it and post the image somewhere. But only link from here as the forum rules don't allow large images.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I found this thread that seems to describe the same issue:
https://bbs.archlinux.org/viewtopic.php?pid=1334705
And also this thread that may offer some relevant information (second to last post):
http://chakra-linux.org/bbs/viewtopic.php?pid=76384
Still want to know what came up in the debug output, though. Post when you can.
Offline
Ok, i will post more when i would have some time to check it, or do a pictures (...my camera in phone has problem with focus...so i would have to play with it in order to do a good picture), because right now i can't afford to spend to much time on Arch because of my daily routines, chores, work hours and so on.
Thank You for Your time and advices.
Offline
I found this thread that seems to describe the same issue:
This thing looks promising. I downgarded systemd to 204, after this i rebooted, Welcome to Arch Linux went away, i saw that services are being loaded, there were lines with green "OK", but after it system stopped at:
systemd-login : watvhing system buttons on /dev/input/event8 (Video Bus)
We are really close to solving it.
Edit: i hit few times enter, loging prompt showed up:
Arch Linux 3.11.6-1-ARCH (tty1)
localhost login:
This was fresh clean install, i haven't created user, haven't run KDE services in order to load GUI.
Edit: yes, that was it! Thank YOU VERY VERY MUCH! Now i rebooted, (deleted LVDS from kernel line because i haven't had screen) and after reboot i can login to Arch!
It is strange to me that systemd was the cause of it. So, for my GMA 3600 or Acer AOD 270 systemd 208 is wrong, or broken, because 204 works - strange is that on much older, maybe 5-6 year old laptop with Graphic Intel GMA900/950 (old Acer Aspire) new iso works with systemd 208.
I had to download old systemd (i downloaded it by running Windows on Acer, don't know why i could not wget under Arch from ARM on sablu.net - cannot resolve host from their site under console mode).
Last edited by firekage (2013-11-05 22:46:16)
Offline
Is there a way to store output of this to shown here or on pastebin?. In debug mode Arch stops at [13.087957] systemd [1] "set hostname to <archiso>, ending with blinking cursor.
I've reported this (on Fedora): https://bugzilla.redhat.com/show_bug.cgi?id=1027478 and it's also already in upstream systemd git: http://cgit.freedesktop.org/systemd/sys … 0035d4743a
Feel free to file bug on archlinux to include this patch.
Offline
Just a quick heads up for anyone suffering with Video Acceleration under Gma 3600.
Sadly, as we know the driver doesn't support Accelerated video decoding, however If your atom processor has Hyperthreading / is dual core you can get acceptable results by running mplayer with the following options :
mplayer -lavopts threads=4 -framedrop yourvideofile.avi
4 being the number of threads availible to your processor. It significantly improves performance and makes videos watchable.
Offline
I'm going to install the driver from https://github.com/thomas001/cedarview-drm. Can somebody help me with the dependencies i have to fix.
Offline
Thank you, firekage, for confirming that the issue is with systemd. That's great news. This gave me the opportunity to provide a solution for my users - instead of going backwards, I went forwards a tad and applied the fpdt patch (http://cgit.freedesktop.org/systemd/sys … 0035d4743a) to 208-4, providing a stopgap until 208-6 is released.
Sorry I didn't respond earlier, but for some reason I received no notification of your reply, or any of the replies since then.
Good work, my friend.
Offline
Glad i could be of use.
BTW - how to apply this fix?
I tried playing with my AOD270. I found that xf86-video-modesetting driver allows me to suspend and resume from suspend to ram without problems (on default drivers for GMA3600 after suspend i had garbage on screen, could do nothing exept reset), also, i can play 720p content without slow frame rate during playback.
Last edited by firekage (2013-12-25 01:32:23)
Offline
I started with systemd-208-4, which is currently in staging, and added the patch to the build directory and PKGBUILD. Also, I incremented the release version to 5, creating a package named systemd-208-5. The reason for giving it a release number of 5 is because this patch isn't scheduled to be included in a release until 208-6. Arch is currently at 208-3 (Fedora is at 208-6). Setting the release number to 5 will prevent its update until 208-6 is released.
I made the PKGBUILD available for download at: http://sourceforge.net/projects/bluesta … z/download
I do want to stress that doing this corrupts the versioning process and is not condoned. It effectively breaks your system in terms of support until you re-align the versioning with the official 208-6 release. That said, I have had one of my users test and confirm that this version works.
Yeah, I've noted that the gma500 driver is working pretty well these days in terms of performance. There are still a few things they need to address, but I'm hopeful the fixes coming up in linux-3.13 will close out some of the outstanding issues. The developer had mentioned having EXA 2D acceleration working, but it has yet to appear in any of the kernel commit logs - maybe soon.
Anyway, take a look at the PKGBUILD I referenced above. You should be able to easily figure out the changes I made. The patch you need is the file named 0008-break-on-zero-or-negative-length-read-from-fpdt-table.patch.
Merry Christmas, and thanks again, firekage.
Last edited by jghodd (2013-12-25 00:19:58)
Offline
EXA is a userspace thing, you won't see anything regarding it in the kernel logs. What you will see is the release of an X driver that will work with the gma500_gfx kernel driver, you will then use that instead of xf86-video-modesetting. But rather than EXA, I'd be interested in Xv, as that would greatly increase video playback performance.
Offline