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

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Alternative usb installation method, part 2

Thu Nov 07, 2013 3:55 pm

> dzz wrote:

> > fsr wrote:
> > Other thing I need to do is rewrite refracta2usb. I'm planning on removing the encryption hack, since it won't be needed for jessie/sid, and after coaching someone through using it over the phone, I want to rearrange some stuff. For one thing, right now, every step requires identifying the usb drive you want to use. That should only have to happen once. I also want to add an option to add and edit persistence.conf.
> > Couple of questions/requests to you, dzz:
> > - I think you mentioned that you wrote a hook to delete 70-persistent-net.rules. I'd like to add that.

> 70-persistent-net.rules cause havoc when you boot a full-persistence live image in a different machine
> post2885.html?hilit=70%20persistent%20net.rules#p2885

> > fsr:
> > - Might also want to add the hood for writable rootfs

> .
> Assuming you mean hook, and "writable rootfs" means the live-media partition (usb) is writable, this still works in wheezy and current sid: http://exegnulinux.net/refracta/experim ... trd.tar.gz It merely generates an alternative initrd.custom.img (does not modify the actual system's live-boot code)
> For some years, whenever someone asks official debian-live for this it gets ignored or pushed to the bottom of the "wishlist" department. There is no good reason why it must be RO with no exceptions.

> > fsr:
> > - Is there any reason why I can't remove the need for running a terminal with the script?

> Was (only) my preference, when I first did live-usb installers, to use xterm. I also used "pv" to show a progress bar for longer operations like copying a large iso. Shows what's going on better than a pulsating dialog.

> fsmithred wrote:Yeah, I meant hook and writable live media partition. I got the tarball but haven't looked at it yet. Thanks.
> Not sure the hook is needed anymore. My sid does not have 70-persistent-net.rules, but it does have the 75-persistent-net-generator.rules file. I don't know if that's because it's installed in vbox or if it's something else. I need to start keeping a list of things that are different or missing in sid.

> dzz wrote:

> > fsr:
> > My sid does not have 70-persistent-net.rules

> Mine do, seems no different from wheezy, however they are "real" installs not vm's. That was my workaround. Else every time you boot a different machine eth0 becomes eth1 then eth2... then you have to reconfigure networking manually. I never bothered with a live-config script because it only needs doing one time in a full-persist setup.
> With my usb installers I tried including features like that (and editing persistence.conf).. then what was originally a fairly simple bash script got a lot larger, more complex and more work to maintain..
> Anyway, there it is (patch-live-initrd) as a stand-alone script complete with "readme" file. It simply generates an alternative initrd to (optionally) boot from, with a couple of files patched in the initrd only.
> Reasons I started doing usb installers: I don't like the dd method, chopping small drives into partitions, unutbootin. I do like the option to multiboot and that the device be usable on all platforms, for which we must live with the horrible FAT filesystem.

> > I realize that we should probably start a new thread.

> Yes, somewhat OT from Installer option: "Do not format" !

fsmithred

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Re: Alternative usb installation method, part 2

Thu Nov 07, 2013 4:07 pm

Been playing with changes in refracta2usb. I tried the patch-initrd script, and it works very nicely. Thanks for that, dzz. Current plan is to add it to the refracta2usb package, and arrange things so that you can call that script from the main program.
I thought I could get rid of the mkusbcrypt script and the associated hook for encrypted persistent partition, but I see that sid and jessie still have the same version of live-boot as wheezy, so I guess encrypted persistence is not an option in live-boot. Does encrypted persistence work with the patched initrd? If so, I can get rid of some stuff to simplify things.
dzz

- dzz
- Posts: 647
- Joined: Wed Apr 27, 2011 11:53 am
- Location: Devon, England

## Re: Alternative usb installation method, part 2

Thu Nov 07, 2013 11:06 pm

> Does encrypted persistence work with the patched initrd?

Yes! Partition, or loopback file (which can run from the live-media partition or other).. LUKS persistent files in non-luks partitions otherwise only work in more recent live-boot experimental versions. See the "readme" file in patch-live-intrd.
The RW patch is based on (old experimental) live-boot_4.0~a7-1 ..There's been quite a bit of activity in debian-live lately so who knows how much longer it's current version will work for sid. .. Probably good for wheezy's lifetime though.
fsmithred

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Re: Alternative usb installation method, part 2

Sat Nov 09, 2013 10:44 pm

Try this. It's not nearly finished yet, but pay attention to how it flows, and let me know if that makes sense. Also, I think there might be another advanced option - multiboot. But I'm not familiar enough with the procedure. I've done it once, I think. A description would help. Probably need help with persistent loopback and encrypted loopback files, too.
unpack in your home, cd into r2u1/ and run ./r2u_beta1 (add -d for debug mode).
http://distro.ibiblio.org/refracta/file ... ta1.tar.gz
I haven't tested everything yet, but I assume that most of the stuff from previous refracta2usb works. That would be most of the items in the main menu. Updating a working stick with a newer iso works, and creating a standard persistence partition works. Edit boot menu work, so does opening the help file (but maybe in a text editor isn't the best choice for Help.) Help file is sorely out of date. I'll do that when I figure out what the program is going to do.
I've arranged it so that you go back to the main menu when a task is finished, but this has only been done with a few tasks. I need to add the egress function to a few more places. Or maybe not. That behavior might only be helpful in a few places.
fsmithred

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Re: Alternative usb installation method, part 2

Sun Nov 10, 2013 2:47 pm

Change the test in select_device_gui() around line 168 of r2u_beta1 to the following, and you can run the program without plugging in a usb stick. Obviously, it won't do much that way, but you can look at it and access the help page. It's more user-friendly this way.

Code:
  `if [[ -z "$usbdevfulllist" ]] ; then
  # exit_message=" Warning: No USB devices detected. Exiting..."
  # exit_dialog
  $DIALOG --$QUESTION --title="$TITLE" --text="No USB drive was detected. You need to plug in the drive before starting this program.
  Continue if you just want to look at the program." \
  --${BUTTON0}="Continue"${BUTTON0NUM} --${BUTTON1}="Exit"${BUTTON1NUM}
  if [[ $? = 0 ]] ; then
  run_task
  else
  exit 0
  fi
  fi`

fsmithred

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Re: Alternative usb installation method, part 2

Sun Nov 10, 2013 3:53 pm

Better...

Code:
  `if [[ -z "$usbdevfulllist" ]] ; then
  no_device_message="\n ### No usb device was detected. Plug it in and Rescan. ###"
  run_task
  fi`

Instead of giving you the choice to exit or continue, it goes right to the Main Menu, where the message will show up if nothing is plugged in. There's a Rescan choice in that menu that will run select_device again, so you can start the program without a stick plugged in, plug one in and rescan for the device.

Code:
  `if [[ $opts =~ Rescan ]] ; then
  select_device_gui
  unset no_device_message
  egress
  fi`

thwak

- thwak
- Posts: 174
- Joined: Tue Nov 20, 2012 3:58 am

## Re: Alternative usb installation method, part 2

Sun Nov 10, 2013 11:58 pm

This commentary is general. I haven't tried the latest script.

> I've arranged it so that you go back to the main menu when a task is finished

Yeah, just dump me back to the main menu...
...and PRESUME I'm gonna remember which steps(s) have been completed and what step needs to be done next.
To you, the GUI presents a menu. To an experienced user, it's a menu.
For a newer user, though, it an "application"... and leaves the user wondering "what am I supposedta do now?"
Where a "menu" GUI presents not-necissarily-linear options/steps,
a checkmark or other indicator highlighting the most-recently completed step would be a suitable navigational aid.
I raise this exact same pain point for the various Saline and Antix "GUI" utilities.
Puppy (gtkdialog) GUI utilities attend to this, providing a clear indication of "you are now HERE" and "what's next"
but the various authors of yad-tastic apps seem oblivious to the poor usability resulting from
nearly non-existent (or, "much, MUCH too terse") descriptive onscreen text
and lack of focus/highlight some sort of visual indication of where, in a multi-step procedure, the user currently is.
Similarly, consider "what's the user left starting at" following presentation of a self-destructing "progressbar" dialog,
or a notification -style dialog which times out and auto-closes. Some of the utilities cheekily suggest "go get a cup
of coffee; this will take several minutes." ...so user may not even see a short-lived, end of operation "notification" dialog.
fsmithred

- fsmithred
- Posts: 2101
- Joined: Wed Mar 09, 2011 9:13 pm

## Re: Alternative usb installation method, part 2

Mon Nov 11, 2013 11:06 am

You make some good point, thwak. I don't know if it's possible to leave a breadcrumb trail of completed tasks with yad and zenity. In this case, many of the menu items are non-linear and even mutually exclusive. I'm going to rely on the user to choose the first item in the menu, which says "Help - Instructions - Read Me!", opens in a separate window and stays open even if the program crashes. Then they can follow along the steps. And most of the time, there will only be a few steps.
Here's beta2 (and these betas probably should have been labeled as alpha)
http://distro.ibiblio.org/refracta/file ... ta2.tar.gz
patch-initrd has been incorporated and seems to work. The file-selector opens in the live folder of the selected (and pmounted) usb stick. Paths are still set for everything in the untarred directory somewhere in your home. Work directory (where the patch gets applied) is ~/patch-initrd, and any previous directories get numbered.
(Note: mkusbcrypt is present, but I haven't changed any of the paths to work from your home. It might work if you have an older version of refracta2usb installed, but I haven't tried it.)
dzz

- dzz
- Posts: 647
- Joined: Wed Apr 27, 2011 11:53 am
- Location: Devon, England

## Re: Alternative usb installation method, part 2

Fri Nov 15, 2013 12:19 am

thwak has a point. Too many options "in your face" or submenus that don't make clear where you are, were or should go next, get confusing for not only new users. However "dumbing down" (the latest mainstream trend?) where advanced options are abandoned or hidden is no good either.
I mean that generally, been too busy to look properly at this new stuff till just now (and still have to find a clear pen drive to test)
To keep the main script more simple (and easier to maintain) some extra options might be better done post-setup as separate sub-scripts
Note: patch-initrd needs the actual replacement /lib/live directory (live.tar.gz), I don't see it in r2u_beta2
I normally generate a custom initrd later, then place it with the original and make an extra menu entry.
It is worth looking at (luks or not) loopback files for persistence. Live-boot can find one automatically in the same way (label) as a persistence partition. "Loopback" files are versatile and portable. You can have more than one for different configurations (by specifying persistence-path=directory_containing_file)
I don't know another way to get multiboot with dedicated persistence for each
Making a luks file is a bit long-winded by cli. Here is a script I use for to make either a persistence or other purpose file: http://exegnulinux.net/refracta/experim ... ile_0.1.sh .. Use as a script or pick out the bits.
BTW pmount => 0.9.99-alpha-1 (in experimental but no extra deps) can open and mount luks files (e.g. a portable "personal data vault") http://packages.debian.org/experimental/pmount
dzz

- dzz
- Posts: 647
- Joined: Wed Apr 27, 2011 11:53 am
- Location: Devon, England

## Re: Alternative usb installation method, part 2

Fri Nov 15, 2013 12:34 pm

Got patch-initrd working from the script after a few tweaks.
The main script was resetting $tempfile *after* the confile was sourced (~line 21)
Script (patch-initrd) was looking for $tempfile in a dir that did not exist (as set in conf file)
live.tar.gz needed copying in to $initrd_work_dir/ (~line 158)
Will look at other options when I can
EDIT (more)
"edit boot menu" didn't work right because the device was either already mounted somewhere different than expected or not mounted at all
To actually use rw mode for live-media partition requires an exta cmdline parameter "basemountmode=rw,noatime" or "basemountmode=rw,noatime,umask=000" (else it will default to "ro,noatime" .. see patch-initrd "readme"). That parameter is just ignored without error by a standard initrd's live scripts
How to automate that or how best to clearly present it to a user is another matter.
Post a reply
Jump to:

Powered by phpBB © phpBB Group.

phpBB Mobile / SEO by Artodia.