Search Results for 'boot from iso'

[Member melodie]

Anonymous wrote:

By design, the O/S installation-to-hard-disk process already removes itself (the installer package) from the installed system.
leafpad /usr/sbin/live-to-installed
(a script belonging to the “installer-data-antix” package)
Mentioned earlier, I would recommend declaring any additional customized removals within this script.

Hello,

I have checked the file, it does indeed have a removal entry near the beginning of the script, I also checked with grep that it is called by the minstall binary, the result is positive. But the installer is not removed at post install, and is still there once the system has rebooted.

The ISO is available, I pointed to the download page, would you be willing to check?

If you want to place a rc.local -ish script to check//remove during each startup, refer to
man update-rc.d

As I said, I can add the line in the said rc.local, because it replaces the current rc.local that seats in /etc during the live session only, and after that is automatically replaced again by the regular one. I’d rather have this desktop file on the Desktop during the live session only, in a way that uses the loop : that’s to say, use what is already there. I’ll try that next, starting tomorrow.

[Anonymous]

melodie, the snapshot tool contains a longstanding bug (reported across years) described as “I specify a custom namelabel for the boot menu, but the custom name is not displayed when I boot a system produced via the snapshot tool“. However, the symptoms of _that_ bug case do not include presence of % percent placeholders in the labelname. From a troubleshooting standpoint, we can’t guess whether you have encountered a separate, newly introduced, bug ~~ without hearing exact O/S version (e.g. antiX Full 17.4.1) (and, dist-upgrade was performed immediately prior to running the snapshot tool?) along with the exact installed versions of packages: “iso-snapshot-antix”, “remaster-antix”, “iso-template-antix”. During troubleshooting I would also ask: is the package “xorriso” currently installed on the machine performing the snapshot operation.

Skip the troubleshooting.
The following instructions should enable you to achieve the desired result.

1) Prior to launching isosnapshot, edit /etc/isosnapshot.conf and ensure that it contains this declaration:
edit_boot_menu=yes

2) Launch isosnapshot. During the workflow, when the “will now pause” dialogbox is displayed
and an editor window populated with “isosnapshot.cfg” opens…
ignore minimize (do not close/exit) that editor window.
(Do not close, because the snapshot operation will immediately resume upon closure of that editor window.)

3) While the isosnapshot program is paused, use a file manager (asRoot), and browse to /tmp directory.
Look for a /tmp subdirectory named “snapshot-123abc” (tailend is randomly chosen each time isosnapshot runs).
If you do not find it under /tmp, look for it under /home/snapshot/ ( e.g. /home/snapshot/snapshot-123abc/ )

To perform customizations, you will need to edit various (multiple) files.
After performing all desired edits, close that “auto-opened” editor window instance and the isosnapshot process will resume.

4) Don’t shoot the messenger. I’m attempting to coach you toward a successful outcome ~~ replies stating “should be easier” or “bugs should be fixed” will not be helpful here.

{work_dir}/iso-template/boot/syslinux/syslinux.cfg
{work_dir}/iso-template/boot/syslinux/readme.msg
    ^---- applicable to liveUSB boot menu
    
{work_dir}/iso-template/boot/isolinux/isolinux.cfg
{work_dir}/iso-template/boot/isolinux/readme.msg
    ^---- applicable to LiveCD boot menu
    
{work_dir}/iso-template/boot/grub/theme/theme.txt
{work_dir}/iso-template/boot/grub/grub.cfg

FWIW, these files wind up residing in the /boot subdirectory of the liveboot media, and they can be edited in place to customize an already-made liveUSB device. (This bit of trivia is not useful for someone intending to redistribute a customized ISO though.)

================

I believe the longstanding bug is due to the fact that only isosnapshot.cfg is presented for editing.
During liveboot, that cfg file is only referenced if isolinux (liveCD) is the bootloader.
The devs probably test in virtualbox, with the ISO set as a liveboot CD, and find “Hey, it works for me”.
However, for anyone booting liveUSB the syslinux bootloader is invoked.
Perhaps the configuration setting “make_isohybrid=yes” is expected to cause the syslinux bootloader to load isolinux.cfg (instead of syslinux.cfg)… but apparently, in practice, it is not doing so. Because the user never had easy opportunity to edit the copy of syslinux.cfg residing in the snapshot “work_dir”, the stock version of that file is perpetuated, and its content is evident during syslinux (liveUSB) boot sessions.

Because bugfixes and improvements to the upstream (MX) version of the snapshot tool have not been ported to the antiX 0.3.7 version (shipped in antiX19 beta, but absent from antiX gitlab repo), for local use I created a bespoke derivative version. Its workflow still remains a bit awkward but, yes, it does attempt to provide better inline instruction regarding customization. Many of the changes I’ve incorporated may not be regarded as desirable by the antiX/MX devs (the ui and helptext drown the user in details, are quite verbose), so I haven’t yet published the source code to gitlab.

[Member melodie]

manyroads wrote:

@melanie. whoo- rah. BunsenLabs is now running on antiX19b3. It booted cleanly and is operational. I needed to clean off all the standard desktops, slim and replace the display manager with lightdm. Tada!

I’ll begin working on building an antiX19 version of BunsenLabs Lithium as well as the one for MXLinux19b3.

If you wish to build your Bento Box using this base, I am happy to share it with you.

Hello manyroads,

it is very nice of you. Thank you! I am also happy to share the “Bento recipe” with you. There is a mind map of the files and dedicated configs here:
https://gitlab.com/bento-openbox ( mind map pdf : https://gitlab.com/bento-openbox/bento-filesystem/blob/master/Bento-Openbox-Filesystem.pdf which can help getting the idea on how it’s built )

for the time being it runs fine in the D610 Dell laptop, just until now I don’t get yet an ISO worth sharing.

One more issue I meet with: I can’t get zram config to work out of the box. I’d like it to run currently in the system. I tried the package from the repos, I tried also an ancient config which used to work in Debian ( https://phillw.net/isos/bento-ubuntu-remix/miscellaneous/Debian/zramconfig/ ), no way.

I someone wants to try and help find why it does not / cannot stick after reboot it would be nice (also it worked only once installed after I started it manually).

[Anonymous]

a way to avoid that and have the boot from ISO go straight to the desktop?

you can set autologin via ControlCenter gui

or by running this command from terminal:

python /usr/local/bin/slim-login

or by manually editing 2 lines within /etc/slim.conf

### Automatically login the default user (without entering the password)
### Set to “yes” to enable this feature
auto_login yes

### default user (leave blank or remove this line to avoid pre-loading the username)
default_user your_chosen_username

Make this change on the running system before launching the isosnapshot tool, and it will be reflected in the snapshot result.

[Member amidfour]

Hello to all. Apologies if this ends up being a repost, tried posting in Development, but the topic I created never showed up (could be a moderation thing, dunno). I’m new to antiX, but I have a few decades experience with Linux.

I think there’s a bug in the 19b3 live-usb-maker’s encrypted USB creation and how it interoperates with the 19b3 bootup scripts with live encrypted USB devices.

Debian buster added support for LUKSv2 (and argon2i/id), so unless ‘–type luks1’ is given to cryptsetup, it’ll go with luks2.

The basics:

I successfully can make encrypted 19b3 sticks using live-usb-maker from MX and from AntiX 17 using the 19b3 iso. They boot fine.

If I then use THAT 19b3 system to do a live-usb-maker to make another stick, it fails to boot. If I pick a custom install, encrypted, with a leading data partition, and choose to pick keys at boot time, it boots, but it’ll error out and say it can’t read the encrypted partition. For some reason, I couldn’t get the “encrypted full featured” option to boot at all, but haven’t really isolated that one, could have been bad luck.

I don’t really know the specifics of the antiX live/encrypted boot process yet (I’ll get there eventually, most likely), so I fixed it with a hammer:

I added ‘–type luks1’ to every instance of ‘cryptsetup luksFormat’ & ‘cryptsetup open’ in live-usb-maker.

And the resulting stick booted just fine.

I’ve also noticed some intermittently-odd behavior with live USBs in 19b3, including some that just won’t save BIOS settings while some will. Guessing there are still a few “live-usb-maker meets 19b3 boot” wrinkles to iron out.

-a4

Hello to all. I’m new to antiX, but I have a few decades experience with Linux. I’ve been trying all sorts of interesting things with antiX 17 & 19b3 in the past few weeks. And…

I think there’s a bug in the 19b3 live-usb-maker’s encrypted USB creation and how it interoperates with the 19b3 bootup scripts with live encrypted USB devices.

Debian buster added support for LUKSv2 (and argon2i/id), so unless ‘–type luks1’ is given to cryptsetup, it’ll go with luks2.

The basics:

I successfully can make encrypted 19b3 sticks using live-usb-maker from MX and from AntiX 17 using the 19b3 iso. They boot fine.

If I then use THAT 19b3 system to do a live-usb-maker to make another stick, it fails to boot. If I pick a custom install, encrypted, with a leading data partition, and choose to pick keys at boot time, it boots, but it’ll error out and say it can’t read the encrypted partition. For some reason, I couldn’t get the encrypted full featured option to boot at all, but haven’t really isolated that one, could have been bad luck.

I don’t really know the specifics of the antiX live/encrypted boot process yet (I’ll get there eventually, most likely), so I fixed it with a hammer:

I added ‘–type luks1’ to every instance of ‘cryptsetup luksFormat’ & ‘cryptsetup open’ in /usr/local/bin/live-usb-maker. And the resulting stick booted just fine.

I’ve also noticed some intermittantly-odd behavior with live USBs in 19b3, including some that just won’t save BIOS settings while some will. Guessing there are still a few “live-usb-maker meets 19b3 boot” wrinkles to iron out. And I’m guessing most have to do with cryptsetup/etc changes with LUKSv2.
Will try to isolate more as I get time.

I’ll keep trying to learn more about how antiX is put together, have a ton of things to figure out still. I’m trying to do it do do something a little non-traditional with it (basically, using encrypted live+toram to boot a KVM hypervisor that’s largely amnesiac/ephemeral, mostly loading the VM disk images out of ‘tomb’ archives hosted on non-bootable LUKS drives in the laptop). I’ll explain a little more in another post if anybody’s interested, it’s like Qubes gone horribly wrong.

-a4

• This topic was modified 3 years, 7 months ago by amidfour.

[Member melodie]

Alright, and what about the landing on the login screen in the live iso? Is there a way to avoid that and have the boot from ISO go straight to the desktop?

[Moderator BobC]

I would like to do a “Clean” install with the most current beta code on my 32 bit Pentium III and also on one of my newer 64 bit machines, and then will test.

I have noticed that if I install and then update and then do a dist-upgrade I get the newest code, but it doesn’t apply to my user id, but does apply to a new user created after that.

What would be the best way to get as clean an install as possible?

I was thinking to boot the USB, then do the updates, then

1. install, but not sure if I will have enough memory to do that in that sequence?

2. Or should do a snapshot and burn a new ISO?

3. Or clone a live partition?

I think I found my own answer, I booted to USB, did the update and dist-upgrade, and then did the remaster option from the live menu. Hopefully that will work right.

• This reply was modified 3 years, 7 months ago by BobC.

[Member melodie]

Hello,

I haven’t used the antiX control center, but directly the remaster isos tool, the one which allows remastering to distribute to other people. I have done several test versions and now I am able to have one ISO which boots in Virtualbox, and can be installed to a virtual drive.

However I get several issues: one is that the live does not get the name I gave it, when getting the first boot options screen, and the options show some environment variable gibberish text. Another one is it does not boot straight to the desktop, but presents a lightdm login screen (I prefer lightdm to slim). I will make again a new one as there have been updates available on the iso creating tools and template, and also I’ll add the virtualbox-guest-x11 and packages depending on it and see how it goes next time.

I do have one question : which kernel is advised to use atm? I’d like to use one that can power old lappies, such as a i486, is it compatible with respin creation or should I pick another one? Thanks!

Attachments:

1. 

   gscreenshot_2019-10-04-104147.png
   

[Anonymous]

(previously tested) inclusion of additional dropdowns causes the rightmost columns to become inaccessible for users with lesser resolution displays.

The F1 helptext strives to clarify the implications (“dimensions”) for each of the (e.g. persist_all) labels, because explanation of all the “dimensions” cannot reasonably conveyed via a table ~~ given the limited 80-char (62char?) fixed-width help window.

re: “a different set of option names which can be more clear”
Clarity has been sacrificed for the sake of brevity (character count).
The autosized layout width of each dropdown in the bootmenu is determined by the longest labelstring in its option set.

The persistence options could (conceivably, per /live/boot-dev/boot/isolinux/README), be moved//expanded and displayed to a separate “custom” gfxboot submenu… but that would incur a LOT of work (setup, and testing) and is subject to diminishing returns (those menus are only accessible to users who are booting Legacy BIOS).

With the status quo labels, IMO the most likely-to-confuse detail is the (seemingly TRINARY) nomenclature “root” vs “home” vs “all”.

re: “fill-in-the-blanks”

We can “reason about” each of the permutations, but because I haven’t tested each of the permutations (e.g. I have never found occasion to use persist_all), I cannot definitively fill in all the blanks.

Even when discussing only ONE of them, a thorough explanation would require several “asides” due to circular definitions.

persist_root .... Fast. Only saves root (uses RAM, saves at shutdown)

Root Persist
Save all the changes to the file-system in RAM and then
transfer these changes to disk right before you shutdown or reboot.
Fast, but space is limited by how much RAM you have.

Predictably, the user will probably wish to preserve (persist) the contents of hisHERtheir home directory. Does the user know/care whether or not that content shall be persisted within a separate (homefs) “container”? If so, meaning the user does know/care… does the user understand that write operations for changed homefs are (always, intrinsically) performed immediately, aka are “static”? Is the user aware of the possibility to additionally utilize Live-USB-Storage?

“root persist [..] transfers these changes to disk right before you shutdown or reboot”
This bit confusingly//inaccurately overlooks the manual/semi/auto “dimension” ~~ during semi-automatic mode, changes can be transferred repeatedly, on-demand, throughout the livesession. (as I mentioned above, clarity within the livehelp has been sacrificed for the sake of brevity.)

re: persist_root “Persist home on disk?”
Yes, changes to the content are preserved. No, a separate homefs container is not employed. If it were, write operations to it would be “static” and would obviate the the possibility of having the choice of manual/semi/auto.
-=-
It stands to reason the moniker “persist_all” exists to describe _that_ scenario ~~ one in which both a rootfs and a homefs are employed. We should (are required to) understand that homefs writes will be immediate and that homefs rootfs writes will be governed by choice of manual/semi/auto.

antiX Core Plus Just Enough X – a recipe

A step-by-step tutorial of my way of building an antiX system from a core-ISO install with just the programs I find “essential” — including the X Window System. I thought it would be good to compile a complete basic setup “recipe” in one post. (Note that many of these directions were gleaned from others on this forum.) If desired, one can use this as a guide to begin a similar project. My entire used hard disk space is 2.12 GB.

1. Preparation:
I chose an antiX 17.4.1 core-ISO installation (the latest core version as of this writing), because my target computer is a quite old 32-bit netbook, and I wanted to squeeze every little bit of performance out of it. After installing, I set up the WIFI through Ceni, then upgraded the software through apt-get upgrade. If you are playing with core, I assume you know how to do this. (If not, then please check out the fantastic antiX FAQs. 🙂 )

2. Installing the software:
The list, and the “why:”

xserver-xorg-legacy
# base x package for antiX

xserver-xorg-video-intel
# my netbook’s specific video server

xserver-xorg-video-vesa
# generic fall-back video server

xserver-xorg-input-all
# input for all mouse, keyboard, etc

conky-legacy-all
# I need conky to enjoy my system!

pmount
# mounts usb drives, etc by normal user

jwm
# minimalistic window manager

file-roller
# handles compressed archive files

rox-filer
# file manager & launcher panel

xinit
# starts X window system

lxterminal
# terminal for X

geany
# text editor

ufw
# firewall – set it & forget it

gexec gksu
# easy way to start apps as root

lxappearance
# change the desktop theme

firefox-esr
# my favorite web browser

qpdfview
# pdf reader for my books

dosbox pysolfc
# my bare-essential games

smtube mpv
# view you tube videos without ads

volumeicon-alsa-legacy
# tray icon to easily control sound volume

blackbird-gtk-theme
# the only theme I want, to make my system enjoyable

mirage
# simple image viewer, to chose icons & wallpaper

So run the following command (with a space separating each package):
sudo apt install xserver-xorg-legacy xserver-xorg-video-intel xserver-xorg-video-vesa xserver-xorg-input-all conky-legacy-all pmount jwm file-roller rox-filer xinit lxterminal geany ufw gexec gksu lxappearance firefox-esr qpdfview dosbox pysolfc smtube mpv blackbird-gtk-theme volumeicon-alsa-legacy mirage

This takes about 1 GB of space.

3. Editing the configuration (text) files, preparing the system:
For each of these first two files, start up the nano editor as root.

a. This gives your normal user privilages to run X:
sudo nano /etc/X11/Xwrapper.config
1. Add the following line at the bottom of the file:
needs_root_rights=yes
2. Save (Ctrl+O),then exit (Ctrl+X)

b. This logs you in automatically (without any desktop manager), so bootup to your X desktop is hassle-free, light & quick:
sudo nano /etc/inittab
1. find this line & comment it out (put a # in front of the line):
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2. add this line directly after it (substituting “demo” with your user name):
1:2345:respawn:/bin/login -f demo tty1 </dev/tty1 >/dev/tty1 2>&1
3. Save (Ctrl+O),then exit (Ctrl+X)

For each of these last two files, start up the nano editor as your regular user.

c. This starts X automatically
nano ~/.profile
1. at the bottom of file, add a new line with this command:
startx
2. Save (Ctrl+O),then exit (Ctrl+X)
(NOTE: doing this does not allow for loging into a different virtual terminal without running X if you use ctl+alt+Fx, unless you first comment-out this addition.)

d. Copy the window manager configuration file to your home directory for editing:
cp /etc/jwm/system.jwmrc ~/.jwmrc
Edit the ~/.jwmrc file:
nano ~/.jwmrc
NOTE: The .jwmrc file is kind of hard to follow, but hopefully this will serve the purpose if I mention the editing highlights:

1. Comment-out this line with the “arrows” <!-- & --> like this:

<!-- <Include>/etc/jwm/debian-menu</Include> -->

2. Fix the terminal launcher by changing xterm to lxterminal:
<Program icon="terminal.png" label="Terminal">lxterminal</Program>

3. I erased the other default launchers but added shutdown options after the logout command. I’ll use the
ROX panel to launch my apps:

			<Program label="Reboot">sudo reboot</Program>
			<Program label="Poweroff">sudo poweroff</Program>

4. Add startup commands – these start automatically with Jwm: the ROX panel to launch programs, conky
system monitor, and the volume icon to adjust sound volume:

		    <!-- StartupCommands -->
			<StartupCommand>rox --top=PANEL</StartupCommand>
			<StartupCommand>conky</StartupCommand>
			<StartupCommand>volumeicon</StartupCommand>

5. Backgrounds & desktops – different background for each desktop
example:

		<Desktops width="2" height="1">
			<Desktop><Background type="image">/home/demo/wallpaper/black.jpg</Background> 1</Desktop>
			<Desktop><Background type="image">/home/demo/wallpaper/blue.jpg</Background> 2</Desktop>
		</Desktops>

6. Save (Ctrl+O),then exit (Ctrl+X)
[You’ll have to add your wallpaper files later; you’ll have a plain black background until you do.]

4. Reboot the system (ctrl+alt+del) or type at the console: sudo reboot. This will bring up the system directly to your X Window Jwm desktop. Ready for tweaking.

5. Further steps – playing with your desktop environment:
1. Set up ROX panel — drag & drop files ending in .desktop from /usr/share/applications to the panel.

2. Set up geany to open text files by default — in rox, right click “Set Run Action…” & drag a “.txt” file to the window that opens – or type geany in at the beginning of the bottom text field.

3. Edit conky to display what you like to see on your desktop (use geany to edit ~/.conkyrc — remember that files starting with “.” are hidden).

4. Make “.desktop” files (for the ROX panel) for apps that don’t already have them — copy a file ending in .desktop from /usr/share/applications to ~/.local/share/applications – & edit it with geany to make launchers for them — that is, edit & save-as gexec.desktop, pmrp.desktop, etc.

5. To give certain folders their own distinctive icon, copy your choice of icon (& rename) to “.DirIcon” in a rox folder to change the display icon in ROX panel & rox-filer for that folder.

6. Mount removeable devices with pmount – mounts removable drives to /media – to add your documents, media files, wallpapers, etc.
Use terminal (or gexec.dektop from ROX panel) as your normal user:
a. pmount /dev/sdb1 #mounts drive to /media/sdb1
b. pumount /dev/sdb1 #unmounts drive from /media/sdb1 (& removes /media/sdb1 folder)

7. Execute lxappearance.desktop in /usr/share/applications to use that blackbird theme. 😉

Enjoy the adventure!

• This topic was modified 3 years, 7 months ago by christophe.
• This topic was modified 3 years, 7 months ago by christophe.
• This topic was modified 3 years, 7 months ago by christophe. Reason: added code notations

Attachments:

1. 

   2019-09-29-113831_1024x600_scrot.png
   

1. conky.txt
2. desktop.txt

confirmed antiX frugaler, since 2019

[Anonymous]

The Live behaves also in QEMU very stubbornly.
The keyboard layout and the language settings can only be set during installation, which does not affect the reboot immediately. It is a tinkering.

I think it is absolutely important to use the refractainstaller in text mode, otherwise it won’t work for “a foreigner”.

No comparison with antiX ! 😉

Installed the latest full iso on a ibm r51 laptop. 1.6 gig single core 32 bit cpu 1.2 gigs of ram. Works good. I have a couple of questions. The wicd icon does not show up in the task bar even though wireless is working. I can make it show up via the control center but when rebooting it fails to show. Also I have a “no pinboard” error upon booting to the desktop. The fault reads” No Pinboard was in use…The default pinboard has been selected. Use ‘rox -p=Default to turn it on in the future”. I have to close this dialog box every time after booting. I tried searching before posting but could not find anything.

Still figuring Antix Linux out.

Thanks Tony

[Member rej]

Just some corrected information regarding AntiX 19 B3 4.9.189 kernel:

I clean installed antiX 19 beta 3 [original boot ISO, with default kernel 4.9.189] on a Lenovo ThinkPad T450s [model-2015] and it booted to a blank screen – tried this many, many times making new ISO-USB boot drives. Same result.

Next, installed it on a Lenovo ThinkPad T420, where it runs as expected, only changed the kernel to 5.2.8, made snapshot and live USB, then installed back on Lenovo ThinkPad T450s and no longer blank – updated, everything seems to be running fine so far. The imported files are still executable (as with all the various laptops tried), but installed Thunar – it recognizes the files correctly.

I apologize for the confusing information (inxi -F output) previously posted with wrong kernel [4.19] in the system information output. There were so many attempts at this (different drivers, etc) that I erroneously posted the data from a system that was transferred from a fully installed B3 snapshot/USB installed on another laptop and then installed on the T450s. [This did not work very well – no way to connect to the internet.]

The 4.9.189 default kernel on the T450s booted to a blank screen and therefore could not provide the system info output…

The “Intel HD Graphics 5500” is where the problem is, I believe.

It would be likely impossible to make antiX configured for thousands of different devices, but hope this is somehow helpful information.

Again, sorry for the wrong system data on the previous post.

Installed MX19 B2.1 on the same T450s laptop. Installed the antiX 4.9.189 driver and booted to it. Tried to update it and the desktop started screen-tearing and froze within minutes – could only power off – nothing worked.

Rebooted and again, within minutes the desktop image turned to a black & white photo and froze – could only power off.

Rebooted and again, and quickly, opened “Tweak” in MX Tools and switched the driver to “Intel” – froze on the way out – could only power off.

Rebooted and all was running fine with the new driver.

——–
AntiX 19 B3 4.9.189 kernel and default grahics driver:

rj@antix19rj:~
$ inxi -F
System:
  Host: antix19rj Kernel: 5.2.8-antix.1-amd64-smp x86_64 bits: 64 
  Desktop: IceWM 1.6.1 
  Distro: antiX-19.b3_x64-full Marielle Franco 16 August 2019 
Machine:
  Type: Laptop System: LENOVO product: 20BWS06K00 v: ThinkPad T450s 
  serial: <root required> 
  Mobo: LENOVO model: 20BWS06K00 v: SDK0E50510 WIN serial: <root required> 
  UEFI [Legacy]: LENOVO v: JBET72WW (1.36 ) date: 02/23/2019 
Battery:
  ID-1: BAT0 charge: 19.4 Wh condition: 19.7/23.2 Wh (85%) 
  ID-2: BAT1 charge: 19.1 Wh condition: 19.6/23.2 Wh (84%) 
CPU:
  Topology: Dual Core model: Intel Core i7-5600U bits: 64 type: MT MCP 
  L2 cache: 4096 KiB 
  Speed: 799 MHz min/max: 500/3200 MHz Core speeds (MHz): 1: 798 2: 798 
  3: 799 4: 798 
Graphics:
  Device-1: Intel HD Graphics 5500 driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1600x900~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) 
  v: 4.5 Mesa 18.3.6 
Audio:
  Device-1: Intel Broadwell-U Audio driver: snd_hda_intel 
  Device-2: Intel Wildcat Point-LP High Definition Audio 
  driver: snd_hda_intel 
  Sound Server: ALSA v: k5.2.8-antix.1-amd64-smp 
Network:
  Device-1: Intel Ethernet I218-LM driver: e1000e 
  IF: eth0 state: down mac: 68:f7:28:b2:c0:38 
  Device-2: Intel Wireless 7265 driver: iwlwifi 
  IF: wlan0 state: up mac: 60:57:18:db:c7:0c 
Drives:
  Local Storage: total: 253.08 GiB used: 13.59 GiB (5.4%) 
  ID-1: /dev/sda vendor: Samsung model: MZ7TD256HAFV-000L7 size: 238.47 GiB 
  ID-2: /dev/sdb type: USB vendor: SanDisk model: Cruzer Glide 
  size: 14.61 GiB 
Partition:
  ID-1: / size: 21.53 GiB used: 5.47 GiB (25.4%) fs: ext4 dev: /dev/sda8 
Sensors:
  System Temperatures: cpu: 40.0 C mobo: 0.0 C 
  Fan Speeds (RPM): cpu: 0 
Info:
  Processes: 147 Uptime: 5h 31m Memory: 7.50 GiB used: 539.4 MiB (7.0%) 
  Shell: bash inxi: 3.0.33 
rj@antix19rj:~
$ 

MX 19 B2.1 with 4.9.189 Kernel and Intel graphics driver:

System:    Host: mx19rj Kernel: 4.9.189-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 8.3.0 
           Desktop: Xfce 4.14.1 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19beta-2.1_x64 patito feo September 8  2019 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Laptop System: LENOVO product: 20BWS06K00 v: ThinkPad T450s serial: <filter> 
           Chassis: type: 10 serial: <filter> 
           Mobo: LENOVO model: 20BWS06K00 v: SDK0E50510 WIN serial: <filter> 
           UEFI [Legacy]: LENOVO v: JBET72WW (1.36 ) date: 02/23/2019 
Battery:   ID-1: BAT0 charge: 19.4 Wh condition: 19.7/23.2 Wh (85%) volts: 12.3/11.1 
           model: SANYO 45N1773 type: Li-ion serial: <filter> status: Unknown 
           ID-2: BAT1 charge: 19.1 Wh condition: 19.6/23.2 Wh (84%) volts: 12.3/11.1 
           model: SANYO 45N1775 type: Li-ion serial: <filter> status: Unknown 
CPU:       Topology: Dual Core model: Intel Core i7-5600U bits: 64 type: MT MCP arch: Broadwell 
           family: 6 model-id: 3D (61) stepping: 4 microcode: 2D L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20752 
           Speed: 813 MHz min/max: 500/3200 MHz Core speeds (MHz): 1: 813 2: 939 3: 800 4: 811 
           Vulnerabilities: Type: l1tf 
           mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
           STIBP: conditional, RSB filling 
Graphics:  Device-1: Intel HD Graphics 5500 vendor: Lenovo driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:1616 
           Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1600x900~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) v: 4.5 Mesa 18.3.6 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel Broadwell-U Audio vendor: Lenovo driver: snd_hda_intel v: kernel 
           bus ID: 00:03.0 chip ID: 8086:160c 
           Device-2: Intel Wildcat Point-LP High Definition Audio vendor: Lenovo 
           driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:9ca0 
           Sound Server: ALSA v: k4.9.189-antix.1-amd64-smp 
Network:   Device-1: Intel Ethernet I218-LM vendor: Lenovo driver: e1000e v: 3.2.6-k port: 3080 
           bus ID: 00:19.0 chip ID: 8086:15a2 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter> 
           Device-2: Intel Wireless 7265 driver: iwlwifi v: kernel port: efa0 bus ID: 03:00.0 
           chip ID: 8086:095b 
           IF: wlan0 state: down mac: <filter> 
Drives:    Local Storage: total: 238.47 GiB used: 5.87 GiB (2.5%) 
           ID-1: /dev/sda vendor: Samsung model: MZ7TD256HAFV-000L7 size: 238.47 GiB block size: 
           physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 6L6Q scheme: MBR 
Partition: ID-1: / raw size: 22.51 GiB size: 22.04 GiB (97.87%) used: 5.87 GiB (26.6%) fs: ext4 
           dev: /dev/sda9 
Sensors:   System Temperatures: cpu: 38.0 C mobo: N/A 
           Fan Speeds (RPM): cpu: 0 
Repos:     Active apt repos in: /etc/apt/sources.list.d/antix.list 
           1: deb http://iso.mxrepo.com/antix/buster buster main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mxrepo.com/mx/repo/ buster main non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 296 Uptime: 26m Memory: 7.57 GiB used: 664.3 MiB (8.6%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: quick-system-in inxi: 3.0.33 

[Member Some1]

First of all, I found the culprit, the faul, the big issue and yes, it was me.

Someone has to say, Linux kernel it doesn’t bring support by default to laptops or any portable device (at least when it comes from debian build, its seen also on rpm based as far as I saw through net). So, learning about acpi made me feel less newbie. If u just installed linux in a laptop and it didn’t boot, give it a chance with this:

https://01.org/linux-acpi/documentation/debug-how-isolate-linux-acpi-issues

It consumes lot of time but once you manage to pull the correct acpi to boot with most of functions (fan, proccessor cores, wireless, bluetooth, graphics, etc.); the issues problem listed onto this topic can dissapear once you add the correct acpi command then be added to the kernel boot parameter.

I run a live system from antix 17 with no issue and installed works even better but laptops seems to work very different and need to be handled with care, with the acpi off on a laptop, its a matter of time till it faint.

Now someone can mark this thread as solved. I can’t boot with the slim manager with the graphic card activated, I’m wondering if I should reinstall all the OS or xserver again, if I put again the nomodeset on the boot parameter it loads the configuration already installed but the graphic driver is not detected. Gonna have to research again but this issue is solved. Thanks all of joinning and giving feedback that appoints me to picking up kernel parameters for boot.

This is a signature.