EasyOS version 2.3.2, June 22, 2020

[BarryK]

Thanks for your recommendation. It does make it possible to boot up normally to the desktop, but only if I select the modesetting X driver. [However, I cannot reproduce that setup, so need to assess it further.] The nouveau X driver crashes and stops the boot-up, with either modeset=1 or modeset=0 in nouveau.conf. The boot messages:

• (EE) Fatal server error:
  (EE) No screens found (EE)

and in /var/log/Xorg.0.log (before the above):

• [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19
  [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19

BTW, the nv drivers work successfully, even without the "settle".
Richard

Another possibility is to try the 'xf86-video-nouveau' PET:

http://distro.ibiblio.org/easyos/amd64/ ... pyro64.pet

Easy Pyro64 0.8.x is using xf86-video-nouveau compiled in OpenEmbedded, whereas the PET was compiled in a running Easy.
Maybe there is a difference, worth a try.

Thanks for testing!

[Cu Chulinux]

Barry,

Still checking logs and setups for different puppies vs Easy (when I have time) but thought I would add this:

With EasyOS 0.8.1 from USB I don't get past the quick starup screen. I exit without making any changes and computer freezes. I hard reset and end up back in quick startup screen.

With EasyOS 0.8.1 from HD I exit quick startup without making changes. Now default is sna. Computer runs ok, I can even click on icons to run Sakura, etc. But as soon as I open the main menu the computer freezes. I change to uxa (again, no other changes made yet - I haven't even set up networking) and I get an empty menu with no text (as I described in a previous post). Actually the highlighted line in the menu shows text but only that. It doesn't freeze (at least not yet). I will go back and try other options and see if I can set up networking. In Easy that often causes freezes too. I may try booting USB to commandline and changing the sna xorg.conf.d file to DISABLED to see if I can run from USB.

Note I have tried 3 different usb sticks to make sure it's not the stick. MD5sum was fine. All very confusing and frustrating, especially when Xenailpup64 runs so well.

Edit: just saw your latest post. Downloading and testing new xwin.
Edit2: would the kernel module not be loaded when restarting X though?

[BarryK]

Edit: just saw your latest post. Downloading and testing new xwin.
Edit2: would the kernel module not be loaded when restarting X though?

Don't know, but it is within the realms of probability.

For the last few days I have been using my Acer Aspire 5742G laptop, as away from home. i3-370M CPU, 4GB RAM. Dual intel and nvidia graphics.

First, I had that wait-loop in rc.sysinit, right where the "#udevadm settle" line is. It waited for the 'i915' and 'nouveau' kernel drivers to load, and it took 4.5 seconds.

So, if the wait-loop wasn't there, and execution got to running 'xwin' to start X within 4.5 seconds, then the kernel drivers will not be ready.

Do not have that problem on any of my computers. On this laptop, with that wait-loop in 'xwin', there is no wait, the drivers are already loaded.

But, I can see the possibility of that not being the case.

Note, my "old" Acer laptop was purchased in 2011:

http://bkhome.org/archive/blog2/201107/ ... g64mn.html

I have an even older one, also an Acer, purchased in 2006, but it is sitting in a closet, never gets used. CPU is only 32-bit, 512MB RAM. It is a good laptop though, don't want to dispose of it.

It could be that this problem is happening now, as the kernel is taking longer to load drivers. I don't know why this is happening. rerwin has also noticed it, at least I think that was the implication of an earlier report from him. One thing to try would be to revert to a much older kernel, see if that makes any difference.

[BarryK]

I may try booting USB to commandline and changing the sna xorg.conf.d file to DISABLED to see if I can run from USB.

Note that you can easily make any changes to Easy usb stick, running another Linux, plug in the Easy usb stick, mount the second partition, and /mnt/<second partition>/.session has all the files, change anything you want.

That's an easy way to put in the new 'xwin'.

[rerwin]

Your tests are indicating that X is starting too soon, the kernel video drivers not loaded.

So, I have modified /usr/bin/xwin to wait until they are loaded. Try the attached, instead of that other recommendation to uncomment "udevadm settle".

If you watch bootup, just before X starts you should see some output.

Another possibility is to try the 'xf86-video-nouveau' PET:

http://distro.ibiblio.org/easyos/amd64/ ... pyro64.pet

Easy Pyro64 0.8.x is using xf86-video-nouveau compiled in OpenEmbedded, whereas the PET was compiled in a running Easy.
Maybe there is a difference, worth a try.

Neither change affected the problem. I am unable to successfully re-create using nouveau with modesetting and have never gotten to a desktop with nouveau and (X driver) nouveau, with or without the "settle" activation. I attach the Xorg log obtained with the xwin loop, the packaged nouveau X driver and udevadm settle uncommented.

I don't see in the xwin loop that anything is being checked other than a test for blacklisting. It always finds the vendor ID and loops 30 times, even if I change the sleep to "1", for 30 seconds (which is about how long my wireless module took to load in Easy).

The attached log shows the hardware supported by the nouveau X video driver, but does not show my VGA card:

• 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] [10de:03d0] (rev a2)

After a search, I see an example log entry, "Chipset: C61 (NV4C)", which is listed: "GeForce 6 (NV4x)". So the card seems to be supported by nouveau.

Looking further, I found a page that implies some limitations of this card:
https://h-node.org/videocards/view/en/6 ... ---rev-a2-

FWIW, I see that it is apparently supported by the nvidia-304xx proprietary driver.

[BarryK]

I don't see in the xwin loop that anything is being checked other than a test for blacklisting. It always finds the vendor ID and loops 30 times, even if I change the sleep to "1", for 30 seconds (which is about how long my wireless module took to load in Easy).

In the case statement, this line picks up when the kernel module is loaded:

Code: Select all

   *"*) echo -n "${aVID/*"/} "; continue ;;

Testing on my 2011 Acer laptop:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"' | cut -f 4,12 -d '"'
8086"i915
10de"nouveau

...which the case statement picks up.

Or, just run this to see all output:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"'
00:02.0 "Class 0300" "8086" "0046" "1025" "0488" "i915"
01:00.0 "Class 0300" "10de" "0df1" "1025" "0488" "nouveau"

...that last field only appears after the driver has loaded.

Note, it has to be the busybox lspci, the full version works differently.

I am not using the nvidia graphics in this laptop, so could have blacklisted the 'nouveau' module. If I had done that, then would get:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"'
00:02.0 "Class 0300" "8086" "0046" "1025" "0488" "i915"
01:00.0 "Class 0300" "10de" "0df1" "1025" "0488"

...which is why I put in the blacklist testing, otherwise it would keep looping until times out.

[BarryK]

The attached log shows the hardware supported by the nouveau X video driver, but does not show my VGA card:

• 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] [10de:03d0] (rev a2)

After a search, I see an example log entry, "Chipset: C61 (NV4C)", which is listed: "GeForce 6 (NV4x)". So the card seems to be supported by nouveau.

Looking further, I found a page that implies some limitations of this card:
https://h-node.org/videocards/view/en/6 ... ---rev-a2-

You could try turning off glx:

https://unix.stackexchange.com/question ... n-in-linux

The arch linux page has some useful suggestions:

https://wiki.archlinux.org/index.php/nouveau

If you are still having problems loading the module or starting X server append nouveau.config=NvMSI=0 to your kernel parameters

Specific Nvidia chips with Nouveau may give random system lockups and more commonly throw many kernel messages, seen with dmesg. Try adding the nouveau.noaccel=1 kernel parameter.

[BarryK]

Specific Nvidia chips with Nouveau may give random system lockups and more commonly throw many kernel messages, seen with dmesg. Try adding the nouveau.noaccel=1 kernel parameter.

Well, that can be done by editing /etc/modprobe.d/nouveau.conf

Code: Select all

options nouveau modeset=1 noaccel=1

I notice, running "modinfo nouveau", that there is also a "nofbaccel" parameter.

[foxpup]

FWIW, I see that it is apparently supported by the nvidia-304xx proprietary driver.

I have similar card as rerwin - GeForce 7 Series, don't know exactly, I am not near it, driver is 304 too - and same problem with booting straight to X, as reported before.
Could compiling the 304 nvidia driver help? May be a problem to compile it though because the kernel in Easy is recent, nvidia may not have kept up.

[rerwin]

Try adding the nouveau.noaccel=1 kernel parameter.

Well, that can be done by editing /etc/modprobe.d/nouveau.conf

Code: Select all

options nouveau modeset=1 noaccel=1

Whenever I modify /etc/modprobe.d/nouveau.conf, it gets changed to:
options nouveau modeset=0
by the time it is needed during reboot.

I recall that early on in my use of 0.8.1, I changed the modeset in nouveau.conf from 1 to zero. Could that change have been saved in a snapshot somewhere and is getting restored at bootup, overriding anything I might have changed further in nouveau.conf? Even if I delete nouveau.conf in .sessions, instead of the default "modeset=1" version the "modeset=0" version reappears as the current setting.

So, that is preventing me from trying the 'noaccel=1' addition.

BTW, the 'busybox lspci -m -k' command gives:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b" "nouveau"
in quirky, but:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b"
in easy, anytime during the session. So, the question is "why is it not showing up?" Lsmod shows it as loaded when I use either the nv or nouveau X driver:

Code: Select all

nouveau              1572864  0
mxm_wmi                16384  1 nouveau
wmi                    20480  2 mxm_wmi,nouveau
video                  36864  1 nouveau
hwmon                  20480  2 k8temp,nouveau
i2c_algo_bit           16384  1 nouveau
ttm                    86016  1 nouveau
drm_kms_helper        126976  1 nouveau
drm                   307200  3 nouveau,ttm,drm_kms_helper
agpgart                32768  3 nouveau,ttm,drm

[BarryK]

Whenever I modify /etc/modprobe.d/nouveau.conf, it gets changed to:
options nouveau modeset=0
by the time it is needed during reboot.

I recall that early on in my use of 0.8.1, I changed the modeset in nouveau.conf from 1 to zero. Could that change have been saved in a snapshot somewhere and is getting restored at bootup, overriding anything I might have changed further in nouveau.conf? Even if I delete nouveau.conf in .sessions, instead of the default "modeset=1" version the "modeset=0" version reappears as the current setting.

So, that is preventing me from trying the 'noaccel=1' addition.

BTW, the 'busybox lspci -m -k' command gives:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b" "nouveau"
in quirky, but:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b"
in easy, anytime during the session. So, the question is "why is it not showing up?" Lsmod shows it as loaded when I use either the nv or nouveau X driver:

Code: Select all

nouveau              1572864  0
mxm_wmi                16384  1 nouveau
wmi                    20480  2 mxm_wmi,nouveau
video                  36864  1 nouveau
hwmon                  20480  2 k8temp,nouveau
i2c_algo_bit           16384  1 nouveau
ttm                    86016  1 nouveau
drm_kms_helper        126976  1 nouveau
drm                   307200  3 nouveau,ttm,drm_kms_helper
agpgart                32768  3 nouveau,ttm,drm

Oh wow

I am running Easy 0.8.1, with that modified 'xwin'.

I edited /etc/modprobe.d/nouveau.conf:

Code: Select all

options nouveau modeset=1 noaccel=1

Rebooted, yep, my change is still there.

There is nothing that I know of that will remove your edited file. A previous snapshot will not affect anything.

If you edit /etc/modprobe.d/nouveau.conf, you can verify your changed file is in /mnt/sdb2/.session/etc/modprobe.d

You could even be extra careful and type "sync" in a terminal to make sure it is flushed.

Then reboot, the .session folder gets loaded as the rw layer by aufs. There is nothing that will erase or change that file.

You could create/change any other file, verify that it is still there after a reboot.

As to why lspci is not showing "nouveau", that is another mystery. It does for me.

What about trying the full 'lspci'. Currently using my midi-tower, which only has intel video:

Code: Select all

# lspci -nk -d ::0300
00:02.0 0300: 8086:0102 (rev 09)
	Subsystem: 103c:2ab6
	Kernel driver in use: i915

EDIT:
I wonder if all required firmware for the nouveau driver got loaded? Try:

Code: Select all

# dmesg | grep -i firmware

...see if any msgs about missing firmware.

Note, the firmware for the nouveau kernel driver is at /lib/firmware/nvidia

Nah, all nouveau firmware is there, I just checked. There is a utility for that:

Code: Select all

# updategpumoduleslist.sh

then look at /tmp/gpudrmfirmwaremissing

[Billtoo]

I installed dosbox-0.74debian3-x86_64-1.txz from Fatdog64 and it works well.

[BarryK]

Even if I delete nouveau.conf in .sessions, instead of the default "modeset=1" version the "modeset=0" version reappears as the current setting.

You must never edit the .session folder directly, while Easy is running.

Unlike the puppies, aufs in the kernel used for easy/quirky is configured not to recognize changes from within a layer. This limitation makes aufs faster.

If you do modify .session, it will have unknown affects. You can edit it when Easy is not running.

[scsijon]

Came across a problem for you.

It looks like a download with sfsget to it's set folder (repository/easy-0.8.1) is not checking that folder to see if the .sfs requested is already there before trying to download it.

I already had devx-0.8.1-pyro64.sfs downloaded and loaded via the easy bootmanager and tried to download the newer kernel_src, but accidentally marked the devx again. Cafene shortage! It deleted the existing devx-0.8.1-pyro64.sfs from the directory and started downloading it again, rather than what I would of expected, which was to warn me it's already there and asking permission to proceed. I didn't expect it to be able to delete a loaded .sfs either.

Any chance to sort this please.

Got to say this one seems to have speeded things up from 0.6, the last i've had on a stick and testing with.

[rerwin]

Unlike the puppies, aufs in the kernel used for easy/quirky is configured not to recognize changes from within a layer. This limitation makes aufs faster.

If you do modify .session, it will have unknown affects. You can edit it when Easy is not running.

Got it. Thank you.

From outside Easy, I deleted the nouveau.conf from .session. In Easy, using the nv X driver, I updated nouveau.conf from modeset=1 to that plus noaccel=1. After changing to the nouveau drivers, rebooting to the command line showed nouveau.conf to be as I set it. But xwin failed as before, producing the same messages. After the failure, nouveau.conf contained modeset=0, leading me to conclude that the failure caused the acceleration to be disabled, possibly as an attempt to recover.

When I used the nouveau.conf with noaccel, etc., and chose 'nv' as the X driver, xwin also failed! NV claims that a kernel module claims the VGA device, when nouveau.conf has the added settings, but not with modeset=0, meaning that acceleration impacts nv. So be it.

So, I have to use nv with only the modeset as 0, to get to a desktop. With the nv x driver, kernel driver nouveau is loaded, as there is no nv kernel driver.

One thing I think I noticed (yesterday), when booting with X driver nouveau and the .conf values set to "1", was that the value from the 'lspci -m -k' command was '10de"nouveau nouveau', implying that the card was recognized right away. Even so, the X server crashed, as usual. (I modified xwin to to add that to the progressing count line before each number. All other times it shows only '10de'.)

[BarryK]

Unlike the puppies, aufs in the kernel used for easy/quirky is configured not to recognize changes from within a layer. This limitation makes aufs faster.

If you do modify .session, it will have unknown affects. You can edit it when Easy is not running.

Got it. Thank you.

From outside Easy, I deleted the nouveau.conf from .session. In Easy, using the nv X driver, I updated nouveau.conf from modeset=1 to that plus noaccel=1. After changing to the nouveau drivers, rebooting to the command line showed nouveau.conf to be as I set it. But xwin failed as before, producing the same messages. After the failure, nouveau.conf contained modeset=0, leading me to conclude that the failure caused the acceleration to be disabled, possibly as an attempt to recover.

When I used the nouveau.conf with noaccel, etc., and chose 'nv' as the X driver, xwin also failed! NV claims that a kernel module claims the VGA device, when nouveau.conf has the added settings, but not with modeset=0, meaning that acceleration impacts nv. So be it.

So, I have to use nv with only the modeset as 0, to get to a desktop. With the nv x driver, kernel driver nouveau is loaded, as there is no nv kernel driver.

One thing I think I noticed (yesterday), when booting with X driver nouveau and the .conf values set to "1", was that the value from the 'lspci -m -k' command was '10de"nouveau nouveau', implying that the card was recognized right away. Even so, the X server crashed, as usual. (I modified xwin to to add that to the progressing count line before each number. All other times it shows only '10de'.)

Yeah, if you look at /usr/sbin/xorgwizard-cli, line 1112, you will see that if 'nv' chosen, then "options nouveau modeset=0" is written to nouveau.conf, then there is a reboot.

Otherwise, there is a conflict between the two.

Another alternative would be to blacklist the nouveau kernel driver.

I understand that you meant "busybox lspci -mk", but note, regarding "lspci -mk", that doesn't work with the full lspci, strangely enough (doesn't show the drivers). But "lspci -nk" does.

[BarryK]

Came across a problem for you.

It looks like a download with sfsget to it's set folder (repository/easy-0.8.1) is not checking that folder to see if the .sfs requested is already there before trying to download it.

I already had devx-0.8.1-pyro64.sfs downloaded and loaded via the easy bootmanager and tried to download the newer kernel_src, but accidentally marked the devx again. Cafene shortage! It deleted the existing devx-0.8.1-pyro64.sfs from the directory and started downloading it again, rather than what I would of expected, which was to warn me it's already there and asking permission to proceed. I didn't expect it to be able to delete a loaded .sfs either.

Any chance to sort this please.

Got to say this one seems to have speeded things up from 0.6, the last i've had on a stick and testing with.

Ok, have written that into my to-do list.

[scsijon]

Started on laptops due to go back

Lenovo Ideapad 11".

And another 2 problems, sorry.

1-
Menu>
setup>
easy os installer>
Brings up a Welcome to easy Installer>
clicking on either button 'View in browser, brings up barryk.org/cgi....., which of course are suspended pages.

2- Leave with me for now - see edit2 below
The driver for the pcie ssd doesn't seem to be loading, the emmc on the same laptop (usb bus) is so that's something. Maybe a pci/pcie bus-driver is also needed as only usb is listed under /dev/bus. I do have the kernel_src-4.14.27-patched.sfs loaded and thought that was all that was needed to be added. Any sugestions while I keep looking?
EDIT1: looking at the DOTconfig-4.14.27 line 689 # CONFIG_HOTPLUG_PCI_PCIE is not set. There's quite some others following also. https://www.kernel.org/doc/ols/2005/ols ... s-9-18.pdf seems th be the relevant doc.
EDIT2: A Lenovo Thinkpad, does find the ssd in /dev/disk/by-id with a sata3 SSD so it looks like it's a pcie thing. I shall ask Lenovo about it and get back to the list.

[Billtoo]

I installed 0.8.1 to my hp desktop on Mar 14th and use it often, palemoon
browser has updated, also learned of an extention for it so have installed that.
0.8.1 works well with the ATI graphics card in this pc.

Thanks.

[scsijon]

Not a problem really but...

Laptop 3 : Mine: Toshiba satellite L50D-C AMD-A6 with Radeon R4 Graphics - couple of years old, used for storyboarding nowadays as it's a 15".

I had problems on startup as it tried to automatically ONLY use the intel video driver.

Error was appearing as:
intel 800/900 Series VBIOS Hack : Version 0.5.3

VESA Bios extension not detected.
VESA Bios extension not detected.

Xorg Wizard Automatic has just run.
If you are reading this, then you are at the console without X running.
etc
etc

seems to have both radeon and intel video interfaces active,
can start it with the radeon driver as standard 1024x768 screen, just not a widescreen
both standard xorgwizard options fail giving

VESA Bios extension not detected.

as reason for fail if I try to set any standard or 16:9 Vesa options.

Took some time to get it up via modesetting PLUS the radeon driver but <ctl><alt><F1> still shows the "VESA Bios extension not detected" appearing on a new line every so often.

seems to run ok otherwise

EDIT1:
SSD: If the drive on a laptop is a sata SSD drive or a sata SSD M.2 2280 Card it's symbol is appearing as a normal Hard drive, if it's a emmc module on the motherboard or via a M.2 slot it's symbol is appearing as if it's a SD card. If it's a PCIe NVME it can vary between the SD card symbol or a black square so there must be some other possible connection for PCIe, maybe there is an alternate controller. I have asked for more information from the supplier.

EDIT2:
Most of the intel video laptops I have been playing with have now been tested and are ok with either 0.6 or 0.8.1. Now to have fun with the alternate video controllers and the amd stuff. And there are a couple of dual touchscreen models included. And yes I did say screens, no pad or keyboard just two touch screens (each 15" or 17"). Designed for graphics, animation, Film industry, and the like, won't be cheap when they are released as 32/64 Gram and 500G/1TB SSD and hi-end processors are all promised. Not really for this uni stuff, but I asked and got a yes .