You are not logged in.

#1 2019-06-10 18:49:52

AndrewSmart
New Member
Registered: 2019-06-10
Posts: 3

[SOLVED] What is live root password? --> persistence update issue

This is an old project on a flash drive, not sure what I was doing. If memory serves I had updated systemd with persistence set up and now it's FUBAR. I had to update systemd due to something else I was trying, like bluetooth or something.

I can see user:live is user:password for live install.

This is roughly the prompt I see (from memory sorry, I'll edit in a bit):

emergency mode enter root password press System-D to continue type journald -ad after logging in and view system logs:

Nothing I've tried works. "live", "user", "root", "bunsenlabs", "".

$ uname -a
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) i686 GNU/Linux
$ cat /etc/debian_version 
8.2

A message I see just before this emergency prompt is the "union mounting" of the persistence partition. I'll try to attach a photo of the screen but it is a POS camera.

Anyways, I love crunchbang, I've used my original 64-bit install of #! persistence for 5+ years and had just updated it (resquashing occasionally). This is my 32-bit usb stick for older machines... if this isn't recoverable I'll just install the latest bunsenlabs on it, no biggie.

Last edited by AndrewSmart (2019-06-13 22:31:58)

Offline

#2 2019-06-11 02:06:11

hhh
Meep!
Registered: 2015-09-17
Posts: 7,694
Website

Re: [SOLVED] What is live root password? --> persistence update issue

My (now pretty old) persistence tutorial had the flaw of me having no clue how to upgrade the kernel. That might be the problem.

Online

#3 2019-06-11 04:25:59

AndrewSmart
New Member
Registered: 2019-06-10
Posts: 3

Re: [SOLVED] What is live root password? --> persistence update issue

Ohhhh right. Thanks for the memory jog.

The solution to that problem is resquashing before shutting down. And you have to have booted with the 'toram' and 'persistence' kernel parameters so that you can write the new squashfs file to the live partition. By squashing everything that was in persistence back into live there won't be any issues with different versions of the kernel/libc/systemd on the live/persistence partitions on the next boot. The guide I have also cleans out stuff on persistence that was squashed.

I made sure to resquash everything whenever I updated the kernel or libc, and systemd I wasn't sure if I had to or not (systemd was new to me then, and I had hunch there would be problem and there was, it went FUBAR). So that is the problem I had with this flash drive, thanks again for the memory jog.

Now I need to read how to squash the live+persisntence partitions back into the squashfs externally (not booted to said live partition). Then I expect it will boot. I don't need the live root password after all. Or I guess I'll just install a more recent version of BunsenLabs now that I think about it... idk.

I noticed the old #! forum isn't displaying my resquash guide, here it is below. I came up with it after lots and lots of trial and error, reading, and failures (I'm not sure the list of pseudo files I make are complete for example, but it boots and everything I do works!). The guide could do with a rewrite things had changed since then I added a few notes where I noticed new things:

--------------OLD CRUNCHBANG PERSISTENCE RESQUASH GUIDE---------------
I followed a different guide on this #! forum for creating the live USB in the first place. I didn't use unetbootin or syslinux (just an iso, dd, grub, and gparted really).
This guide assumes:

  1. You have two partitions on the live USB:

    1. The first containing the squashfs, vmlinuz, and initrd; this partition has the 'boot' flag.

    2. The second containing the rw persistence partition, labeled 'persistence'.

  2. Your persistence.conf file contains just "/ union", on the persistence partition.

Following this guide I had squashed the 2.3GB of used space to 550MB.  The increased space usage is due to the updating process; if you want the space back we must re-squash everything into the squashfs.  If you have a humongous USB, what you would gain from this guide is a some-what faster boot.  I wish there were a way for this to be automated; but AFAIK that is not possible at this time. If all your stuff installed since the last squash is too big for the live partition, then you must either uninstall stuff or make the live partition larger. I uninstall things like java or chrome as they're large and frequently updated, not worth squashing, then reinstall them later.

  1. First, you may have noticed if you run apt-get update, you may encounter errors if update-initramfs is triggered: http://crunchbang.org/forums/viewtopic.php?id=25013
    Follow this guide to get around that problem (so vmlinuz and initrd on the first partition can be updated): http://crunchbang.org/forums/viewtopic.php?id=38301 (old #! issue, maybe bunsenlabs not affected)
    I forgot to mention earlier that /boot must be mounted, so that the squashfs, initrd.img, and vmlinuz may be updated by update-initramfs:

    sudo mount /dev/sdb1 /live/image  #Replace /dev/sdb1 with your relevant USB partition containing /boot stuff (initrd.img, vmlinuz). With more recent debian versions than #! this /live/image now seems to be /lib/live/mount/medium, and may have to be remounted as rw so that /boot can be updated by update-initramfs.
    • In the above guide you must be booted with both the 'persistence' and 'toram' kernel parameters. 'toram' is necessary to be able to mount the /boot partition otherwise it will be in-use.

  2. Now, run this script to generate the new squashfs (edit TARGET_SQUASHFS_FILE to where desired, such as /tmp or an external HDD like I did): https://gist.github.com/AndrewSmart/90e … 08db8f1426

    • In the above guide you must be booted with the 'persistence' kernel parameter; 'toram' doesn't matter, though it would be quicker if so.

    • Two further optimizations on the above script would be to not squash /boot and /var/log; though it works fine as is.

    • In the script I chose not to squash /home.

    • I suggest you back up your original squashfs the first time you try this guide.

  3. Now copy TARGET_SQUASHFS_FILE to your first partition, over ./live/image/filesystem.squashfs I believe. Also move the filesystem.packages there if you wish to follow that convention (I believe that file is necessary if you wish to install #! to the HDD).

  4. Now most everything had been squashed into the squashfs on the first partition; but there is a problem as we have the files duplicated both there and in the persistence partition.  aufs unfortunately won't clean up the duplicates from the rw branch (I wish it would).  We have to do that manually.  Boot without the 'persistence' kernel parameter, and run this script on your persistence partition: https://gist.github.com/AndrewSmart/2f6 … 1922c4556f

  5. Now boot as you normally would with the 'persistence' kernel parameter and verify you receive no new error messages on startup or shutdown.  If all is well, remove /bak at your convenience.  Enjoy your updated & condensed live USB stick!

Last edited by AndrewSmart (2019-06-13 21:22:05)

Offline

#4 2019-06-11 13:31:02

hhh
Meep!
Registered: 2015-09-17
Posts: 7,694
Website

Re: [SOLVED] What is live root password? --> persistence update issue

Thanks for posting that! I probably won't test until after Lithium is released, we have quite a bit of work to do in a short time. smile

Online

#5 2019-06-13 21:20:20

AndrewSmart
New Member
Registered: 2019-06-10
Posts: 3

Re: [SOLVED] What is live root password? --> persistence update issue

No problem, thank you for the great lightweight distro.

Yes /live/image seems to be /lib/live/mount/medium now. That is an issue in my guide above. IIRC it can be remounted rw given 'toram', as it is mounted ro by script:

/dev/disk/by-uuid/c27f1e3d-77af-4023-83a2-f143268b33ab /lib/live/mount/medium ext4 ro,noatime,stripe=128 0 0

Only after it is remounted as rw then update-initramfs can update initrd.img, though I think /boot/ has to symbolically link to the right place. Without 'toram' it won't allow being remounted as rw (IIRC).

There might be other issues, like I ought do do uuid stuff in scripts instead of stuff like /dev/sdb1. I have other utility scripts laying around, like diffing the packages between live & persistence, useful when trying to shrink the filesystem.squashfs file as small as possible.

Also maybe my issue wasn't systemd, I think my memory got mixed up. I'd updated lib & initrd without squashing them into live (I can tell by looking at persistence partition). Going to try to surgically get them in there.

My /boot/grub/grub.cfg:

menuentry "#! 11 - waldorf 3.16 64bits - by UUID - Persistence" {
  #Enter the UUID of your boot partition (this is where grub and your kernel reside)
  set uuid_grub_boot=ab3920b1-2d3f-4bf8-9da1-27bc2b5c9e2f
  #Enter the UUID of the persistence partition.
  set uuid_os_root=aedab356-05bc-4e30-ba77-6317b0210c7e
  #Here we set the grub "root" variable by locating the uuid of the root partition identified above
  search --no-floppy --fs-uuid $uuid_os_root --set=root
  #Here we set a custom variable grub_boot by locating the uuid of the boot partition identified above
  search --no-floppy --fs-uuid $uuid_grub_boot --set=grub_boot
  #Here's the magic. We test to see if the boot and root partitions have the same UUID.
  #If they do we append /boot to the $grub_boot variable. For ex. (hd0,1) becomes (hd0,1)/boot.
  if [ $uuid_grub_boot == $uuid_os_root ] ; then
    set grub_boot=$grub_boot/boot
  fi

  linux ($grub_boot)/live/vmlinuz-3.16.0-4-amd64 boot=live config quiet noeject toram persistence persistence-storage=filesystem usbcore.autosuspend=-1 live-media=/dev/disk/by-uuid/$uuid_grub_boot elevator=as
  initrd ($grub_boot)/live/initrd.img-3.16.0-4-amd64
}

menuentry "#! 11 - waldorf 3.16 64bits - by UUID - Live" {
  #Enter the UUID of your boot partition (this is where grub and your kernel reside)
  set uuid_grub_boot=ab3920b1-2d3f-4bf8-9da1-27bc2b5c9e2f
  #Enter the UUID of the persistence partition.
  set uuid_os_root=aedab356-05bc-4e30-ba77-6317b0210c7e
  #Here we set the grub "root" variable by locating the uuid of the root partition identified above
  search --no-floppy --fs-uuid $uuid_os_root --set=root
  #Here we set a custom variable grub_boot by locating the uuid of the boot partition identified above
  search --no-floppy --fs-uuid $uuid_grub_boot --set=grub_boot
  #Here's the magic. We test to see if the boot and root partitions have the same UUID.
  #If they do we append /boot to the $grub_boot variable. For ex. (hd0,1) becomes (hd0,1)/boot.
  if [ $uuid_grub_boot == $uuid_os_root ] ; then
    set grub_boot=$grub_boot/boot
  fi

  linux ($grub_boot)/live/vmlinuz-3.16.0-4-amd64 boot=live config quiet noeject toram usbcore.autosuspend=-1 live-media=/dev/disk/by-uuid/$uuid_grub_boot
  initrd ($grub_boot)/live/initrd.img-3.16.0-4-amd64
}

Notes:
live-media & persistence-storage kernel parameters seemed to be necessary for me, and uuid's necessary for jumping from computer to computer.
The menuentry I copied from a forum somewhere else, I needed something supporting live & persistence booting by UUID and I modified it.

IIRC update-initramfs or some hook thereabouts was in a crunchbang live-tools .deb package. I bet the whole process of updating the kernel on a persistence usb can be scripted in live-update-initramfs of live-tools package (I know #! had a custom script here, so I expect bunsenlabs does too). Maybe have a pre-update hook require that 'toram' is among the kernel boot parameters so that initrd & vmlinuz can be updated. Maybe resquash filesystem.squashfs when things like libc and nvidia are updated. Would be neat to have those scripts handle this automagically.

It's worked great for me for 5-6+ years as my main operating system... very fast boot time and shutdown time on USB3 ports. Can jump from computer to computer and have all my software ready, any library/lab/home. Never had to deal with Windows or unfamiliar systems again, reinstalling software over & over, or even installing linux again. HDDs are just for storage now. I love this workflow I'd settled in, works well for me.

The only issue I have is sometimes usb filesystem writes hang (blocks) when I only have 2-3 gb left of free space on the 32gb stick, like no usb reads can proceed until a lengthy write is done, it may be an old aufs/kernel or whatever bug though... I'm not sure. I just have to keep at least 3gb free space on it as it gets worse the less free space there is. I think it was a regression, I didn't have it initially until I updated the kernel. Maybe it's fixed in newer kernel or different union filesystem. I think I found the bug report and bookmarked it somewhere but it was so low incidence that the devs put it on the backburner. Anyways, works great besides that.

Last edited by AndrewSmart (2019-06-13 22:43:15)

Offline

Board footer

Powered by FluxBB