I've noticed that making an antix-14 stick with antix2usb in antix 13 results in a boot menu without the persistence menu entries. The save F7 menu is also different (lacking the"both" and"custom" entries). This is not an issue with sticks made with unetbootin or universal-usb-installer. Persistence cheat codes work fine, although I haven't tried to see if the rootfs auto-create works that way or not.

gjots2
With every launch, it spews an"error" dialog stating"install pythongtksourceview to enable undo/redo)".

? Will user figure out that the name of the missing package is actually python-gtkresource2 (with a dash)

Reported package size is only 892Kb (and most of that is doc files). To avoid user frustration, it should be preinstalled, eh.

I don't know if it is just me, and my crappy eeepc, but in wmii, I can not get any keybindings to work?

I will try some stuff later.

dolphin_oracle wrote:I've noticed that making an antix-14 stick with antix2usb in antix 13 results in a boot menu without the persistence menu entries.

This is a known issue due to the peculiar way the older versions of antix2usb creates the menu for the LiveUSB. We wanted to get rid of the persistence entries from the LiveCD to reduce complaints about them not working OOTB. The two options we have now are:

1. The bug you encountered
2. Leave the persistence entries in the LiveCD menu

Opinions?

A third option is beginning to emerge but will probably not be ready for antiX-14. If someone boots with persistence enabled on a LiveCD and there is no partition labeled"antiX-Persist" then we could present a list of partitions and ask them to select one. Then we can create persistence files on that partition and offer to label it"antiX-Persist". This would allow the persistence options to work OOTB on the LiveCD.

The save F7 menu is also different (lacking the"both" and"custom" entries). This is not an issue with sticks made with unetbootin or universal-usb-installer.

This is a change I made. I thought the"menus" and"custom" entries were superfluous so I trimmed the menu down to"save" and"reset". Where"save" does what"both" used to. Does anybody ever want to use the"custom" or"menus" entries? (not a rhetorical question). The first problem (lack of persistence main menu entries) should only happen with antix2usb but this change should happen with all antiX-14 LiveUSBs.

I don't mind the simplified save menu. I always used"both" anyway.

the problem with antix2usb is that it lets you create the persistence files in-app, but then the menus entries don't appear. If the choice was either leaving the bug or leaving persistence options on the liveCD, I would go with leaving on the liveCD, but labeled as liveUSB only, at least until secret option 3 comes of age.

either that, or don't package antix2usb (unless there is a newer version coming up) with antix and use unetbootin or something like that instead. Personally, I find antix2usb quite convienent when making liveUSB sticks.

side note: I happened to make some persistence files the other day on a system other than my usual machine. The persistence files were created in no time at all, I mean really fast. Its still slow on my main laptop, so obviously mileage varies greatly from machine to machine on persistence file creation speed. I wonder if laptop vs. desktop drives are a factor... Anyway, I wanted to mention it since I've commented on the slow speed of persist file creation in the past. I finally know the wonder of the fast persist file creation and I see why you didn't think it was a big deal.

dolphin_oracle wrote:either that, or don't package antix2usb (unless there is a newer version coming up) with antix and use unetbootin or something like that instead.

The version of antix2usb in antiX-14 works fine. The problem only occurs when you use an earlier version of antix2usb with the antiX-14 iso.

side note: I happened to make some persistence files the other day on a system other than my usual machine. The persistence files were created in no time at all, I mean really fast. [...] I finally know the wonder of the fast persist file creation and I see why you didn't think it was a big deal.

Thanks. I have progress indicators now in both live-init and persist-makefs. On my system even 1 GB ext3 files get made in less than a second.

dolphin_oracle wrote:I happened to make some persistence files the other day on a system other than my usual machine. The persistence files were created in no time at all, I mean really fast. Its still slow on my main laptop, so obviously mileage varies greatly from machine to machine on persistence file creation speed. I wonder if laptop vs. desktop drives are a factor... Anyway, I wanted to mention it since I've commented on the slow speed of persist file creation in the past. I finally know the wonder of the fast persist file creation and I see why you didn't think it was a big deal.

I thought it was just me.

In the past I too have mentioned the long time it takes. It is one of the reasons I tend to use antiX on a USB stick very little (generally when there is no other practical alternative). I can recall it happening on various desktop and laptops (all USB2) and using sticks of different sizes from a variety of different manufacturers.

The above is not intended to disparage antiX on USB as things may have changed since I last ran it on a stick, probably something in the region of 6-8 months ago.

anitX-14R kernel gose into panic, and fail to boot this computer.
This is what it reads.
Kernel panic-notsyncing;Attempted to kill init! Exitcode=0x0000000b 13-2 boots without any issues.

Yeah Eino. I Pm'd Anti the kernel config files for what is working on my IBM Laptop.

I tried the current 14R-alpha1_386 in my Dell Inspiron 8100 laptop with the built in nvidia Geforce2 Go 1600x1200 video and screen, and taking the defaults on boot I get:

....
Booting the kernel.
acerhk: notebook not recognized, refusing to load module.

it hangs at that point and doesn't respond to keyboard or mouse... Is there a boot line code I can use to tell it not to try to load it?

AFAIK there is no way for you to prevent that message. It can only be prevent be changing the kernel config. But I think the message is benign and not related to your booting problem.

I suggest you trying using"F7 Console" -->"plain" and see if that helps you boot. You may want to also use"F5 Video mode" -->"safe" just in case the nouveau driver takes control and tries to bump your console resolution to the maximum possible (unless you have very good eyesight).

BTW: I used an i8200 for many years with Geforce2 Go 1600x1200 video and screen. I upgraded to a faster hard drive and it died of oveheating soon after.

Thanks for trying. I read the last 6 pages here and can see you've put lots of effort into this. antiX is setup closest to what I like, and that's why I'm trying it. I did try F7-plain and F5-safe and same result. I have a Zalman cooler under it since I lost a HD due to heat, I think, a few months ago, and its been running well, since then.

Something I've noticed is that the nouveau driver seems to work fine in 1600x1200 on this Dell laptop with no effort on some more recent versions of some distros, but on many others (especially xorg < 1.14) I have to install proprietary nvidia stuff to get it to work, or get it to work well. The common denominators thus far have been xorg 1.14.4 and linux 3.10.11 (like parted magic 2013_11_11) have worked, but older don't seem to. At the moment, I've freed up some disk and am loading Debian Jessie to see if it figures out the video correctly without any trouble. Even its LXDE version is too heavy to be running on the old laptop, but its a good hardware compatibility test. I really want to be running the default nouveau video driver if possible. The Jessie install finally finished and it does come up fine in 1600x1200 without doing anything, but its eating 143 mb of memory, so no way I could run it normally.

BTW, I got the old laptop free, but its been a good testing platform, and with a decent o/s is quite usable, compared to XP or Vista, which run like such absolute snails even with lots of memory and fast cpus, with their bloated registries and big memory hogging browsers, etc. What makes the old laptop such a good testing platform is that if the software isn't efficient, you see it immediately, and when I put efficient software on my faster ones, there is no waiting for anything, so much so that sometimes they finish things so quickly that I wonder if they actually did what was asked.

You could check the md5 sum of the initrd.gz and of vmlinuz. If you mount the boot device (LiveCD or LiveUSB) the files of interest are all in the /antiX directory. We have a .md5 file for linuxfs, initrd.gz and vmlinuz.

The fact that you get that error message indicates the kernel is functioning. The next thing you are supposed to see is the output from the init script inside initrd.gz. If that file is corrupted, it would explain your symptom. There shouldn't be hardware compatibility issues with the initrd. If the kernel works (and it does) then the programs in the initrd should work too. That's why I suggest you check the md5 of the initrd.gz. I guess it is possible the file is read wrong during the boot process but is read correctly when tested. Another thing to try is to switch to LiveUSB (if you are using a LiveCD) or switch to LiveCD if you are using a LiveUSB.

Oh yes! One more thing to try is the"noclear" boot option. I don't think it will fix your problem but it might leave more clues on the screen. You could also combine this with removing the"quiet" option.

anyone having success getting ceni to work. I've tried on two different (live) systems now and ceni fails when trying to set up the wireless, after you've gone through all the selection screens. scan works fine.

WiCD also works fine, although I get a dbus error, the connection stays active.

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. 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. 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.