Installing Porteus onto a flashdrive from Arch results with /dev/media [SOLVED]

[eggbladder]

Thank you. I will use this file, however id like to learn how to do this so i can use porteus to its full potential

Will update when all tests are done with this file

[eggbladder]

fat32 on graphical mode, using UEFI mode, boots into black screen.
fat32 on graphical mode, using legacy boot, flashes text at me over and over, produces a garbled screen, then a black screen

fat32 on text mode, using UEFI mode, boots into black screen. No terminal.
fat32 on text mode, using legacy boot, flashes into a garbled screen, goes black, then flashes text on my screen with a blinking cursor on the top left. then it... boots into graphical mode... (i have zero clue what happened here. i didnt even type in xinit or anything, there was no terminal.) (i think i accidentally booted into save to RAM)
after trying fat32 with text mode on legacy boot again, it prints "
xorg failed to start up - using modesetting driver on next try

xorg failed to start up - removing invalid etc/x11/xorg.conf
"
8 times. then it says "Id "x1" respawning too fast: disabled for 5 minutes."

for ext4 with graphical mode on legacy (uefi doesnt work), it boots into the menu with the run level 4, then after a while it goes to a black screen with a garbled image flashing. then it goes to a black screen and after a while, shows the "xorg failed to start up" thing again. it then flashes a garbled image at me over and over. then, it shows me a garbled image and keeps it there.
for ext4 with text mode on legacy,

ext on text mode boots into the terminal fine. running init 4 just shows a black screen.

ext on save to ram mode, however, boots perfectly fine. Pretty fast, the display isnt all messed up like in Debian, and everything works normally. Maybe some config file with saving to ram does something better than before.

[eggbladder]

after some tinkering, i realized that Porteus refuses to work if saving changes, apparently. whether on ext4 or fat32

[eggbladder]

some more tests:
when booting from ram, with no storage
sometimes, it does not work at all (garbled screen to a black screen)

when it does work, it flashes screens between a black screen w/ a text cursor indicator thing (the thing that flashes when youre typing text in a terminal), and for a split second, the welcome message that tells you the commands to poweroff and the logins for root and guest

it does that a few times then it boots completely into xfce.

[roadie]

some more tests:
when booting from ram, with no storage
sometimes, it does not work at all (garbled screen to a black screen)

when it does work, it flashes screens between a black screen w/ a text cursor indicator thing (the thing that flashes when youre typing text in a terminal), and for a split second, the welcome message that tells you the commands to poweroff and the logins for root and guest

it does that a few times then it boots completely into xfce.

That sounds like the same thing I experienced, I have an AMD video card too. Check /var/log/lxdm.log and lxdm.log.old. I think you may find that lxdm shows many retries before X finally starts.

[eggbladder]

i got the logs from when it worked, as i cant exactly get the logs from when it doesnt work.
the .old says that it started it in 8 retries. what did you do to fix this?

[roadie]

@eggbladder

If it's 8 retries when it works, it's probably like the 50-60 I was getting. I fixed it by removing lxdm and replacing it with slim, which used to be the default in Porteus. IIRC, it was replaced because it was causing issues with a root user login. I never boot to a root user, so not an issue for me.

There is an 003-lxde-slim.xzm at this link should you want to try it:

https://www.mediafire.com/file/68vh2xkq ... m.xzm/file

It boots well on my machine and has lxdm replaced with slim. Just replace the 003-lxde.xzm in the porteus folder.

EDIT:
You could also try PorteuX-v0.8 as my install still uses lxdm and is booting as fast as my builds with slim do. The logs show usually 2 retries. I haven't found anything online regarding this issue, but it seems that lxdm and AMD video cards don't play nicely together.....I suspect that AMD is the cause.

[eggbladder]

booting into slim (legacy) with graphical mode takes a long time; eventually, it does show something graphical, but its the failed to login thing you mentioned.
booting into slim w/ copy2ram works! consistently!
thank you, very appreciated.
post is solved (as far as i can tell)

[roadie]

@eggbladder

Good to see it's working, though it would be nice to know why it only works with the copy2ram cheatcode. And, I'm not clear as to what you mean by "booting into slim (legacy) with graphical mode".

Can you post the result of this after a successful boot:

Code: Select all

cat /proc/cmdline

[eggbladder]

Yes i may.
"booting into slim (legacy) with graphical mode" means that im booting into Porteus using the graphical mode option, in legacy (BIOS) mode (as opposed to UEFI), with the slim LXDE module.
The results of cat /proc/cmdline while booting into slim (legacy) with Copy to RAM is

Code: Select all

quiet BOOT_IMAGE=/boot/syslinux/vmlinuz copy2ram initrd=/boot/syslinux.initrd.xz

[eggbladder]

Do you think that AMD drivers would be helpful?

[Rapha_]

How would i remove /lib/firmware/amdgpu_raven_dmcu.bin?

here's one done for you : 000-kernel-test.xzm
place it in the porteus/base folder and move or rename/back up the original so it doesn't end in .xzm.

@eggbladder

Have you tried the method suggested by ncmprhnsbl ? Does it work?

[eggbladder]

Thats what ive been using with every test after he recommended that, so yes i have been.
it works better? i think? i have tested using it more than not using it

[roadie]

Do you think that AMD drivers would be helpful?

I compiled an amdgpu driver today, but it made no difference with lxdm or slim. I'll try different settings in the kernel config next time I compile a kernel. While I posted that PorteuX-v0.8 has been booting well with lxdm, I did get a kernel error yesterday. The kernel wasn't tainted and it didn't appear to affect anything. It was related to amdgpu of course.

You might try some of these kernel parameters on the cmdline:

Code: Select all

radeon.si_support=0 
radeon.cik_support=0 
amdgpu.si_support=1 
amdgpu.cik_support=1 
amdgpu.dc=1 
amdgpu.dpm=1 
amdgpu.modeset=1

I can't say they helped me, apart from the amdgpu.dc=0 which I used in the past for kernel-5.10

[eggbladder]

where do i put those commands?