antiX-14R-alpha1-full-386 available - Page 7

SamK · posted: 2014-05-22 17:42

dolphin_oracle wrote:anyone having success getting ceni to work.

Booted Live, tried wireless via Ceni on two systems and obtained mixed results. Worked on one failed on the other. Am making this post on the one that worked (well I couldn't really do from the other could I).

dolphin_oracle · posted: 2014-05-22 18:02

what is weird is that wicd work when ceni didn't. I can't think of another time of that happening. both broadcom and intel chipsets. Do you recall what chipset was in the one that worked?

BitJam · posted: 2014-05-22 18:46

thriftee wrote:I did check the md5 of the iso and it checks out ok, so therefore the files contained should be ok, too, I would think.

Ideally you would check the media on the target system. Mount the LiveCD/DVD and perform the check I suggested.

With the Dell, I was trying to boot from a USB via Plop booting from a 3.5" floppy so that may have been part of the problem.

You can boot our LiveUSB from our LiveCD by using the"from=usb" boot parameter when you boot the LiveUSB. AFAIK, booting via plop forces the usb into usb-1.1 mode which is very slow. Again, checking the iso is not the same thing as checking the LiveUSB.

I tried booting the same USB directly from a newer HP DV9000 laptop, and it also gets the acerhk error message for a moment, but gets farther along in the boot process than the Dell.

Many, perhaps most or all systems get that message. It is benign and due to a kernel configuration parameter that enabled a debugging mode. You may get more information if you remove the"quiet" boot parameter and add"noclear".

thriftee · posted: 2014-05-22 21:32

bitjam, i checked the checksums for the 3 files and they all came out correct. On the Dell I am only using the Plop floppy boot via USB to load because the CD-ROM drive on the machine doesn't work. One of the nice things about antiX is that its quick enough that even loading a system from USB is quite fast, like 15 min, compared for example to 2 hrs for Debian. I ran it again, without quiet and with noclear.

some of the text scrolled off, but no errors were noticed... text from:

Code: Select all

acerhk: notebook not recognized, refusing to load module.
TCP:: vegas registered
TCP: yeah registered
Key type dns_resolver registered
Using IPI No-Shortcut mode
registered taskstats version 1
hd: no drives specified - use hd,cyl,head,sectors on kernel command line
rtc_cmos 00:06: setting system clock to 2014-05-22 21:23:12 UTC (1400793792)

Hmmm, I wonder why is it expecting me to type in hard drive parameters? And what I would give it?

BitJam · posted: 2014-05-22 22:03

Thanks for checking the md5s. Those messages all look fine. The hd: message is standard.

I don't know what is wrong. The next thing that happens in my dmesg output after the lines you posted is discovery of usb devices and hard drives. If those lines you posted are the last lines displayed then maybe the kernel is stalling when it tries to discover your floppy drive. I don't know what to do about this but that is my guess now for what is triggering the problem.

BitJam · posted: 2014-05-22 22:08

Try the"no acpi" option in the"F4 Options" menu.

thriftee · posted: 2014-05-22 22:24

I tried the"no acpi", but got a kernel panic, so maybe better to not try to test it with the old Dell, unless and until you want me to. I don't want to divert you from problems that would affect many. I need to read up on the persistence stuff. That's new to me.

Thanks much for trying, and thanks for your efforts in general __{{emoticon}}__

skidoo · posted: 2014-05-23 07:19

skidoo wrote:Trying to understand what, and how to fix, problem of monitor not being correctly detected... I created a new pendrive and started afresh.
Monitor is 23" AOC flat panel LED with a native 1920x1080 display resolution. It is attached via HDMI.

First boot,"default" option of F6 boot menu... results in a blank screen
"vesa" F6 option result: max available resolution is 1280x1024
"safe" F6 option result: max available resolution is 1280x1024

Lotta stabs in the dark later... here's the lowdown:

-- this bug was introduced in the initial version of this alpha

-- same as ever (in my use) nouveau driver is automatically selected for this graphic card

-- problem not resolved by swapping in my 1280x1024 panel (which works fine with antix 13.2 and all other distros I've tried across the years)

-- placing xres=whatXever boot line argument (as suggested in F1 helptext) does not resolve the problem

-------------------------------

solution is to (select ANY boot line and) place a vga= boot line arg, and set F7"save"
(moreover, ANY value will suffice here 791, 795, etc)

Until the above is performed, I'm doomed to"black screen, right after seeing a line mentioning udev" (upon launch of startx, I guess)

After the above has been performed, during future reboots any/every boot menu line is usable
(without subsequent use of F7=save, and without ever again needing to add the vga= arg)

Confusingly (to me, at least) once saved, the vga= isn't displayed to"any/every boot menu line"...
...which led to an end result of forgetting what the heck I had previously done to achieve the fix.

SamK · posted: 2014-05-23 07:37

dolphin_oracle wrote:Do you recall what chipset was in the one that worked?

Before configuration by Ceni

Code: Select all

inxi -n
Network:   Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
           IF: eth1 state: down mac: 00:14:22:89:f8:ce
           Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200
           IF: eth0 state: unknown mac: 00:13:ce:b9:90:bb

During configuration by Ceni
Immediately following a cold boot-up from Live CD, Ceni seems to consider the interface already configured

Ceni screen

After configuration by Ceni

Code: Select all

inxi -n
Network:   Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
           IF: eth1 state: down mac: 00:14:22:89:f8:ce
           Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200
           IF: eth0 state: up mac: 00:13:ce:b9:90:bb

Connection to the network is successful and an IP address is obtained from a remote DHCP server.

Related Post
post34926.html?#p34926

SamK · posted: 2014-05-23 08:15

BitJam wrote:AFAIK, booting via plop forces the usb into usb-1.1 mode which is very slow. Again, checking the iso is not the same thing as checking the LiveUSB.

According to the following abstract from the Plop documentation it is an optional feature that can be invoked to force the use of v1.1 mode instead of v2.0. If the use of the older standard option is desired it can be selected from the Plop boot menu.

Plop Documnentation wrote: Force USB 1.1

Use USB 1.1 controller even if there is a USB 2.0 controller.

Mode 1: Ignore the EHCI Controller
Mode 2: Setup EHCI Controller and set all ports to the companion host. Some controllers need this option to force usb 1.1.

I have regularly used Plop for many years (and still do) and find it to be reliable and predictable across a wide range of hardware.

skidoo · posted: 2014-05-29 18:22

BitJam wrote:
6. boot menu options on liveUSB - I do not get a menu for setting the console resolution. My F7 menu is the save menu.
Yes. We are not sure what the best thing to do is. Here are some manual options you can play with:
Code: Select all
rm /live-boot/boot/syslinux/gfxsave.on
This will remove the Save menu and put the console menu back at F7.
Code: Select all
echo 1 > /live/boot-dev/boot/syslinux/f6save.on
This will move the Save menu over to F6, replacing the Desktop menu and put the Console menu back at F7.

Suggests are welcome.

Currently, the boot screen is fitted to 800x600?
Syslinux and gfxboot would handle 1024x768, yes?
Syslinux would handle additional (F7,F8) option submenus?
If so, does the status quo simply reflect attention to supporting"older gear"?

For a"desktop" linux distro, given the browser-centric nature of desktop computing nowadays...
seems to me that targeting/requiring a minimum display resolution of 1024x768 would be reasonable.
If 1024x768 is used for boot menu screen, would that relieve the need to"move XYZ over to F6"?

dolphin_oracle · posted: 2014-05-29 18:25

The 800 x 600 would work better on netbooks.

SamK · posted: 2014-05-30 05:24

skidoo wrote:...seems to me that targeting/requiring a minimum display resolution of 1024x768 would be reasonable.

800x600 is a good choice for users with impaired vision. Additionally, I have come across old kit on which 800x600 is the maximum that can be used.

skidoo · posted: 2014-06-02 00:02

Thanks, those are good examples in favor of keeping 800x600 boot menu.
An alternative way to free up screen space would be to move some options to a submenu, reached via a link labeled"more options".

BitJam · posted: 2014-06-02 01:08

The bootloader is written in a odd lisp-like language that AFAIK does not have a name. I don't know how to add more menus to it that don't show up on the panel. Even doing very simple things with it can be quite an adventure. I am trying to see if I can make the choice of desktop persistent on LiveUSBs even if no persistence is enabled. If this works then the"Save" menu can replace the"Desktop" menu on the LiveUSB with almost no loss of functionality. Whatever desktop was used last will be used when you boot again.

This actually provides a work-around for the gfxsave bug you found. In fact, try this (as root):

Code: Select all

echo 1 > /live/boot-dev/boot/syslinux/f6save.on

This file should take precedence over the standard gfxsave.on file and cause the"Save" menu to show up on the F6 key. My tests show that this solves the gfxsave bug. I've finally been able to replicate it and I think I can fix it but I hope to be able to use this work-around for now. With any luck, the code for the LiveUSB persistent desktop should show up in the next alpha release. The choice of desktop (via the F6 menu) should be persistent now on LiveUSBs that have either root or home persistence enabled.