Debian buster (10) image 1.0 released for B3

[shadowbox]

Has anyone tried this image with B2? (Or does anyone know why it wouldn't work with B2)?

And if it won't, are there other recommended options?

[MouettE]

Has anyone tried this image with B2? (Or does anyone know why it wouldn't work with B2)?

And if it won't, are there other recommended options?

Debian dropped PowerPC support since stretch (version 9). The last debian version available for the B2 is jessie (8) still available here : https://forum.excito.com/viewtopic.php?f=7&t=5871 . However it's not maintained anymore. The more recent (2018) system available is the gentoo port done by sakaki-, it's available here https://forum.excito.com/viewtopic.php?f=7&t=6366

[shadowbox]

Thanks, MouetteE.

Guess I'll be looking for a Bubba replacement, then. Too bad. This was a good little unit for 12 years. Cheap, quiet and cold.

[MouettE]

After reading a bit online, there is a powerpc port of current unstable debian tree. I can try to build an image based on this tree, if you are willing to wait a little and run sid on your b2

[shadowbox]

I would be most grateful. I've migrated all essential data from the machine, ready to mostly decommission out of security vulnerability. And life you might breath into it would be welcomed.

[MouettE]

Quick update, I have made good progress on the debian unstable port for the B2. The install/rescue system has been updated, I have a working 5.4 kernel and I'm currently building the image. We should have something working in the next couple of days.

[audiohd]

Hi, I have my B3 since 2011 and have been using it since. This week I replaced the 2TB hdd with a Samsung 500gb SSD.

Then I installed Buster and have been working with the configuration for many hours. I am not completely new to Linux
but have been more into Windows for many years. Anyway now my B3 works greater then ever and I really like to send
many thanks to MouettE!

Three times I made mistakes with fstab during installations so the machine did not boot. My only secure way to solve
this was to take out the ssd disk and mount it in another computer.

Is it possible to create a bootable "rescue live usb stick" with Debian Buster to boot with and reach the internal disk to
make changes?

Thanks again from Sweden!

[MouettE]

Then I installed Buster and have been working with the configuration for many hours. I am not completely new to Linux
but have been more into Windows for many years. Anyway now my B3 works greater then ever and I really like to send
many thanks to MouettE!

Thanks for your message. It's a great reward for all of us who work on those new images (the buster image would not exist without the work of sakaki and Gordon on the other images) to know that they are used. B3 is old but dead solid and reliable !

Is it possible to create a bootable "rescue live usb stick" with Debian Buster to boot with and reach the internal disk to
make changes?

You can use the install image as a rescue live usb by editing the install.ini file and removing or commenting the [general] section along with its parameters (install and wipe). The key will boot and open an ssh server on which you can connect. Once connected you can mount the internal disk and fix stuff. The rescue system is not a live debian per say but should provide all the tools you need. You can also use the other live-usb systems systems available in this section.

[audiohd]

Hi again, thanks for the fast feedback and thanks for the instructions about how to create a usb-stick that do not wipe my internal ssd. I was rather sure that it is no rocket science to create one but I had not the courage to experiment by myself.

IF anyone reading this post, feel free to ask questions about my trial and error installation. I have documented the main parts and have other stuff in my head for the moment, stuff like Swedish layout (with åäö) and my fstab that mount two external drives (one ntfs 4TB hdd and one 238GB ssd) but only IF the are turned on during the boot process, exactly as I like to.

Today my b3 only works as a file server for media and I detached the two antenna cables when the machine was open.
Our LAN have two Dovado routers today with 2,4 and 5ghz wifi and a e3276 huawei modem with 4g. Our new antenna
mounted at our roof also is prepared for 5g.

Now maybe my loved B3 will serve the family for another 9 years!


Thanks again!
/Peter

[philgaskin]

Firstly, I must say excellent work on the continued development of distributions to keep my B3 going.
I just tried installing the Buster 10 image 1.0 on my B3 with a 500GB WD green drive - at this stage just to refamiliarise myself with unix but with the hope to setup a more up-to-date file, media and intranet server.

I followed the instructions to the letter (many times). The installation seems to go well each time but when I login I see the same issue that @guyran reported where /etc and /usr are owned by the excito user. Now I can change this recursively with chown and chgrp but the more worrying part is the list of mounted filesystems includes a /run and /run/lock (and others I wasn't expecting) which appear to stop lvm2 from working properly and detecting my storage partition. I've tried different USB sticks and reformatted the disk etc but I always get this result.

When I try apt-get upgrade, I get the same canonicalisation errors as @guyran reported which also point to /run and /run/lock. I tried the additional steps covered by @jcilund which was when I started to realise the issue is with these tmpfs mounts in place.

Does anyone have any suggestions?

Directory listing of /

Code: Select all

root@b3:/# ls -l
total 72
drwxr-xr-x  2 root   root    4096 Jul 10  2019 bin
drwxr-xr-x  2 root   root    4096 Jul 10  2019 boot
drwxr-xr-x 14 root   root    3560 Nov 19 09:26 dev
drwxr-xr-x 61 excito excito  4096 Nov 19 09:26 etc
drwxr-xr-x  3 root   root    4096 Jul 10  2019 home
drwxr-xr-x 12 root   root    4096 Jul 10  2019 lib
drwx------  2 root   root   16384 Jul 10  2019 lost+found
drwxr-xr-x  2 root   root    4096 Jul 10  2019 media
drwxr-xr-x  2 root   root    4096 Jul 10  2019 mnt
drwxr-xr-x  2 root   root    4096 Jul 10  2019 opt
dr-xr-xr-x 76 root   root       0 Jan  1  1970 proc
drwx------  2 root   root    4096 Jul 10  2019 root
drwxr-xr-x 13 root   root     440 Nov 19 09:27 run
drwxr-xr-x  2 root   root    4096 Jul 10  2019 sbin
drwxr-xr-x  2 root   root    4096 Jul 10  2019 srv
dr-xr-xr-x 11 root   root       0 Nov 19 09:26 sys
drwxrwxrwt  3 root   root    4096 Nov 19 09:27 tmp
drwxr-xr-x 10 excito excito  4096 Dec  4  2015 usr
drwxr-xr-x 11 root   root    4096 Jul 10  2019 var

Mounted filesystems

Code: Select all

root@b3:/# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root       10255672 551920   9179464   6% /
devtmpfs          255232      0    255232   0% /dev
tmpfs             255332      0    255332   0% /dev/shm
tmpfs             255332   3464    251868   2% /run
tmpfs               5120      0      5120   0% /run/lock
tmpfs             255332      0    255332   0% /sys/fs/cgroup
tmpfs              51064      0     51064   0% /run/user/1000

Extract from apt-get upgrade

Code: Select all

Setting up systemd (241-7~deb10u4) ...
Detected unsafe path transition / → /run during canonicalization of /run.
Detected unsafe path transition / → /run during canonicalization of /run/lock.
Detected unsafe path transition / → /run during canonicalization of /run.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd.
Detected unsafe path transition / → /run during canonicalization of /run/systemd/netif.
Detected unsafe path transition / → /run during canonicalization of /run/systemd/netif.
Detected unsafe path transition / → /run during canonicalization of /run.
Detected unsafe path transition / → /var during canonicalization of /var.
Detected unsafe path transition / → /var during canonicalization of /var/lib.
Detected unsafe path transition / → /var during canonicalization of /var/lib/systemd.
Detected unsafe path transition / → /var during canonicalization of /var/lib.
Detected unsafe path transition / → /var during canonicalization of /var.
Detected unsafe path transition / → /var during canonicalization of /var/log.
Detected unsafe path transition / → /var during canonicalization of /var.
Detected unsafe path transition / → /var during canonicalization of /var/cache.
Detected unsafe path transition / → /var during canonicalization of /var/log.
Detected unsafe path transition / → /var during canonicalization of /var/log.
Detected unsafe path transition / → /var during canonicalization of /var/log.
Detected unsafe path transition / → /var during canonicalization of /var.
Detected unsafe path transition / → /run during canonicalization of /run/log/journal.
Detected unsafe path transition / → /run during canonicalization of /run/log/journal/a56c18e486df4351a49d7a9ade410162.
Detected unsafe path transition / → /run during canonicalization of /run/log/journal/a56c18e486df4351a49d7a9ade410162.
Detected unsafe path transition / → /run during canonicalization of /run/log/journal/a56c18e486df4351a49d7a9ade410162/system.journal.

[MouettE]

I followed the instructions to the letter (many times). The installation seems to go well each time but when I login I see the same issue that @guyran reported where /etc and /usr are owned by the excito user. Now I can change this recursively with chown and chgrp but the more worrying part is the list of mounted filesystems includes a /run and /run/lock (and others I wasn't expecting) which appear to stop lvm2 from working properly and detecting my storage partition. I've tried different USB sticks and reformatted the disk etc but I always get this result.

/etc and /usr (and some but not all directories below) are indeed owned by the excito user instead of root. I just understood why, I will fix the issue and release a new version of the image. I will also do some tests regarding apt-get and upgrade issues and keep you posted

[MouettE]

While I build a new version (it will take some time) you can fix the path ownership with these commands (run as root):

Code: Select all

chown root:root /
chown root:root /etc
chown root:root /etc/systemd
chown root:root /etc/systemd/system
chown root:root /etc/systemd/system/multi-user.target.wants
chown root:root /usr
chown root:root /usr/local
chown root:root /usr/local/sbin

Note that this actually fixes the apt-upgrade errors with systemd.

[philgaskin]

Thanks @MouettE, that did the trick. I got carried away with a chown -R root:root / before!
I'm so pleased I can give my B3 a new lease of life - thank you.

As an aside, is it normal in later versions of Debian to see so many tmpfs mounts, especially the /run prefixed ones?

Code: Select all

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       9.8G  665M  8.7G   7% /
devtmpfs        250M     0  250M   0% /dev
tmpfs           250M     0  250M   0% /dev/shm
tmpfs           250M  6.6M  243M   3% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           250M     0  250M   0% /sys/fs/cgroup
/dev/sda3       448G   71M  425G   1% /home
tmpfs            50M     0   50M   0% /run/user/1001

Thanks again
Phil.

[MouettE]

I've released a new version 1.1 of the image which fixes this permission issue and includes debian 10.6 with security updates as of now.

As an aside, is it normal in later versions of Debian to see so many tmpfs mounts, especially the /run prefixed ones?

I don't really now, seems legit to me.

[Gordon]

As an aside, is it normal in later versions of Debian to see so many tmpfs mounts, especially the /run prefixed ones?

Yes. It is. As far as I know every modern distribution does it. The idea is that if the system crashes (which of course it shouldn't), when restarting it should not prevent any service to start on account of a rogue PID file that would have remained if it had been on a physical file system.