Stuff that has not yet gone into the official build.
Post a reply

Re: Alternative usb installation method, part 2

Fri Jan 10, 2014 6:58 pm

Even though I don't understand the technical back and forth, I find it fascinating.

dzz wrote:
I just want to find a way to give a friend Linux with persistent capabilities to play on without messing with his Windows (xp and 7) MBR in any way. Trying to set up a dual - actually triple - boot with winders on someone else's machine terrifies me. I'm hoping this can be an easy and 'safe' solution.

A very safe option which will give a good introduction to Linux till ready to do a "real" install. A Refracta live image does not even automount the fixed disk (some distros might). Mine boots within 30 seconds on a core 2 and runs fast.

Live disks are fine for taking a quick tour through a new distro or to repair fixed disks. But having to start from scratch every time you pop in a live disk really sucks. The continuity provided by persistence will give him a better idea of how Linux works on a 'real' install.

A bit OT . . .I was cleaning up my old bookmarks and found this. The part about running it in virtualization was interesting. Wonder if that could be adapted for Linux on Linux.

Re: Alternative usb installation method, part 2

Sat Jan 11, 2014 12:56 pm

It looks like LiLi is using VirtualBox. That's pretty cool that you can test the live usb without rebooting. But you don't get to see if the linux works with your hardware, because vbox will emulate linux-compatible hardware.

What isn't clear to me is whether the vbox is running from the usb stick or if it gets installed in Windows. If it's the latter, you can do the same on linux, but you'd have to install virtualbox on your hard drive. And then, I'm not sure what you'd do. FYI, refracta is developed in a virutalized environment (virtualbox). I've tried to boot a live usb inside vbox, but I couldn't do it. What I was able to do was create a disk image from the usb and use that in vbox. I did that exactly because I didn't want to reboot. But it takes longer than rebooting, even with all the passwords I have to enter to mount the various encrypted partitions on the four hard drives that are currently in this box and open all the programs I usually keep open.

Code:
dd if=/dev/your-usb of=filename.img
VBoxManage convertdd filename.img filename.vdi

Then use the .vdi file as an existing hard disk image in virtualbox. Either add it to an existing virtual machine as the first hard disk or create a new virtual machine and choose it as the existing hard disk image.

It's also possible to boot the .img file with qemu.
Code:
qemu -drive file=filename.img
But qemu is painfully slow.

Re: Alternative usb installation method, part 2

Sat Jan 11, 2014 11:26 pm

fsmithred wrote:It looks like LiLi is using VirtualBox. That's pretty cool that you can test the live usb without rebooting. But you don't get to see if the linux works with your hardware, because vbox will emulate linux-compatible hardware.

What isn't clear to me is whether the vbox is running from the usb stick or if it gets installed in Windows. If it's the latter, you can do the same on linux, but you'd have to install virtualbox on your hard drive.

I found the answer in step 4 of the user's guide:

Enable launching LinuxLive in Windows (= Virtualization):

This is the most important option. It allows you to launch a LinuxLive directly in any Windows without any configuration nor software installation on your hard drive. No other Creator offers this exclusive feature.

LinuxLive USB Creator made it possible with a special homemade version of the famous virtualization software VirtualBox. It will download this portable version on your USB key (no installation) and will set it automatically for you. If you don't know what virtualization is, then read the What is virtualization? article of the FAQ.

To launch your LinuxLive in Windows, just run Virtualize_This_Key.exe * located in the VirtualBox folder on your USB key.

* Be aware that you need local administrator's privileges in order to launch VirtualBox.

Mull that over and maybe you'll find way to do it on Linux. Would be a neat additional feature . . .

But here's a downside . . .

Be aware that persistence CAN'T be used in VirtualBox.

Re: Alternative usb installation method, part 2

Sun Jan 12, 2014 9:21 pm

I think there's a good subliminal message there for the Win users - "Linux won't make you reboot all the time."

It is kind of a neat idea, but to really try linux, you need to reboot to see if all your hardware works. You can't do that in vbox. As for doing the same thing in linux, there might be a way, but it might be necessary to install vbox from the repository for your distro. Or make distro-specific versions, since different distros put things in different directories or have different names for the same thing.

If you still have a windows installation and you try this, please tell us about it. I'd be interested to see what ends up on the usb stick.

Re: Alternative usb installation method, part 2

Sun Jan 12, 2014 9:39 pm

fsmithred wrote:If you still have a windows installation and you try this, please tell us about it. I'd be interested to see what ends up on the usb stick.

Hahahahah! Sorry, I nuked all things windoze years ago. Was hoping one of you guys would still be bi-lingual.

Re: Alternative usb installation method, part 2

Wed Jan 15, 2014 1:07 am

Different distros?.. just realised I haven't tried a different debian-live image yet!

I'm working on a new ExeGNU (wheezy) image at the moment as Trinity Desktop (KDE3 fork) is close to R14 release. It is essentially a standard debian-live format except the menu is a single isolinux.cfg rather than split into multiple files and there is a custom isolinux gfxboot. Like most debian-live images there is no preconfigured user and all live-config scripts are run.

Refracta2usb transferred that iso to usb perfectly and it ran fine, including the gfxmenu.

Adding custom initrd also worked. The added (Refracta default) menu entry needed manual editing for live-config (not difficult to do)

RE virtualbox: Is this a "black art"? Or is my core2 with 2GB ram not enough to run it at a usable speed? Qemu is guaranteed to give me the rage. I use a chroot, or a live usb, for most dev stuff.

An old Windows XP install still exists here but is almost never used.

Re: Alternative usb installation method, part 2

Wed Jan 15, 2014 5:41 am

dzz wrote:RE virtualbox: Is this a "black art"? Or is my core2 with 2GB ram not enough to run it at a usable speed? Qemu is guaranteed to give me the rage. I use a chroot, or a live usb, for most dev stuff.

My best machine is a Intel(R) Celeron(R) 1.60GHz with 4 Gigs of Ram, so i am rather on low-end machines (compared to others). Hence i am not the right person to ask, i am used to slow responding in VBox.
You probably will not be able to run the big environments in a satisfying way (that is real work. It is ok to have a quick look).
Set RAM as high as possible (-> Settings -> System). 512 should be ok, a Gig is good
and also Video Memory (-> Settings -> Display).
Cli should always work fine, even with much less specs. Gui can be a pain (even when using something like fluxbox).

I never looked that much into the subject of tweaking VBox and the last few months i barely use it at all.

qemu, to me, was unusable (from a speed point of view). people say kvm is _much better (as long the CPU supports it:
grep -E '^flags.*\b(vmx|svm)\b' /proc/cpuinfo
must list: vmx or svm
nothing beats chroot, of course.

Short version: Nah, if it bugs you it probably isn't you, but simply is that way,

Re: Alternative usb installation method, part 2

Thu Jan 23, 2014 7:51 pm

refracta2usb-0.9.4u.deb is in the testing folder at ibiblio. I made some adjustments in the path names, and it no longer requires a /live directory in some tasks. Other names will be preserved (e.g. antiX). Seems to be working. Tested findiso, multiboot, patch-initrd and mkloopback a few times, and it seems to do the menu entries correctly.

* (refracta2usb)
* Don't need /live folder for setup_findiso, setup_multiboot, or
* replace_live - other names for /live will work, and findiso uses
* $target_dir instead of ${target_dir}/live.
* Moved select_kernel and select_initrd to functions file.
* copy_syslinux set to FALSE in setup_options()
* In setup_multiboot and setup_findiso, boot menu from the iso file
* opens in text-info window just before actual boot menu opens.
* Moved tests for $save_syslinux in replace_live() up to beginning
* of function and reverserd their order.
* Added --progress and -h to rsync commands.
*
* (mkloopback)
* Don't need /live folder.
* Test if first partition was selected, in case user does not set the
* option, so that custom initrd warning is shown.
*
*(patch-initrd-gui)
* Don't need /live folder - uses existing path to kernel and initrd.

Re: Alternative usb installation method, part 2

Sat Jan 25, 2014 3:15 pm

Thanks fsr, will test as soon as I can. The patch-live-initrd script will need updating at some stage.

Re: Alternative usb installation method, part 2

Mon Jan 27, 2014 6:01 pm

I keep ending up with extra loop devices hanging around. Even ran out of loops the other day while testing. I think it happens when I run select-loop-mount and abort the run before it's done. Made some changes in the cleanup that may have fixed it, but in the meantime, I wrote a script to seek and destroy unused loop devices. It may or may not work right in zenity. I had to get rid of the buttons.

Code:
#!/usr/bin/env bash
# killloops

source /usr/lib/refracta2usb/functions_r2u
yad_zenity_compat

select_loop () {

selection=$(find /dev -mindepth 1 -maxdepth 1 -name "loop[0-7]" -exec losetup {} \; | sort | \
   $DIALOG --list --column ' ' --height 220 --width 450 --title="Select Loop Device" \
   --text="
Select the loop device you want to delete. If you pick one
that is still in use, it will not be deleted.

If the list is empty, there are no loop devices set up. \n" )
   
   if [[ $? = 1 ]] ; then
      exit 0
   fi

strayloop=$(echo $selection | cut -d":" -f1)
delete_loop
}


delete_loop () {
report=$(losetup -d "$strayloop" 2>&1 | $DIALOG --$INFO \
--text=" If there's no error message below, the command worked.
Continue to delete another loop. \n" --width 450)
   if [[ $? = 0 ]] ; then
      select_loop
   else
      exit 0
   fi
}


# Check that xserver is running and user is root.
[[ $DISPLAY ]] || { echo "There is no xserver running. Exiting..." ; exit 1 ; }
[[ $(id -u) -eq 0 ]] || { $DIALOG --title=Error --$ERROR --${BUTTON0}="OK"${BUTTON0NUM} \
--text="You need to be root\! \n\nCannot continue." ; exit 1 ; }


select_loop

exit 0
Post a reply