Bonus Challenge (secondary challenge)!!

All I wanted to do was run a Live Linux distro off a USB drive and ...

Mint Linux Live USB

Just kept failing on the second boot. Rewrote the disk from scratch three times and each time would get a single successful boot :(

Xubuntu Linux Live USB

Booted every time and seemed ideal accept the Wifi drivers wouldn't load and I needed internet access :(

Gentoo Linux Live USB (desktop edition)

Booted quickly and an onscreen keyboard was shown. Dismissed that and got a standard login screen for a user gentoo .

What's the password?

... and now it really begins ...

Googling the answer turns up this Reddit post

Which has the following suggestions

• live
• moo123
• gentoo
• and my favourite, a Google link to googling for the password

None of these worked, and I tried gentoo a number of times before I tried changing the password in a separate terminal.

CTRL + ALT + F1

Got me a terminal where I could run

passwd

and I tried to change the password to gentoo , but got rebuffed for the password being too simple.

so I tried

sudo passwd gentoo

and I tried to change the password to gentoo , but got rebuffed for the password being too simple.

Hang on a mo. As root I should be able to change anyone's password to anything!

So began the fixing stage of this challenge.

change the policy file

euse -D passwdqc -p sys-auth/pambase

Didn't produce any errors and I could run passwd and enter a simple password, Hooray!

Not too fast! Although the password change was successful I couldn't login with it :(

so I followed the instructions in passwd and used "Moon!Rent$agent" and it worked

I then had to go through that palaver every time I rebooted the live USB, grrr

When I am root I do not expect to be treated like this!

CTRL + ALT + F7

to get back to the GUI login.

Bonus Challenge!!

Old 256Gb drive kept getting filled up. Company supplied me with a 512Gb replacement.

Booted in to Gentoo Live USB and saw new drive was unformatted(*).

(*) Except by the end of this you will realise that wasn't completely wiped clean.

Copied the drive, swapped over the drives.

Booted the new drive and checked everything still worked, knowing the disk size would not update.

Booted again into Gentoo live and ran KDE partition manager ('cos the live USB was all KDE themed).

This showed all the partitions and that the drive was 477Gb (close enough), but there were no options to resize anything, there were no visible indications that any free space existed :(

Tried to install Gparted to find it was already installed :D

But when Gparted was ran it only showed a single ZFS rloop partition. No sign of any free space

I eventually found that the previous drive owner had left ZFS "bits" on the drive and Gparted couldn't see beyond them.

This forum post covered what I needed.

wipefs will not "wipe" your file system, if you are careful!

wipefs -n /dev/nvme0n1 | grep rpool

Showed not one or two ZFS "bits" but 31!!

I am not trying to type in 31 complex hex offset values and just hoping I don't make a mistake.

Time for some bash scripting...

wipefs -n /dev/nvme0n1 | grep rpool | grep -Eo "[ ]0x[^ ]+" | sed -re "s/^/wipefs -o /" | sed -re "s/$/ \/dev\/nvme0n1/"

Gets all the rpool items, extracts the hex offset and then replaces the front of the line with the wipe -o command and the end with the the device root /dev/nvme0n1

Which spat out this lot, which was easy to copy and paste

wipefs -o  0x773c23f000 /dev/nvme0n1
wipefs -o  0x773c23e000 /dev/nvme0n1
wipefs -o  0x773c23d000 /dev/nvme0n1
wipefs -o  0x773c23c000 /dev/nvme0n1
wipefs -o  0x773c23b000 /dev/nvme0n1
wipefs -o  0x773c23a000 /dev/nvme0n1
wipefs -o  0x773c239000 /dev/nvme0n1
wipefs -o  0x773c238000 /dev/nvme0n1
wipefs -o  0x773c237000 /dev/nvme0n1
wipefs -o  0x773c236000 /dev/nvme0n1
wipefs -o  0x773c235000 /dev/nvme0n1
wipefs -o  0x773c234000 /dev/nvme0n1
wipefs -o  0x773c233000 /dev/nvme0n1
wipefs -o  0x773c232000 /dev/nvme0n1
wipefs -o  0x773c231000 /dev/nvme0n1
wipefs -o  0x773c230000 /dev/nvme0n1
wipefs -o  0x773c22f000 /dev/nvme0n1
wipefs -o  0x773c22e000 /dev/nvme0n1
wipefs -o  0x773c22d000 /dev/nvme0n1
wipefs -o  0x773c22c000 /dev/nvme0n1
wipefs -o  0x773c22b000 /dev/nvme0n1
wipefs -o  0x773c22a000 /dev/nvme0n1
wipefs -o  0x773c229000 /dev/nvme0n1
wipefs -o  0x773c228000 /dev/nvme0n1
wipefs -o  0x773c227000 /dev/nvme0n1
wipefs -o  0x773c226000 /dev/nvme0n1
wipefs -o  0x773c225000 /dev/nvme0n1
wipefs -o  0x773c224000 /dev/nvme0n1
wipefs -o  0x773c223000 /dev/nvme0n1
wipefs -o  0x773c222000 /dev/nvme0n1
wipefs -o  0x773c221000 /dev/nvme0n1
wipefs -o  0x773c220000 /dev/nvme0n1

Gparted refreshed, showed correct partitions and FREE SPACE

and there is just time for a secondary Bonus Challenge ... about Gentoo's Live USB

A new bigger drive for my work Linux laptop!!

Had a 256Gb drive and kept running out of space. Database back ups, Docker images, Snap packages etc.

They kindly sent me a 512Gb drive in a cute M.2 USB enclosure.

Challenge 1. cannot get my Gentoo live USB to boot.

Fix: disable Secure Boot in the BIOS (had to do this Every time I needed to boot the live USB)

I ran dd with an 8Mb block size on the new unformatted USB drive

dd bs=8M if=/dev/original-small-drive of=/dev/new-bigger-drive

from one drive to the other and shut everything down and physically swapped over the drives in the laptop.

Challenge 2. cannot get the new drive to boot.

Fix: re-enable Secure Boot in the BIOS (had to do this Every time I needed to boot the M.2 system drive)

Would it boot now? Yes, and as expected the drive still showed as 256Gb

OK, now to resize it.

Bonus Challenge : this will be its own separate post and I doubt anyone else will encounter it, but different partition managers were telling me different things at this point*

Tried a few thousand commands from various blogs and forums and although nothing was breaking the disk, it was stubbornly staying at 256Gb

Challenge 3. realising that it is a LUKS volume and it's Encrypted.

Fix: Add "crypt" to all Google searches

which led to a post extend-a-luks-encrypted-partition-to-fill-disk , which sounds about right :)

and to an answer with this amazingly detailed guide , including lots of screenshots.

I followed it religiously and it all seemed to work...

Except the

sudo resize2fs -p /dev/mapper/vgubuntu-root`

command reported that nothing had changed...

Undeterred, I rebooted and found ... the disk was still reporting 256Gb , but now it was also showing the encrypted partition as 512Gb .

Making progress!

Back to the post extend-a-luks-encrypted-partition-to-fill-disk and reread detailed guide

I couldn't see anywhere I had gone wrong so I looked at another answer on the page

add followed just a few of the steps after unlocking the encrypted partition in Gparted .

pvresize /dev/nvme0n1p3_crypt

lvresize -l+100%FREE /dev/mapper/vgubuntu-root

e2fsck -f /dev/mapper/mapper/vgubuntu-root

resize2fs /dev/mapper/mapper/vgubuntu-root

OM the Gs! that last command said it DID change something ...

reboot and ... It worked! Finally I had 512Gb (minus the boot partition, some swap and some overfit)

Stay tuned for the *Bonus Challenge which was all about ZFS