Posts by MangoCats

I've actually gotten pretty far with the above by copying the Estuary skin to a new name, then ssh-ing in to the new skin and blowing away the stuff I don't want (using the above keymap to help get around on the skin side) - a lot of things I didn't want got turned off in Settings, then Settings itself isn't accessible (other than through the temporary keymap) due to the removals of settings access points in the skin.

This is definitely more of a one-off project than something easily bundled to ship for others to use, but for people who can get around an ssh connection and edit xml files, it's not too hard to do.

So, with a combination of settings, skin removals, node removals, and keymap mods I think it's fully secured. Time will tell.

Help I got from the Kodi forums is in this thread: https://forum.kodi.tv/showthread.php?tid=376699

So, basically I'm starting here: https://kodi.wiki/view/HOW-TO:Es…nt_for_skinning and ripping out everything that can cause trouble. The only real trick I've turned is in the keymap.xml:

<keymap>
   <global>
       <keyboard>
           <F5>ReloadSkin()</F5>
           <F7>ActivateWindow(settings)</F7>
           <F8>Skin.ToggleDebug()</F8>
       </keyboard>
   </global>
</keymap>

that way I can use F7 to get back to Settings and reload the original skin if I ever mess up too bad. Then, when I've got it fully locked down I can remove the keymap.xml and the thing is locked, and if I ever want to get back in and modify it, I can ssh in, replace keymap.xml, F7 and switch to the original Estuary skin to do whatever I need to do.

Quote from tokul

"Write to device and not to partition."

You probably won't like my answer about what was lacking in dd command. There is nothing wrong with writing images using dd command on Linux.

Your answer was apparently on hold while I was writing my "what's missing" question. I did mark your reply as "best answer" when I saw it.

I have been using Linux off and on since 1996 - using it as my personal "daily driver" and work environment since 2013. I knew that bit about "device not partition" long ago, but haven't used that knowledge in the last 5 or so years, so I messed it up and the simple GUI app was a quicker fix for me than dredging the less user friendly knowledge out of my brain. Thanks for the refresher... I'm sure I'll forget again by 2029 if I don't keep using it in the meantime.

Back around 2014 I did a lot of work with dd, and I guess what I would say dd is lacking is user friendliness. It's a very powerful tool which kind of invites misuse by people who don't know exactly what they're doing. The GUI apps, by comparison, either don't offer as many options, or the better ones bury the less commonly used options where they aren't accidentally used by novices. I was suspecting there was some kind of flag to set somewhere to make an image bootable when burned to the device, which is why I ended up asking for help on the forum because "man dd" doesn't mention any such flag option, because that's not how it actually works.

Quote from chewitt

a GUI for command-line-phobic users, which is probably 80%+ of our userbase

Agreed.

Thanks... in this environment I'd like to avoid power cycles, but it's definitely a step in the right direction to be able to reset using them. Reddit has a lot of questions around kiosk mode for Kodi, but the answers sort of vaguely point at the Aeon Nox skin and don't seem to get "all the way there..."

It feels like the missing piece is requiring a password to take the skin out of Basic mode - is that really a difficult thing for a developer to do? It wouldn't have to be a high security password, having the secret defined in a config file would be enough, and for my use case even having a standard password in the distro, something like: "letmein", would do the job.

I am putting a(nother) LibreELEC media server on RaspberryPi5 into a "configuration meddling hostile environment"... the one that went there first has had the file selection menus all messed up and some configurations changed that shouldn't have been...

Are there any guides out there for how to lock down the system so that the users can browse, select and play the onboard media, but otherwise not manipulate the configurations in any way without a password?

Thanks! I tried Ubuntu's "Startup Disk Creator" - after burning the LibreELEC image on the SD card it told me I could "Use the device to boot Ubuntu on any machine," but... obviously, it actually worked to burn the LibreELEC image:

First try, easy peasy, first boot resized the partition automatically.

If anybody knows, I'd be curious: what does SDC, Balena, Rufus, etc. have that dd lacks?

I have a new SD card: SanDisk 512GB Extreme microSDXC UHS-I Memory Card

That I want to put LibreELEC on for use in a Raspberry Pi 5. The "easily accessible" computer I am typing this from has Ubuntu 20.04.

I downloaded: LibreELEC-RPi5.arm-11.0.6.img.gz, inserted the SD card into my Ubuntu machine, then did the following:

$ gzip -d LibreELEC-RPi5.arm-11.0.6.img.gz
$ lsblk
...
sda           8:0    1 476.7G  0 disk 
└─sda1        8:1    1 476.7G  0 part /media/mike/3731-3564
...
$ sudo dd if=LibreELEC-RPi5.arm-11.0.6.img of=/dev/sda1 bs=4M
137+1 records in
137+1 records out
575668224 bytes (576 MB, 549 MiB) copied, 0.425209 s, 1.4 GB/s

Then I (first soft then hard) ejected the SD card, inserted it into the RPi5, powered it on, and got this:

What might I be missing?