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

## Re: Alternative usb installation method, part 2

Fri Nov 15, 2013 2:45 pm

Thanks, dzz. In the beta2 tarball, I think most stuff was still not working. I've moved some stuff around so that the tasks that most people will use are in the main menu, and all the other stuff is in the advanced menu. Changed wording on the ISO and Live tasks to start with "Create Live-USB..." to match wording in the help file and make it more obvious what those choices are for.
mkpersist and mkusbcrypt are separate scripts that get called from the main script, and those are working. One way you might get separate dedicated persistence on a multiboot would be with multiple partitions, each with a different disk label. You just add "persistence-label=LABEL" to the append line. mkpersist will take whatever label is on the partition you choose for persistence and echo a comment with the above boot option into the boot menu, so you can copy/paste it into place. (I haven't uploaded that version yet.) I decided to add that after I plugged in two sticks with persistence partitions, and they both showed up on my desktop with the same name.
Other stuff I'm working on: Made a config file. Right now, it's one config file for refracta2usb, mkpersist, mkusbcrypt and patch-initrd-gui. Also pulled some of the common functions out of the scripts and put them in a functions file. That makes it easier if I need to change any of those functions.
I might upload one more tarball when I get everything working, and then make a deb file. Not sure how much "everything" will be. Was going to leave out the loopback and cryptloop, but with your additional script, it might be easy to add it in.
thwak

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

## Re: Alternative usb installation method, part 2

Sat Nov 16, 2013 3:43 am

> You just add "persistence-label=LABEL" to the append line

3 days from now, will I remember the exact LABEL string I saved as?
Puppy Linux does this (supports multiple savefiles) and the savefiles are written to a specific directory.
At boot, that directory is scanned + any savefiles present are listed. User is invited to choose from the list which to load this session (or none of them)
nadir

- nadir
- Posts: 1160
- Joined: Wed Mar 09, 2011 4:18 am
- Location: here

## Re: Alternative usb installation method, part 2

Sat Nov 16, 2013 3:51 am

blkid
or
ls /dev/disk/by-label
will give info about labels.
As i never really used them i am not sure if that is of any help.
fsmithred

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

## Re: Alternative usb installation method, part 2

Sat Nov 16, 2013 10:38 am

If you have multiple configurations you can boot into, you're going to have to remember something about them to tell them apart when presented with a list, whether that list comes from a scanned directory or a boot menu file. Since you can't see the "persistence-label=LABEL" without hitting the TAB key, I suggest you give them each unique names in the menu label line of the boot menu.
What I could and might do is have the script add a complete boot menu entry, and put the disk label in the menu label line. Then you wouldn't have to edit the menu if you didn't want to.
dzz

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

## Re: Alternative usb installation method, part 2

Sat Nov 16, 2013 3:30 pm

> One way you might get separate dedicated persistence on a multiboot would be with multiple partitions, each with a different disk label. You just add "persistence-label=LABEL" to the append line

> persistence-label=LABEL
> live-boot will use the name "LABEL" instead of "persistence" when
> searching for persistent storage. LABEL can be any valid filename,
> partition label, or GPT name.

True (in theory) but that way clunks. Multiple partitions on a small drive waste space. Makes adding a new system without trashing an existing one a problem. Easier to place a file labelled "persistence" in a dedicated directory and use:

> persistence-path=PATH
> live-boot will look for persistency files in the root directory of
> a partition, with this parameter, the path can be configured so
> that you can have multiple directories on the same partition to
> store persistency files.

Obviously (for multiboot) the actual live-media files also need to be organised in directories and referenced on cmdline
Working example (device sdb, using rw live-media mount):

Code:
  `menu label refracta-sid
  #menu default
  kernel /refracta-sid/vmlinuz
  append boot=live initrd=/refracta-sid/initrd.custom.img live-media-path=/refracta-sid/ basemountmode=rw,noatime union=aufs quiet persistence persistence-path=/refracta-sid/ persistence-encryption=none,luks`

All files are in directory "/refracta-sid". Using the standard initrd the persistence file(s) must be in the referenced directory on a second partition (because sdb1 is mounted RO)
BTW syslinux supports submenus, if your menu is quite long it's tidier to break it down
I just today added a new sid snapshot to a single-partition pendrive. Luks persistence in a file is successful.
fsmithred

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

## Re: Alternative usb installation method, part 2

Sat Nov 16, 2013 6:09 pm

Thanks for the info on multiboot and persistent files. I agree that it does make more sense to do it that way rather than multiple partitions.
Here's beta3 -
http://distro.ibiblio.org/refracta/file ... ta3.tar.gz
Yeah, it's still a tarball and still runs from the local directory. If you happen to check the option, "Copy default refracta syslinux folder" you'll get the one in /usr/lib/refracta2usb. Edit boot menu now edits to boot menu on the selected usb drive. (I think the last beta was using the example menu.)
This one does work. There may be a problem with installing syslinux to the mbr. I've had it work for me and not work for me (after zeroing the beginning of the drive.) So there's a new feature: install althernate bootloader, which uses 'install-mbr -e 1FA <device>'.
Edit: I assumed that patch-live-intrd was a typo, and I changed intrd to initrd. Tarball and unpacked directory are included.
thwak

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

## Re: Alternative usb installation method, part 2

Sun Nov 17, 2013 2:25 am

> Since you can't see the "persistence-label=LABEL" without hitting the TAB key

The puppy construct detects presence of savefiles later in the init (NOT handled in the boot line)
and if any are present, user is presented with "choose a savefile to load (or none)" during startup.
The puppy savefiles are squashfs. Same as the "persistence" file(s) you are using, yes?

Code:
  `Would you like to load a savefile this session?
  0) none
  1) lengthy_highly_descriptive_name_of_savefile_and_perhaps_autoappended_datetime
  2) openoffice_and_other_shite_i_typically_dont_care_to_load_but_sometimes_need
  3) NSFW_dont_boot_to_this_if_wifey_is_around
  4) rollback_waypoint___prior_to_upgrading_gtk_etc_libs
  `

They (puppy) even go a step further. Rather than example #2 above, you might load openoffice or whatever on-demand, from a "pet" file during a session (vs creating a bloated savefile within which OO is permanently installed.
I'm not suggesting "refracta should be more like puppy" but...

> Multiple partitions on a small drive waste space. Makes adding a new system without trashing an existing one a problem.

...but I do see merit in supporting multiple savefiles.
For me (continually installing/uninstalling/testing stuff), frugal install + multiple savefiles seems like a winning approach.
(To each his own. Tinkering from within the constraints of a VM is entirely unappealing to me.)
With Barry K's retirement, and in light of many puppy users' apparent longstanding and unfulfilled desire
for a "debian-based" alternative (2 attempts, but neither DPup nor pussygut cuts the mustard)
supporting multiple savefiles in Refracta might attract a wave of puppy emigrants.
ps, while I'm thinking about it:
Anthony Nordquist announced yesterday that SalineOS is closing
dzz

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

## Re: Alternative usb installation method, part 2

Sun Nov 17, 2013 2:09 pm

Some errors testing r2u_beta3:
Main script: select_device_gui
Error message "Device $device is not a block device." appears, although it is
Dialog window does not return on closure or failure to select
Dialog window does not allow exit from button
Error dialogs offer to "proceed anyway" although maybe in an impossible situation
patch-initrd-gui:
Errors because trailing slash in config file (live_tarball="./patch-live-initrd/live.tar.gz/")
mkusbpersist:
Error message "Persistent partition is ready and has a
non-standard label. You need the following
option in the append line of your boot menu"... (although it is labelled "persistence")
Appends to log rather than making a new one (>>)
####################################
Mostly simple fixes.. "Device $device is not a block device.", a bit harder.
More later.
fsmithred

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

## Re: Alternative usb installation method, part 2

Sun Nov 17, 2013 3:16 pm

I made some changes to exits and error messages, but I know I'm not done. Did change what happens when you don't select a device. Also found the trailing slash on live.tar.gz this morning, while experimenting with multi-boot.
Fixed (I think) this function in r2u_beta/refracta2usb

Code:
  `select_device_gui () {
  usbdevlist=$(/usr/sbin/hwinfo --usb --short|grep "/dev/sd"|awk '{print $1}')
  usbdevfulllist=$(/usr/sbin/hwinfo --usb --short|grep "/dev/sd"|awk '{print $0}')
  if [[ -z "$usbdevfulllist" ]] ; then
  no_device_message="\n ### WARNING: No usb device was detected. Plug it in and Rescan. ###"
  run_task
  fi
  echo -e "\n\tLIST OF USB DEVICES\n\n$usbdevfulllist\n"
  device=$($DIALOG --width=400 --height=200 --title="$TITLE" --list --separator="" --column="" --text=$"Detected USB devices:\n\n$usbdevfulllist\n\nPlease select the correct one to use" $usbdevlist \
  --${BUTTON0}="OK"${BUTTON0NUM} --${BUTTON1}="Exit"${BUTTON1NUM})
  if [[ $? = 1 ]] ; then
  exit 0
  fi
  if [[ -z $device ]] ; then
  no_device_message="\n You did not select a usb device. Rescan to select one."
  warning_message="\n You did not select a usb device. Rescan to select one."
  warning_dialog
  elif ! [[ -b $device ]] ; then
  echo "Device $device is not a block device!"
  no_device_message="\n You did not select a usb device; rescan to select one."
  error_message="Device $device is not a block device."
  exit_dialog
  else
  echo "$device" > "$tempfile"
  fi
  }
  `

warning_dialog is in functions_r2u and currently looks like this:

Code:
  `warning_dialog () {
  $DIALOG --$WARNING --title="$TITLE" --text="$warning_message" \
  --${BUTTON0}="OK"${BUTTON0NUM}
  }`

Well, I can't reproduce the "not a block device" error, so I guess it's fixed.
Another thing I discovered was that the "do_not_exit" option wasn't really controlable from the setup options window, so I moved it out to the config file. Also switched reset defaults button with the menu choice to exit, so now you select 'reset defaults' from the menu and the right-button will exit the script.
Will look at the persistence label part again. I changed that a few times, and I'm not sure where I left it.
fsmithred

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

## Re: Alternative usb installation method, part 2

Sun Nov 17, 2013 3:28 pm

@thwak:
The persistence files are not squashfs. The only squashfs is /live/filesystem.squashfs which is the squashed image of the operating system that comes from the iso file.
It might not be too difficult to make snapshots of your persistent files. I'd have to play with that a bit. I just started experimenting with persistent loopback files this morning. You can do it now, either fully-manual or with dzz's script. Create a loopback file (doesn't have to be encrypted, but the script only does encrypt.), boot with persistence on that loopback file, install stuff you want. Make a new loopback file, boot with that, install different stuff... You'd need to make different boot entries for each loopback file, then choose the one you want at boot.
Post a reply
Jump to:

Powered by phpBB © phpBB Group.

phpBB Mobile / SEO by Artodia.