I still don't know when ceni runs during the boot process.   I thought it was only run manually.   For example there is no ceni script under /etc/init.d/.   I understand it was an attempt to supply a point of reference.

PS: here I can get a list of framebuffer modes with: Copying this output may be easier than taking a picture of the vga=ask menu.

Reward: 32-Gig usb-3.0 live-usb to the first person who can tell me a fast and easy way to find out if the vga=ask menu was used and if so, which mode was selected by the user, without having to rely on a table that translates resolutions and depths back to the selection.    I can try to figure it out using the resolution and depth reported in files under /sys/class/graphics/fb0/ but that doesn't always work because different systems use different vga=xxx codes to get the same resolution and depth.  IOW, if someone uses the vga=ask menu to select mode 0x31b then I'd like there to be a file or something somewhere that will give me either"0x31b" or"795" directly so I know for sure which vga=xxx mode to use for the next boot so vga=ask only needs to be used once.

Is it possible you entered the new password incorrectly?

I'm sure I entered the password for LUKS (?) volume decryption correctly three times. If I find time I will try to create an encrypted USB stick again and see if I can confirm it. Anyway, antiX having and encryptied live USB option is a big deal for some users who will be greatful for sure!

I will try to find out where the font size switch happens. hwinfo --framebuffer gives no output. (sic!) I also inspected Xorg.0.log but found nothing. However setting 800x600 at live boot menu F8 (IIRC) makes the VGA selection dialog not appear. I will paste /etc/live/config/font in a moment...
$ cat /etc/live/config/font
54.40: 140 800: udev-rule-92: Uni2-Terminus12x6
56.38: 140 1024: udev-rule-92: Uni2-Terminus12x6
56.89: 140 1024: keyboard-setup.sh: Uni2-Terminus12x6

The machine I'm testing with is a 10" Intel Atom netbook.

It is under the"Console Utilities" sub-menu.  That menu only shows up if you run antiX-cli-cc in a console (not a terminal window).  That's because some commands, such as console-width-select only work when you are in a console.

Ok, I found it there, but I cannot use it. When I select any menu item, on my screen the old text stays in place, I would guess a"clear" command is missing after selection of a menu item. Therefore I cannot use this function on this screen and would need an external monitor. I agree with @skidoo, that a larger font size is a great thing for a 1900x... screen, I'm enjoying the new CLI apps there, but TTY needs to work on small screens as well. :-/

Here are some photos.

If I apply nomodeset (or i915.modeset=0) boot parameter the console font doesn't switch to bigger size (and even the antiX frame stays), but I get 800x600 in X and this is not the highest 1024x600. Aha!! In boot menu there is 1024x768, but there is no 1024x600! Maybe let's check if this mode can be enabled?

I switched the default session to JWM instead of min-JWM and now xrdb merge .Xresources works when present in .desktop-session/startup and also the wallpaper survives a reboot, but I cannot make my keyboard layout persistent, not with CC at least nor with"setxkbmap de".

Wow! Thanks for all of the great information eugene-b!

I won't bother quoting because it is a pain now.

The"clear" command is not missing.  If it were then everyone (including me) would have the problem you are having.  There are a couple of commands to try that might help you limp by for now. "a" redraws the screen. "A" clears the screen then redraws it. "c" cycles through 3 different color schemes.

I  don't see that network connection information on my boot screen.  It certainly appears to be coming from the networking init.d script (not from ceni).   That information is not supposed to show up on the screen.  It is supposed to go into the file /var/log/init.d-networking.log.    I'm curious what the rest of the"Configuring network interfaces in background" line says but I guess it is just getting stomped on by the output of the ifup command.

The font file indicates the screen is starting out 800 pixels wide (which jives with the 800x600 vga mode you have to use) but then it switches to being 1024 pixels wide when udev runs which should be making the fonts appear *smaller*.   Ah, I wonder if the problem is related to the Debian code that runs almost at the end of the boot process.    Here when I run with an 800x600 framebuffer, the screen is 126 characters wide and the same Terminus12x6 font is selected (which is the smallest font available).

After you boot and you are in the console, what is the output of"stty size"?  Here when I use an 800x600 framebuffer and use"nomodeset" then the answer is 42,126.   Also, what is in the file /sys/class/graphics/fb0/virtual_size.

Please try using the"nomodeset" cheat and see if that fixes any of these problems.  The cause is not your smaller screen.  The smallest font is being selected to squeeze in as many characters as possible.   At the risk of appearing like I'm passing the buck, I think your modesetting graphics driver could be causing these problems.  It doesn't account for the ifup  output appearing on your screen (does any of it end up in the /var/log/init.d-networking.log file?) but it would account for the clear command not working and for the console fonts breaking after your modesetting driver kicks in.

We had problems similar to this in recent versions of Virtual Box.  They  added a modesetting driver (that takes control of the consoles) and it exhibited similar but not identical broken behavior.  For example, it had problems with the"clear" command inside of antiX-cli-cc.  If the modesetting driver isn't causing some of your problems then my next guess is that your machine is haunted by evil spirits and needs an exorcism. 

 

I booted normally on the netbook (without nomodeset), switched to TTY2 and ran antiX-cli-cc - it starts but the text flashes (almost invisibly) after a moment; when I select a menu item and press enter the console become unresponsive, no shortcuts work, neither a nor A nor c. Before I press enter they all work, but I get this ugly things you can see on the above photo where one line ends with < and the next starts with q. I can quit antiX-cli-cc with q.
"stty size" gives 18 64.
/sys/class/graphics/fb0/virtual_size is 1024,600.

I will supply the same infos after booting with nomodeset. Edit: Here we go:
"stty size" in TTY (now with small font and antiX frame) gives 42 126.
/sys/class/graphics/fb0/virtual_size is 800,600.
And my graphical session is 800x600, too, which is suboptimal.
I will try to reset some thing with antiX-cli-cc -> Console Utilities now.

About network boot text: I think I misconfigured ceni, allthough I mean to have selected the defaults, I will try changeing"allow-hotplug" for"auto".

I would also like to find out how to change the console keymap best, because X now has got"de", but TTY has got"en". (Probably with antiX-cli-cc -> Console if it only worked.)

BitJam wrote: I still don't know when ceni runs during the boot process.   I thought it was only run manually.   For example there is no ceni script under /etc/init.d/.   I understand it was an attempt to supply a point of reference.

you are correct.  ceni itself doesn't run.  Its really a connection editor, with the actual connections being brought up by the various networking scripts.  

eugen-b, can you give us the"inxi -F" for that machine.   There are usually 2 different video chipsets for those older netbooks.  One is usually pretty easy to work with, the other is a PITA.  Your output will give us the info to know which you have.

dolphin_oracle wrote: eugen-b, can you give us the"inxi -F" for that machine.   There are usually 2 different video chipsets for those older netbooks.  One is usually pretty easy to work with, the other is a PITA.  Your output will give us the info to know which you have.

It is here

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was"antix-17-a2-32-bit-only-for-testing-t6901.html#p50747"
linktext was:"antix-17-a2-32-bit-only-for-testing-t6901.html#p50747"
====================================

Number #16 in that topic.

Resetting console font with antiX-cli-cc to the smallest Terminus available, while having booted with nomodeset, did not help on reboot without nomodeset. The characters are still large in TTY.
Will try selecting other available fonts after having booted with nomodeset. Edit: No, that doesn't work neither. The same behaviour as before, font gets reset to large shortly before X starts. If antiX had systemd I would have looked into journalctl. ;P

eugen-b wrote:"stty size" gives 18 64.
/sys/class/graphics/fb0/virtual_size is 1024,600.

I will supply the same infos after booting with nomodeset. Edit: Here we go:
"stty size" in TTY (now with small font and antiX frame) gives 42 126.
/sys/class/graphics/fb0/virtual_size is 800,600.
And my graphical session is 800x600, too, which is suboptimal.

This indicates your modesetting driver may be broken.  The problems with the cli-cc also point in this direction.  Did using"nomodeset" help with cli-cc problems?   I understand that you would prefer to not use"nomodeset" but there might not be much I can do to fix the problems you have in the console.   If you find a console font that works for you then you could trying editing the file /etc/default/console-setup to use that font following the example they give for Braille.  Are you specifying a language in the bootloader?  That would cause different code to run to set up the console font.  I expect the contents of /etc/default/console-setup to specify the 12x6 Terminus font that was shown in the /etc/live/config/font file.  If it has something different then that would indicate there is a problem I might be able to fix.   But that file has  to be correct for it work correctly with"nomodeset".  The font file showed that we were using the same 12x6 font after the modesetting driver changed the screen resolution.

About network boot text: I think I misconfigured ceni, allthough I mean to have selected the defaults, I will try changeing"allow-hotplug" for"auto".

Yes.  If you used"auto" instead of"allow-hotplug" then that text would appear and it would also slow down the boot process.  That's just the way it is designed and I don't think there is anything I can do about it.  Perhaps that mystery is now solved.  I guess I could hide that text but it is good signal that the system was misconfigured.   The only interface that should be"auto" is"lo".   The idea is that it gets brought up first (which is very fast and quiet) and we wait for that to happen before bringing up the real interfaces, ethN and wlanN.   It's kind of a crazy system.  Any interface you set to"auto" will get brought up when lo is brought up and the entire system will wait for it to come up before going on to the next step.  If you set an existing ethN interface to"auto" and there is no cable plugged in then there may be a very long delay before the system finishes booting.

I would also like to find out how to change the console keymap best, because X now has got"de", but TTY has got"en". (Probably with antiX-cli-cc -> Console if it only worked.)

On the live system the keyboard layout should be set when you specify a language or when you use the explicit"kbd=xxx" cheat.   We didn't build a tool to help you manually set the keyboard layout in the console.  The following command should work: Debian has some very fancy code that tries to have the console keymap match the keymap specified for X.   It is quite possible this fancy code is broken.  The simple loadkeys command may be all you need.   This stuff got all shifted around (and broken) between antiX-16 and antiX-17, probably due to Debian jumping on the systemd bandwagon.  I would not be at all surprised if the fancy code to set the console keyboard layout also got broken.    You could also try the cheat"conkbd=de" which will run loadkeys for you but if you also specify a language then Debian may try to set the console keymap again later in the boot process which would clobber what you did with conkbd. 

From what I can piece together, Debian made a bunch of last-minute changes to their sysv init system between antiX-16 and antiX-17 to try to make it more compatible with systemd or something and then they just dropped it and left it in a broken state.   On top of that, the people who wrote the new code didn't seem to know what they were doing.  For one small example, they put default console keymap or console font stuff in files under /tmp that need to be accessed during the boot process.    Of course this breaks on the live system but it will also break on some installed systems since you are not supposed to rely on anything under /tmp surviving a reboot.   

One of the reasons it took us so long to figure out the networking is that we had incorrectly assumed there was some sense in the existing code.  We thought there were functioning overlapping code bases that were interfering with each other.  But the code was just broken, partly due to their last-minute half-hearted attempts to make it more systemd compatible or something.  This is a turning point for antiX/MX because up until now we tried to run a stock Debian system after the install.  But the stock Debian system is now broken if you use sysv init.

fast and easy way to find out if the vga=ask menu was used and if so, which mode was selected by the user, without having to rely on a table that translates resolutions and depths back to the selection.    I can try to figure it out using the resolution and depth reported in files under /sys/class/graphics/fb0/ but that doesn't always work because different systems use different vga=xxx codes to get the same resolution and depth.  IOW, if someone uses the vga=ask menu to select mode 0x31b then I'd like there to be a file or something somewhere that will give me either"0x31b" or"795" directly so I know for sure which vga=xxx mode to use for the next boot so vga=ask only needs to be used once.

/var/log/live/gfxsave.log explicitly reports this.
On an installed system... idunno. /var/log/Xorg.0.log reports only the"Kernel command line:" details

I tried posting a reply but it was blocked by the new forum software.   I don't know why.  I sent you a PM on the MX forums.

BitJam wrote:On the live system the keyboard layout should be set when you specify a language or when you use the explicit"kbd=xxx" cheat.

You won't believe me, that's why I took a picture and will upload it now, but kbd=de solved all the problems with TTY! 
(FWIIW, conkbd=de doesn't get recognized as boot parameter.)
Now, I have German keyboard layout in TTY, the font size is ok (I set conwidth=120), antiX-cli-cc works. 
The font size doesn't become large shortly before X anymore. I also don't have the antiX frame in TTY as with nomodeset.