Lost Boot Into Root With Image-Resurrected Flash

[jimwg]

Greetings!

While tinkering with a nonessential flash copy (reinstalling from a gnome-disk created backup image of 3.0 final with XFCE), I found that I don't automatically boot into root now, but instead into the cyan XFCE Login screen (which also doesn't allow you to create a new session but only launch what was previously there). My proteus.cfg is unchanged as below. I tried swapping and booting with earlier xorg and kernel flies just to see but no change. Could it be some corrupted boot-up config in the Changes file (which I'm not touching now because a lot unique is in there, but I'm game to try by your info!) Aside, quite a few images also had their links broken in a few folders, but this shouldn't occur with reconstituted image files, right? Maybe has to do because Copy was on as well?

Add to this, when I click on USM it only drops a terminal screen with a usm usage menu.

Code: Select all

PROMPT 0
TIMEOUT 90
UI vesamenu.c32
DEFAULT xfce
MENU BACKGROUND porteus.png
MENU TITLE Porteus-v3.0 32bit

MENU WIDTH 30
MENU MARGIN 2
MENU ROWS 10
MENU HELPMSGROW 17
MENU TIMEOUTROW 28
MENU TABMSGROW 15
MENU CMDLINEROW 22
MENU HSHIFT 4
MENU VSHIFT 5

	menu color screen	37;40      #00000000 #00000000 none
	menu color border	30;44      #00000000 #00000000 none
	menu color title	1;36;44    #ffF6FF00 #30003f07 none
	menu color unsel	37;44      #ffffffff #00000000 none
	menu color hotkey	1;37;44    #ff8037b7 #00000000 none
	menu color sel		7;37;40    #ff111B78 #003f7fbf none
	menu color hotsel	1;7;37;40  #ffaf67f7 #003f7fbf none
	menu color scrollbar	30;44      #00000000 #00000000 none

	menu color tabmsg	31;40      #ffB6F538 #00000000 none
	menu color cmdmark	1;36;40    #ffff0000 #00000000 none
	menu color cmdline	37;40      #ffffffff #ff000000 none
	menu color pwdborder	30;47      #ffff0000 #00000000 std
	menu color pwdheader	31;47      #ffff0000 #00000000 std
	menu color pwdentry	30;47      #ffff0000 #00000000 std
	menu color timeout_msg	37;40      #ff809aef #00000000 none
	menu color timeout	1;37;40    #ffb72f9f #00000000 none
	menu color help		37;40      #ffD5F538 #00000000 none
	menu color msg07	37;40      #90ffffff #00000000 std

LABEL xfce
MENU LABEL root-boot mode (XFCE)
KERNEL vmlinuz
APPEND initrd=initrd.xz changes=UUID:3ce1d360-f81f-4c21-9a05-c60af1ab09d8/porteus fsck copy2ram login=root
TEXT HELP
    Run Porteus the best way we can.
    Try to autoconfigure graphics
    card and use the maximum
    allowed resolution
ENDTEXT

Thanks for any assist.

[jimwg]

It appears that without printing.xzm, Bleachbit and USM menus don't appear. Is this correct? Something app-pruning flash memory-strapped newbies ought know. Also, what controls activating the session selection box in the cyan XFCE Login screen because I just can't get it to input and create a new session.

Thanks!

Jim in NYC

[brokenman]

To test if your changes are causing the problem .... at the boot menu screen, hit the tab button and then remove changes=UUID:3ce1d360-f81f-4c21-9a05-c60af1ab09d8/porteus from the boot line. Use the left arrow button to navigate to the end of the changes=xxx code (the letter 's') then hit ctrl + w to remove the entire block.

It appears that without printing.xzm, Bleachbit and USM menus don't appear. Is this correct?

No. The only thing that determines if a menu item appears is the file /usr/share/applications/somefile.desktop
Sounds to me like you have some funky changes.

[jimwg]

To test if your changes are causing the problem .... at the boot menu screen, hit the tab button and then remove changes=UUID:3ce1d360-f81f-4c21-9a05-c60af1ab09d8/porteus from the boot line. Use the left arrow button to navigate to the end of the changes=xxx code (the letter 's') then hit ctrl + w to remove the entire block..

Still occurs, even if I use a totally virgin porteus.cfg or delete the boot and modules folders and reinstall Porteus with my Documents folder there intact. The cyan XFCE Login splash screen's session input box won't accept input to create a new session. This would imply to me that there's a corrupting file in Documents that the boot-up/login sequence is tapping, yes? If so, how could I track it down to obliterate it?

ADD: Or could it be a bad permissions preventing write access to the login page's new session input portion?

Thanks for education!

Jim in NYC