kmathern wrote:However, I'm not able to get it to boot in UEFI mode, it doesn't seem to detect the LiveUSB key when in UEFI mode. I had to change it to the legacy (CSM) mode to get it to boot my LiveUSB key.
How did you make the LiveUSB? It needs the /EFI directory and the /boot/grub directory in order to boot in UEFI mode. If these are missing, maybe you can mount the iso file directly and copy those directories to your LiveUSB.
When I made a LiveUSB with Unetbootin on Windows, it made those directories (and their contents) automatically.
Also, the LiveUSB must use a fat32 file system in order for UEFI booting to work. If you use ext2/3/4 then it doesn't matter if the directories exist because UEFI doesn't read those file systems.
kmathern wrote:However, I'm not able to get it to boot in UEFI mode, it doesn't seem to detect the LiveUSB key when in UEFI mode. I had to change it to the legacy (CSM) mode to get it to boot my LiveUSB key.
How did you make the LiveUSB? It needs the /EFI directory and the /boot/grub directory in order to boot in UEFI mode. If these are missing, maybe you can mount the iso file directly and copy those directories to your LiveUSB.
When I made a LiveUSB with Unetbootin on Windows, it made those directories (and their contents) automatically.
Also, the LiveUSB must use a fat32 file system in order for UEFI booting to work. If you use ext2/3/4 then it doesn't matter if the directories exist because UEFI doesn't read those file systems.
When I was trying to get it to boot in UEFI mode, I did have the key formatted using fat32. One time I created the LiveUSB key using Unetbootin. On another try I roughly followed instructions you posted last fall in a topic in the Development team subforum at the Mepis forum:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE =========== url was:"http://forum.mepiscommunity.org/viewtopic.php?p=351096#p351096" linktext was:"http://forum.mepiscommunity.org/viewtop ... 96#p351096" ====================================
, I didn't need to use the uefi-2014-11-17a.tgz tarball download though because the antiX-15-beta1-V iso now includes the /boot and /EFI folders and their contents. If you recall from that topic, I also wasn't able to get it to boot in UEFI mode back then.
The LiveUSB key that I was able get to boot in Legacy/CSM mode was created by dd -ing the iso to it.
Full install on an old Compaq V2000 - 'apt-get update was very fast' ... media, graphics fine, Broadcom BCM4318 wifi also fine. Audio working as well but not the volume buttons @ the keyboard are non-responsive.
Last edited by Servo on 22 Mar 2015, 22:47, edited 1 time in total.
After recreating the LiveUSB key (not using Unetbootin), I finally got it to boot in UEFI mode, at the correct resolution and using the radeon driver. (though not in a very straightforward manner -- discussing that with BitJam in a PM).
Took 2 attempts, the first try wouldn't boot and had fun error messages. Guess it was one of those"didn't copy all the right stuff to the hard drive" attempts. Second try, no problem. __{{emoticon}}__
This build provided the smoothest, most pleasant, first-run live session I've encounterd since v13.2, back in in 2013.
Apparently my Audigy sound card was autodetected; that's a nice surprise.
cosmetic:
The globe at lower-right displays correctly (round) in console, but wallpaper shows it egg-shaped.
If the default wallpaper image is currently one-size-fits-all (is stretched to fit) maybe a smaller"centered" default image would be preferable?
bug/quirk:
controlCentre --} Hardware tab --} Select sound card
If the"Cancel" button is clicked, the dialog box titlebar and window border disappear.
bug/permissions:
controlCentre --} Hardware tab --} PC Information
select"Repository"
information is displayed to a roxterm window _AND_ a yad dialog inviting"Edit repositories" is displayed.
Clicking"OK" causes the utility to abend/close.
iceweasel:
The pre-installed"FlashBock" addon has become obsolete/redundant. Iceweasel now provides"Click to Play" permissions for each individual plugin, including Flash.
usability issue / theming:
Same as reported earlier, repeatedly... the background color of checkbox input fields (only affects GTK3 applications?)(the yad dialogs etc are unaffected)
does not stand out from page background color, nor is a differently-colored border visible.
usability issue / keybinds:
Who moved the cheese? I immediately noticed the absence of Alt+F2 = gExec
(I've quickly replaced it for fluxbox, but haven't yet taken the time to pizz with the configs for the other desktops)
A suggestion -- place a link in the"Help" file (the file launched from preinstalled desktop icon) leading to"howto set/change keybinds" documentation
and consider also setting multiple default"homepage" tabs in iceweasel config, with one of the tabs set to display the"howto set/change keybinds" helpdoc.
usability issue:
Window placement is controlled by a setting in theme config?
Yad has a default location for dialog box opening position?
Something has changed compared to earlier builds ~~ each time I launch gExec (and for many other app windows)
neither does it open center-screen nor in the same-as-last-time-used position.
I'm forced into a lotta extra scrolllllllling, to reach top-left desktop corner (each new window instance is opened there)
-=-
At first, I wondered whether this is due to a not-yet-set fluxbox configuration detail...
but I noticed that same behavior, at least for the gExec dialog window, when lanuching it via the iceWM"Run" menu entry.
I'm not nitpicking. At the default (low) mouse acceleration setting, the repeated necessity of mousing-to-top-left is a noticeable usability issue.
usability:
rox-filer (and same for spaceFM, IIRC) a"Default editor" has not been set for root user.
Also (may just be my monitor settings? or, did I change away from default theme for root user?)
rox-filer"as Root" is displaying a difficult to read gray-on-gray text/bgcolor.
In the broader context, at least for root user and rox-filer, seems like default handlers (mime associations) are not set.
asking:
I respect the decision to streamline the persistence setup script for the sake of K.I.S.S.
but how/where can a user now specify a fs other than ext4 for the persistence container?
(Admittedly, I have not searched for documentation on this) (never had a need to do so)
Is an optional bootline arg available to specify desired container type? Should I create, or edit, some config in one of the boot-dev files?
Thanks {and a hug} for adding a UTC/localtime option to the bootmenu !
dolphin_oracle wrote:
8. consider placing a commented line about using the desktop-session startup entry instead of the various wm startup files.
9. Consider a wrapper script for Add Menu Entry and Remove Menu Entry, or at least rename them so they are in the same place in the menu. (Menu Entry - Add and Menu Entry- Remove for instance).
D.O. I would like some clarification on the above 2.
8. Is this commented line to be placed in the desktop-session startup? in the window manager startups? both? or where are you thinking for placement?
9. I will do a wrapper script for the moment, as in the future they will be merged into one app. So that begs the question what would be a good name for the single app / wrapper script? I have noted Add / Remove Items...
Live: No Persistence
Boot Param: lang=en_GB quiet
Desktop: Default
The the contents of the resulting desktop are unpredictable. Sometimes the icons (Files, Help, Install) are displayed sometimes they are not. It seems quite random and without an obvious pattern.
Live: No Persistence
Boot Param: lang=en_GB quiet
Desktop: Default
The the contents of the resulting desktop are unpredictable. Sometimes the icons (Files, Help, Install) are displayed sometimes they are not. It seems quite random and without an obvious pattern.
I can confirm this one. There seems to be some kind of timing issue when the session stuff loads. Sometimes I get a message about a using a"default" rox pinboard which only has a Home folder shown instead of the usual pinboard with Files and Help. This is on an installed system.
One of the stranger aspects of rox filer is that while the toolbars and such follow the gtk them, the icon text does not. This has been true for a long time. There is a separate text color setting in the rox Options.
You'll also find the same for the icon theme. If you change the gtk icon theme, it will not change the icons in rox.