Search Results for 'boot from iso'

[Member Xecure]

@anticapitalista
I think I have most things ready and sent merge requests (don’t accept yet, I will try to build an ISO to see if everything works out of the box).

I have 4 things missing (and I need some advice):
1 – Add the exception to gazelle-installer add default_user and autologin_enabled when “autologin” is selected during installation (I am not sure what version you have under development, so didn’t create any merge request).
2 – Add slimski.local.conf to Build-iso (slimski will use /etc/slimski.local.conf first, and if missing use /etc/slimski.conf), so it is injected into the ISO, so that no package update can override the default configuration set by the user (no package brings it in).

3 – A question related to slim I tried to copy to slimski, but I don’t understand.
There is a file in /usr/share/slim/antiX/slim-install.conf. This file is edited by the live inits when a dpi is selected (it also edits /etc/slim.conf) in the live boot menus, but the installer never uses it. I thought this file was used by the gazelle installer (copy it and replace /etc/slim.conf), but I cannot find any part that uses it. I have created a slimski-install.local.conf to copy this structure, but don’t know where to look for the package/scripts that edit or uses this file (to adapt it for slimski use).

4 – A problem I don’t know how to solve (easily).
The packages desktop-defaults-icewm-antix, desktop-defaults-jwm-antix and desktop-defaults-fluxbox-antix will bring the .desktop configurations for session management (/usr/share/xsessions/), used for example by desktop-session-antix to generate the other desktop menus.
If I replace spacefm with zzzfm, anyone upgrading will no longer be able to login to space-<wm> sessions, but if I have them both there (files for spacefm and zzzfm), then creating an ISO with only zzzfm, the menus will also display the space-<wm> entries (which will not work and lead to confusion). Should I create an apt-hook to remove the corresponding .desktop files if the desktop-icon manager (file manager) is not installed and recreate them if they are detected when installed?
Let me know and I will create this hook (maybe a new one or add the check to the updated loginmanager hook).

Thanks and sorry for the inconveniences.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member LinuxFan84]

May I ask you something else:

As antiX is very into politics/having a polticial point i wonder that antiX does not aims more into encryption. Having a political opinion or a free speach is a very personal thing and in some countries even a dangerous one. Based on this fact, i would expect that antiX offers in every situation a suggestion “Its better to encrypt your files, do you want to [Y/N]”, no matter you install it, run it frugal ect or create a ISO from your current system. Maybe i missed something but i read all site and googled a lot about antiX.

I personally like the snapshot function antiX provides, a great tool, but it looks like you make an unencrypted iso of your current system (including all your data).
I coded something similar for myself based on Debian. I spent a week on it but unfortunately for any reason it was not able to boot. The process was: partition usb/create luks, mount it, rsync all files to usb structure, chroot it to edit fstab, crypttab, update lvm and run update-grub/update-initramfs …

——

Regarding systemd-free:
I also searched regarding this but did not find the reason why antiX has chosen for being free of systemd. Is it a political decision (freedom of choice) or is it only for being lightweight, as ex. for older systems?

I found it again, the info by anticapitalista about the approach and difference to Devuan: “antiX takes a more ‘militant’ stand against systemd. We ship without systemd, libsystemd0 (I was sad to see that the latest Devuan ships with libsystemd0) and use eudev rather than the systemd infected udev. We also have our own nosystemd packages such as cups, dbus, tor etc.”

I ask myself why here: https://sysdfree.wordpress.com/2021/04/26/333/, antiX is not listed unter “healthy hardcore distros” and why other stuff like elogind got damned (by this site) and many more and if and why antiX keeps it? Also regarding this i googled a lot but didnt found the answer or got the point.

Thank you guys.

[Member Xecure]

I will explain things so you understand what your are doing, and not only trying bootcodes.

For a graphic card to work it needs 2 things:
1. The kernel module related to that graphic device (kernel driver).
2. The Xorg module to render graphics to the Xorg/X11 graphic server (xorg video driver).

When running inxi -G, you are asking inxi to display all information it can find related to the graphic devices (hardware), the related kernel module that were loaded (and are being use) for this hardware to communicate with the kernel, and the module(s) xorg is using to draw to your screen.
For your example in OpenSUSE:

Graphics:
  Device-1: Matrox Systems MGA G200EV vendor: IBM driver: mgag200 v: kernel 
  bus ID: 07:00.0 chip ID: 102b:0530 
  Device-2: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] 
  vendor: PC Partner Limited driver: radeon v: kernel bus ID: 15:00.0 
  chip ID: 1002:6779 
  Display: x11 server: X.org 1.20.3 compositor: kwin_x11 
  driver: ati,modesetting,radeon FAILED: mga unloaded: fbdev,vesa 
  resolution: <xdpyinfo missing> 
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.2.4 compat-v: 3.1 
  direct render: Yes 

This is the desired result you want to emulate in antiX, but for some reason it cannot do this automatically. The reason for the problem detecting and configuring the correct drivers out of the box can be many things (different kernel version: opensuse uses 5.13, antiX uses 4.9; different detection on the live USB, etc.).

From the above output, the device 2 is the one that is being used to output video:

Device-2: AMD Caicos [Radeon HD 6450/7450/8450)[…] driver: radeon

You can see that the kernel driver used for this device is called radeon. You can see if it is loaded in any linux system with
lsmod | grep radeon
If there is NO output, it is not loaded. You will need to load it with
sudo modprobe radeon

The next part is the module used for Xorg server:

Display: x11 server: X.org 1.20.3 […] driver: ati,modesetting,radeon

You can see that there are 3 xorg video modules loaded: ati, modesetting and radeon
modesetting refers to the ability of the kernel to manage the display resolution and other video related properties. It works much better in newer kernels and also on newer hardware. For some devices, it is recommended to disable it at boot. You can do this using the boot parameter nomodeset, to instead use the xorg modules and not let the kernel try to intervene too much.
nomodeset
You can also force the kernel mode setting to load the correct radeon xorg video driver with the boot parameter
radeon.modeset=1
but probably the thing that is failing in your case is the kernel modesetting feature, so this will probably not work, and it is better to use both nomodeset and disable radeon modesetting
nomodeset radeon.modeset=0

Normally, the radeon module will also load the ati driver, so lets concentrate on the radeon driver.
If you see that the xorg radeon driver isn’t being used by xorg after booting to antiX, you can force it to use it in one of two ways:
A. Using a boot parameter (only works on antiX live system, and before booting):
xorg=radeon
B. Disable X server, (if it is running, meaning you have a graphical interface), create a xorg.conf file specifying that the radeon xorg module must be enabled when starting X server, and then start the xserver again. You can do this from terminal
sudo make-xorg-conf -f radeon -o /etc/X11/xorg.conf
stop slim and xorg server
sudo service slim stop
start it again with
sudo service slim start
or
sudo startx slim

You could try combining both methodes, of disabling the kernel modesetting and also forcing xorg to load the radeon driver
nomodeset xorg=radeon

As you see, there are too many possibilities that may have caused the failure.

If nothing above worked, it is very possible that the older 4.9 linux kernel in the antiX 19.4 ISO doesn’t support so well the video card as the newer 5.X linux kernels. If this was the case, you would need to:
A. Use a different antiX edition, for example with kernel version 4.19, or a community release with kernel 5.10, or the newer antiX-21-beta1, which lets you select in the boot menus the kernel 5.10.
B. (last resort) Install in fail-safe mode, update the kernel to a newer one and then remove the /etc/X11/xorg.conf to let it sart detect on the next boot the correct driver.

The information is here. I hope this can help you understand how to read the inxi output for the graphics cards, and also how to find one of the multiple paths (or try them all) that might help you boot to a working antiX system.

Let me know if there is something I didn’t explain properly, or need clarification.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

BUG for desktop session “minimal-<wm>”
Ignore the previously mentioned bug report. min-<wm> is the correct exec command.

Ampersand wrote:

Rufus in Windows. Also please see point 1

I may have time later today to test if creating the live USB with Rufus gives some kind of conflict with the new boot options. I have booted the bullseye b1 ISO on all my machines without problems (even in a small mini-pc), but I never tested creating the ISO with Rufus, so I will check.

• This reply was modified 1 year, 10 months ago by Xecure.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Ampersand]

1. yes. But the final testimony is the unblinking underscore. efi shell only when usb lowered in boot order.
2. Rufus in Windows. Also please see point 1
3. no, for there is no such option in efi. Also please see point 2<
4. no, as above. Also please see point 2

[Member Xecure]

The translation resource from antix/MX linux developers is here: https://www.transifex.com/anticapitalista/antix-development/live-grubpot/ (not antix-contrib, but official antiX)

This may be a though one, as these are the new live grub menus, but they should be very familiar for anyone that has checked the original isolinux/syslinux boot menus. If there are any questions, please ask away. I will try to link to the script files for context if needed.

Thanks to anticapitalista, fehlix and all others involved in the transformation of the live grub menus.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Ampersand]

ModdIt wrote:

Hi Ampersand,
did you use boot menu (often F12, keep pressing switch on computer) or set in BIOS to boot from USB before other devices.

Hi Moddit,
Actually there is a jolly welcome to grub message for a few seconds before the unblinking underscore appears. This happens when the usb pendrive with the mentioned iso is in the socket and UEFI boot options start from `Linpus Linux’ in the top choice.

[Member Ampersand]

Xecure wrote:

Can you see if the USB device boots on other machines (if you have any other one available)? Or, do you know if other versions of antiX Live USB boot properly on the machine in the same conditions?

Twice yes:

1. Same image on another PC
2. 19.3 on the same (mini) PC

[Member seaken64]

This sounds like a UEFI/BIOS setting. Can you detail for us the exact steps you took to get to this “Welcome to Grub!” display?

The Live USB does not usually use Grub to boot, but Isolinux or Syslinux. After the opening Isolinux menu you select from one of the choices. Which choice did you select?

If you cannot get a Legacy boot then you need an UEFI boot. There are UEFI boot utilities that can help if you can’t get it figured out from the UEFI/BIOS settings.

There are some folks here a lot smarter about UEFI booting than me. But start by giving us a play-by-play description of exactly what steps you are taking.

Seaken64

[Member Xecure]

You just need a newer kernel than the default 4.9 for support for the CPU Intel Core i5-8259U.
You could either try with the release with kernel 4.19, or check out the antiX21 beta (selecting a modern kernel in the boot menus), if you don’t mind giving us a bit of feedback on how it performs on newer hardware (optional).

The new advances in live-boot options for future releases will give the chance of selecting different kernels, between one compatible with old hardware and one with improved support for newer hardware.

You also have the option of booting the core release for 19.4 live-USB on Virtualbox on Windows/Mac (whatever you use), install there a newer 5.10 kernel from the package installer, remaster and change the live kernel. Then it should have no problem at all on your hardware, and you can follow the steps by dolphin_oracle to install KDE as the main desktop environment.

There are different options available to achieve the same thing. That is the great advantage (and curse) of Linux.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member ModdIt]

Bit of a chicken egg comparison, stable distro compared with experimental alpha and beta releases which are expected to show some deficits.

The antiX beta has been my daily driver since its release, boots very quickly and has been stable the entire time.

I use the full antiX versions of antiX, remove or add some applications to keep users happy.

Not had a real let down with antiX since starting to use it, about two years or more with a lot of installations in intensive daily use.

Many many sincere thanks to anticapitalista for the work he does, same goes for all others in the team and who are on the forum.

I hope that runit version will further evolve to a stable release, the last odd error messages dissapear. In my case none are critical.

I do not use LXDE desktop, icewm is very much my favorite.

And will stick with antiX as distro of choice.

my memory usage is a different subject, it is somewhat higher than normal as i have more services running that as delivered and a dressed up icewm.

• This reply was modified 1 year, 10 months ago by ModdIt.

[Member Xecure]

mckaygerhard wrote:

you said that uses the sis MODULE from jessie

Yes. Though it really is a module (module sisimedia), xorg calls it “display driver” (that is why I called it driver).
It was packaged in antiX 15-16 and can be found in the antiX repos.

mckaygerhard wrote:

so you said that the ABI is working ?

I don’t know what ABI means, so I cannot say.

mckaygerhard wrote:

the only change is the kernel and the sis module?

Yes (more or less). I am not a real maintainer, and am only building it by what others tell me.
I have also included the updates for all packages (be it Debian or antiX), and included a similar list of applications included in antiX 19.4 full. And I have also built a 64 bits ISO.
I forgot to include the xserver-xorg-video-geode package to the i386 ISO to support the geode graphic chips that you mentioned before, mckaygerhard. Sorry. I had it written down but forgot when preparing the final ISO. I have included it in the instructions for the next release. If possible, could you recommend other xorg drivers that I could include in future releases? I don’t really have any machine to test, and I was only building the ISO based on marcelocripe and a few others’ input.

I was asked by marcelocripe to upload a new ISO for x64 so I also re-did the i386 ISO without adding anything else. Again, sorry.

MANUALLY SELECT THE XORG DRIVER
There are two ways to select the xorg driver if it doesn’t select itself automatically:

1) At boot, using the boot parameter xorg=.
Example:
xorg=sisimedia
for SIS graphic chipsets

xorg=openchrome
for VIA graphic chipsets.
Alternatively, for loading generic drivers, you can also use:
xorg=safe

Sometimes, an initdr module needed for the kernel to detect some hardware is not automatically loaded. If you know the corresponding module name, use the boot parameter:
load=<list>
If you don’t know the specific module needed, you could try loading ALL initdr modules (not the best recommendation, but useful for troubleshooting):
load=all
Normally you don’t need to worry about this.

2) In a persistence live device or in an installed system, manually create a xorg.conf file with the correct configuration.
2A) Create a generic xorg.conf file using the command
sudo make-xorg-conf <module> -o /etc/X11/xorg.conf
where <module> is the name of the xorg video driver. Example for openchrome (VIA driver):
sudo make-xorg-conf openchrome -o /etc/X11/xorg.conf

2B) Or create it manually (the file /etc/X11/xorg.conf) based on one you found on the internet or one that already worked for the testing machine (on a different distro or same distro but different version). Example for sisimedia:

#----------------------------------------------------------------------
# xorg.conf file
#
# Generated by make-xorg-conf sometime around Thu Mar 26 08:53:16 GMT 2015
#
# If you want to save customizations, delete the line above or this
# file will get automatically deleted on the next live boot.
#----------------------------------------------------------------------

Section"Monitor"
    Identifier"Monitor0"
    Option"DPMS""true"
EndSection

Section"Device"
    Identifier"Device0"
    Driver    "sisimedia"
EndSection

Section"Screen"
    Identifier"Screen0"
    Monitor"Monitor0"
    Device "Device0"
    SubSection"Display"
        Modes "1280x1024""1333x768""1024x768""800x600"
    EndSubSection
EndSection

Taken from a post by SamK.

Or a more recent one by linuxdaddy (in this thread) for vesa generic video driver:

#-----------------------------------------------------------------------------
# xorg.conf file
#
# A vesa xorg.conf file for old video cards to get full resolution
#-----------------------------------------------------------------------------
Section "Monitor"
    Identifier "Monitor0"
    Option "DPMS" "true"
EndSection

Section "Device"
    Identifier "Device0"
    Driver     "vesa"
EndSection

Section "Screen"
    Identifier  "Screen0"
    DefaultDepth   24
    Monitor     "Monitor0"
    Device      "Device0"
EndSection

Section "DRI"
	Mode 0666
EndSection

Section "Extensions"
	Option		"Composite"	"Enable"
EndSection

If on live-USB, save persistence changes.
Reboot to see if the xorg driver loads properly. If it doesn’t, remove the xorg.conf file from terminal if needed and reboot.
sudo rm /etc/X11/xorg.conf

As stated previously (close to beginning of this topic), the legacy ISOs are built using the build-iso technology created by the antiX team. I used the most recent version for antiX-19 available in gitlab, added the necessary changes (iso folder and initrd folder), added some extra files to Template/COMMON/ (mainly the debian-jessie.list source list and the slim.conf file for auto-login, and some other small things), edited the package.list files in various of the Template folders, including one to add and remove packages for jessie repos, and added minor changes in the build-iso code. I tried to keep things as close as the original build-iso configuration, so that it can still be a used as a tool to build general antiX based ISOs and not only the legacy ISO.

For anyone interested in building their own system, I am uploading to gitlab the entire build-iso folder with all necessary things for directly building a working bootable ISO without having to do much at all. It is already configured for the pseudo-antix-legacy ISO build, so you can see what I have done and change whatever you think needs changing (for example, remove or add packages you are interested in).
You will need a good internet connection and at least 8 GBs of free space.

The distro information can be found in Input/defaults-local, where the project name, kernel, live username, local mirror (for downloading the packages to create the ISO), etc. can be configured.
The build-iso script is the one that needs to be run to produce the ISO. Here you can see the small changes I have included in the script to install and hold the xorg jessie packages.
Files in Template are the ones used to configure packages to be installed, in COMMON you can see files to be added or changed, sources, etc. The jessie sources can be found in Template/COMMON/squashfs/etc/apt/sources.list.d/debian-jessie.list
Packages to be installed from jessie repos can be found in Template/base-AND-full/jessie.list (if building for 64 bits, replace contents with jessie.list.64, as the geode package is not available for x64 architecture and will make the build iso to fail).

I understand, @mckaygerhard, that you are already busy maintains a venenux, so any advise, as small as it may be, will help a lot. I want to keep the antiX desktop (though some apps may be going away if not needed/don’t work on older machines), and was aiming at improving hardware detection and support for older devices.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

I really cannot get the same quality as the antiX 19.4 release, so I consider it a disservice to release a version with the pt_BR live menus (only on legacy boot) changed (not fixed, as it is in general worse than the official release). It would reflect very badly on the antiX project.

I have tested a few ISOs created with build-iso and they are all missing things. I tried extracting the original 19.4 ISO and take the boot menus from there but they don’t work well on the new builds. If I use the iso-template files for initdr and boot menus iy would be almost the same as an antiX 19.3 release with some updates (and still missing things)

Instead of releasing a fake it is better to recommend to use the official 19.4 release, selecting the pt language in the legacy boot menus and then switch locale to pt_BR during installation.

Sorry for wasting everyone’s time. Better to recommend the easy way. I was just obsessing to much on trying to create it myself, when the solution was so simple.

Note: The next antiX 21 release will use different translations, as all the menus have changed (in both grub and isolinux/syslinux menus). So those new files in transifex (if already there or when they arrive) will be the ones used.

Regards.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

I have built a new legacy ISO, based on antiX 19.4 FULL packages, for both 32 and 64 bits.

Changes:
* kernel 4.4.0-264 (thanks to anticapitalista’s efforts).
* Fixed the “invalid EXPRESSIG” error by updating the antiX signatures package.
* Aprox 1.3 GBs ISO. Now it is MUCH bigger to include almost the exact same packages as antiX 19.4 Full (includes seamonkey, libreoffice, etc.).
* Renamed the project to “pseudo-antiX” to not dirty the antiX name, as this is a very inferior product compared to the current antiX 19.4 release.
* This release DOES NOT include the improved live system changes (as it is based on the antiX 19 iso-template-antix_19.18 initdr and boot)
* Included a sis xorg driver that comes from the antiX 15-16 (jessie) repos. Hopefully this will make it possible to use real SIS xorg driver, and better results than vesa.
* Up to date packages.

i386 ISO: pseudo-antix-19 legacy bet3 (32 bits) (md5sum)
amd64 ISO: pseudo-antix-19 legacy bet3 (64 bits) (md5sum)

• This reply was modified 1 year, 10 months ago by Xecure. Reason: fixed links

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member marcelocripe]

Imsoenthused,

I thank you for posting the result of the $ inxi -Fnz command with the ISO “antiX-19-legacy-bet2_386-base.iso” on your computer, this data can be very useful for other people. I imagine that you have booted with the normal video mode, if you try to boot the ISO “antiX-19-legacy-bet2_386-base.iso” in Safe Video Mode, you can check with the command $ inxi -Fnz whether the vesa video driver has been loaded or not. For some motherboards I installed with this ISO, it only worked perfectly when I performed the installation process in Safe Video Mode. Normal video mode is the first option in the ISO boot menu (booloader).

marcelocripe
(Original text in Brazilian Portuguese)

Translated with http://www.DeepL.com/Translator (free version)

———-

Imsoenthused,

Eu agradeço por postar o resultado do comando $ inxi -Fnz com a ISO “antiX-19-legacy-bet2_386-base.iso” no seu computador, estes dados podem ser muito úteis para outras pessoas. Eu imagino que você tenha iniciado com o modo de vídeo normal, se você tentar iniciar a ISO “antiX-19-legacy-bet2_386-base.iso” no Modo de Vídeo Seguro, você poderá verificar com o comando $ inxi -Fnz se o controlador de vídeo vesa foi carregado ou não. Para algumas placas-mães que instalei com esta ISO, somente funcionou perfeitamente quando eu realizei o processo de instalação no Modo de Vídeo Seguro. O modo de vídeo normal é primeira opção do menu de inicialização da ISO (booloader).

marcelocripe
(Texto original em Português do Brasil)