Lerking/rpi-clone
1
0
Fork 0
Code Issues 129 Pull Requests 10 Packages Projects Releases Wiki Activity

Update RPi OS logic detection #152

Open
martignoni wants to merge 3 commits from martignoni/151-rpios into master
pull from: martignoni/151-rpios
merge into: Lerking:master
Conversation 21 Commits 3 Files Changed 1 +15 -18
martignoni commented 2023-01-15 19:59:24 +01:00 (Migrated from github.com)
Copy Link
- Fixes #151.
martignoni commented 2023-01-15 20:01:45 +01:00 (Migrated from github.com)
Copy Link

Should work with Bookworm (and hopefully later Debian versions).

Should work with Bookworm (and hopefully later Debian versions).
framps (Migrated from github.com) reviewed 2023-01-16 13:35:13 +01:00
rpi-clone
framps (Migrated from github.com) commented 2023-01-16 13:34:32 +01:00
Copy Link

As far as I see this test should check whether it's a Raspberry HW. Are you sure /proc/device-tree/model is an unique idetifier for a Raspberry HW? /etc/rpi-issue exists on Raspberry OS Builds only.

As far as I see this test should check whether it's a Raspberry HW. Are you sure /proc/device-tree/model is an unique idetifier for a Raspberry HW? `/etc/rpi-issue` exists on Raspberry OS Builds only.
framps (Migrated from github.com) commented 2023-01-16 13:35:07 +01:00
Copy Link

I like this check for the osversion 👍

I like this check for the osversion :+1:
martignoni (Migrated from github.com) reviewed 2023-01-16 15:26:56 +01:00
rpi-clone
martignoni (Migrated from github.com) commented 2023-01-16 15:26:55 +01:00
Copy Link

Thanks, normally, it should work with later versions of Debian.

Thanks, normally, it should work with later versions of Debian.
martignoni (Migrated from github.com) reviewed 2023-01-16 15:26:59 +01:00
rpi-clone
martignoni (Migrated from github.com) commented 2023-01-16 15:26:59 +01:00
Copy Link

I'm rather sure, but your proposition with /etc/rpi-issue is cleaner and easier to understand, I'll change.

I'm rather sure, but your proposition with `/etc/rpi-issue` is cleaner and easier to understand, I'll change.
gpongelli commented 2023-03-05 18:44:01 +01:00 (Migrated from github.com)
Copy Link

hi @martignoni , I was looking to your changes , I've tried them manually and osversion in my case is empty.

those are the result from my raspberry

pi@raspberrypi:~ $ cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.2
 
pi@raspberrypi:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux bookworm/sid"
NAME="Raspbian GNU/Linux"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@raspberrypi:~ $ cat /etc/rpi-issue 
Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5

as you can see, the /etc/os-version misses the VERSION_ID field .

With the original code, at least the "raspbian" variable is set to 1.

hi @martignoni , I was looking to your changes , I've tried them manually and `osversion` in my case is empty. those are the result from my raspberry ```bash pi@raspberrypi:~ $ cat /proc/device-tree/model Raspberry Pi 4 Model B Rev 1.2 pi@raspberrypi:~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux bookworm/sid" NAME="Raspbian GNU/Linux" VERSION_CODENAME=bookworm ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" pi@raspberrypi:~ $ cat /etc/rpi-issue Raspberry Pi reference 2019-09-26 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5 ``` as you can see, the `/etc/os-version` misses the `VERSION_ID` field . With the original code, at least the "raspbian" variable is set to 1.
martignoni commented 2023-03-05 21:33:18 +01:00 (Migrated from github.com)
Copy Link

Hi @gpongelli,

You'll see that in your case the rpios variable (which replaces variable raspbian) is correctly set to 1.

What you describe is not a problem, since osversion is only used to detect recent versions of RPiOS.

In your case, you've an older release, there's no VERSION_ID in your /etc/os-release, so osversion is empty; the comparison on line 38 evaluates to false, so rpios_recent=0 and your older release is adequately detected.

Recent versions of RPiOS all have a VERSION_ID in their /etc/os-release, so in this case the comparison on line 38 evaluates correctly to true.

Hi @gpongelli, You'll see that in your case the `rpios` variable (which replaces variable `raspbian`) is correctly set to `1`. What you describe is not a problem, since `osversion` is only used to detect **recent versions** of RPiOS. In your case, you've an older release, there's no `VERSION_ID` in your `/etc/os-release`, so `osversion` is empty; the comparison on line 38 evaluates to `false`, so `rpios_recent=0` and your older release is adequately detected. Recent versions of RPiOS all have a `VERSION_ID` in their `/etc/os-release`, so in this case the comparison on line 38 evaluates correctly to `true`.
gpongelli commented 2023-03-06 09:50:54 +01:00 (Migrated from github.com)
Copy Link

Hi @martignoni , I’ve no idea what’s “recent” for you but, as you can see I’m on bookworm, that’s the actual testing release.

I’ve tried today to upgrade (again) over testing and the os-release had not changed.

Hi @martignoni , I’ve no idea what’s “recent” for you but, as you can see I’m on bookworm, that’s the actual testing release. I’ve tried today to upgrade (again) over testing and the os-release had not changed.
martignoni commented 2023-03-06 13:36:02 +01:00 (Migrated from github.com)
Copy Link

There is a misunderstanding here: I'm speaking of recent releases of RPiOS images.

And my bad: I did not notice that your image was upgraded. For the record, upgrading an RPi image to a new OS version is not recommended and not supported. I assume rpi-clone too is not supported in these cases.

Side note: Debian testing versions never have a VERSION_ID defined.

There is a misunderstanding here: I'm speaking of recent releases of **RPiOS images**. And my bad: I did not notice that your image was upgraded. For the record, upgrading an RPi image to a new OS version [is not recommended](https://www.raspberrypi.com/documentation/computers/os.html#upgrading-from-previous-operating-system-versions) and not supported. I assume `rpi-clone` too is not supported in these cases. Side note: Debian testing versions never have a `VERSION_ID` defined.
gpongelli commented 2023-03-06 19:58:29 +01:00 (Migrated from github.com)
Copy Link

There is a misunderstanding here: I'm speaking of recent releases of RPiOS images.

And my bad: I did not notice that your image was upgraded. For the record, upgrading an RPi image to a new OS version is not recommended and not supported. I assume rpi-clone too is not supported in these cases.

Even if it’s not recommended, it can be done (and it worked, waiting for official bookworm), so why rpi-clone shouldn’t also be supported ?

> There is a misunderstanding here: I'm speaking of recent releases of **RPiOS images**. > > And my bad: I did not notice that your image was upgraded. For the record, upgrading an RPi image to a new OS version [is not recommended](https://www.raspberrypi.com/documentation/computers/os.html#upgrading-from-previous-operating-system-versions) and not supported. I assume `rpi-clone` too is not supported in these cases. > Even if it’s not recommended, it can be done (and it worked, waiting for official bookworm), so why rpi-clone shouldn’t also be supported ?
martignoni commented 2023-03-06 22:25:05 +01:00 (Migrated from github.com)
Copy Link

If you find a way to check for a version number in Debian testing release, I'd be glad to include it in this PR.

If you find a way to check for a version number in Debian testing release, I'd be glad to include it in this PR.
framps commented 2023-03-07 00:12:59 +01:00 (Migrated from github.com)
Copy Link

Not sure what's the purpose of this check. Maybe it's worth to remove this check?

Not sure what's the purpose of this check. Maybe it's worth to remove this check?
martignoni commented 2023-03-07 11:47:26 +01:00 (Migrated from github.com)
Copy Link

This is needed because as of RPiOS Buster (and later), the boot partition size has changed. See 07f536e9d9/rpi-clone (L1348-L1356) and 07f536e9d9/rpi-clone (L1609-L1624).

This is needed because as of RPiOS Buster (and later), the boot partition size has changed. See https://github.com/billw2/rpi-clone/blob/07f536e9d93cb5b50635415ee0fa46f498614ee4/rpi-clone#L1348-L1356 and https://github.com/billw2/rpi-clone/blob/07f536e9d93cb5b50635415ee0fa46f498614ee4/rpi-clone#L1609-L1624.
👍 1
gpongelli commented 2023-03-12 19:44:00 +01:00 (Migrated from github.com)
Copy Link

Hi @martignoni , I've just tested rpi-clone on my rpi and it worked correctly.

The only changes I did had been this one here:


	if ((raspbian)) && [[ "$pretty" == *"buster"* ]]
	then
		raspbian_buster=1
	fi
+	if ((raspbian)) && [[ "$pretty" == *"bookworm"* ]]
+	then
+		raspbian_buster=1
+	fi

this because there's no way to get version 11 with any of following methods:

  • lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux bookworm/sid
Release:	n/a
Codename:	bookworm
  • cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux bookworm/sid"
NAME="Raspbian GNU/Linux"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
  • hostnamectl
 Static hostname: ...
       Icon name: computer
      Machine ID:....
         Boot ID: ....
Operating System: Raspbian GNU/Linux bookworm/sid 
          Kernel: Linux 5.15.84-v7l+
    Architecture: arm
Hi @martignoni , I've just tested rpi-clone on my rpi and it worked correctly. The only changes I did had been this one [here](https://github.com/billw2/rpi-clone/blob/master/rpi-clone#L39): ```diff if ((raspbian)) && [[ "$pretty" == *"buster"* ]] then raspbian_buster=1 fi + if ((raspbian)) && [[ "$pretty" == *"bookworm"* ]] + then + raspbian_buster=1 + fi ``` this because there's no way to get version 11 with any of following methods: - `lsb_release -a` ``` No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux bookworm/sid Release: n/a Codename: bookworm ``` - `cat /etc/os-release` ``` PRETTY_NAME="Raspbian GNU/Linux bookworm/sid" NAME="Raspbian GNU/Linux" VERSION_CODENAME=bookworm ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" ``` - `hostnamectl` ``` Static hostname: ... Icon name: computer Machine ID:.... Boot ID: .... Operating System: Raspbian GNU/Linux bookworm/sid Kernel: Linux 5.15.84-v7l+ Architecture: arm ```
martignoni commented 2023-03-12 21:18:32 +01:00 (Migrated from github.com)
Copy Link

Your "fix" would not fix the bug: the problem will occur again when Debian reaches its next version after Bookworm.

Your "fix" would not fix the bug: the problem will occur again when Debian reaches its next version after Bookworm.
framps commented 2023-03-12 21:46:02 +01:00 (Migrated from github.com)
Copy Link

Agree. Then every new Debian version requires a change in rpi-clone. Wouldn't it make sense to test backwards and not forwards?

Agree. Then every new Debian version requires a change in rpi-clone. Wouldn't it make sense to test backwards and not forwards?
gpongelli commented 2023-03-13 08:20:06 +01:00 (Migrated from github.com)
Copy Link

I know it is not future-proof, but it’s just to demonstrate that rpi-clone works also on upgraded rpi (even not so pure raspbian, because in the past I’ve mixed it with Debian due to more recent sw version needed).

agree with @framps about reversing the detection logic

edit:
To address future boot changes other than the one already in place (or any os changes that impacts rpi-clone), a more correct check could be done parsing history/release table in webpages like this one or this one through an external script.

I know it is not future-proof, but it’s just to demonstrate that rpi-clone works also on upgraded rpi (even not so pure raspbian, because in the past I’ve mixed it with Debian due to more recent sw version needed). agree with @framps about reversing the detection logic edit: To address future boot changes other than the one already in place (or any os changes that impacts rpi-clone), a more correct check could be done parsing history/release table in webpages like [this one](https://wiki.debian.org/DebianReleases) or [this one](https://en.m.wikipedia.org/wiki/Debian_version_history) through an external script.
framps commented 2023-03-13 10:56:52 +01:00 (Migrated from github.com)
Copy Link

a more correct check could be done parsing history/release table in webpages

I agree. That's the more general approach. But this creates a dependency of rpi-clone on an existing network connection I don't like.

> a more correct check could be done parsing history/release table in webpages I agree. That's the more general approach. But this creates a dependency of rpi-clone on an existing network connection I don't like.
martignoni commented 2023-03-13 12:58:00 +01:00 (Migrated from github.com)
Copy Link

Wouldn't it make sense to test backwards and not forwards?

Not sure I understand, can you elaborate?

> Wouldn't it make sense to test backwards and not forwards? Not sure I understand, can you elaborate?
framps commented 2023-03-13 13:20:31 +01:00 (Migrated from github.com)
Copy Link

As @gpongelli wrote here he added a new if statement to set raspibian_buster. This will have to be done for every new release. Why don't we just negate the test and assume raspbian_buster is 1 and reset it to zero for older releases. They will not change any more 😉

As @gpongelli wrote [here ](https://github.com/billw2/rpi-clone/pull/152#issuecomment-1465270895) he added a new if statement to set raspibian_buster. This will have to be done for every new release. Why don't we just negate the test and assume raspbian_buster is 1 and reset it to zero for older releases. They will not change any more :wink:
👍 1
martignoni commented 2023-03-15 12:50:34 +01:00 (Migrated from github.com)
Copy Link

Here are the PRETTY_NAMEs for all Raspbian/RPiOS supported releases:

32bit

PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"

64bit

PRETTY_NAME="Debian GNU/Linux 10 (buster)"
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

For (unsupported) testing/sid releases, the PRETTY_NAME does not have any number and no VERSION_ID, as already said before. A few examples (we cannot exclude that some adventurous rpi-clone user has updated their official RPiOS buster version to a testing bullseye one):

32bit

PRETTY_NAME="Raspbian GNU/Linux bookworm/sid"
PRETTY_NAME="Raspbian GNU/Linux bullseye/sid"

64bit

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
PRETTY_NAME="Debian GNU/Linux bookworm/sid"

We can conclude that for the test to work also for unsupported versions, we've to test whether the PRETTY_NAME contains either "wheezy", "jessie" or "stretch", and conclude that in this case this is not a recent version.

This (not as elegant as actual PR) bit of code would work. Any comment welcome: bash is not my first language 😊

rpios=0
rpios_recent=0
if [ -f /etc/os-release ]
then
  osversion=`cat /etc/os-release | grep PRETTY | cut -d'"' -f2`
  osversion=${osversion##* } # Remove everything before last space
  osversion=`echo ${osversion} | cut -d"(" -f2 | cut -d")" -f1` # Remove parens if needed
  osversion=${osversion%/*} # Remove everything after last slash
  if [[ -e /etc/rpi-issue ]]; then
    rpios=1
  fi
  if ((rpios)) && !([[ "${osversion}" = "wheezy" ]] || [[ "${osversion}" = "jessie" ]] || [[ "${osversion}" = "stretch" ]] ); then
    rpios_recent=1
  fi
fi
Here are the `PRETTY_NAME`s for all Raspbian/RPiOS **supported** releases: #### 32bit PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)" PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)" PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" #### 64bit PRETTY_NAME="Debian GNU/Linux 10 (buster)" PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" For **(unsupported) testing/sid** releases, the `PRETTY_NAME` does not have any number and no `VERSION_ID`, as already said before. A few examples (we cannot exclude that some adventurous `rpi-clone` user has updated their official RPiOS buster version to a testing bullseye one): #### 32bit PRETTY_NAME="Raspbian GNU/Linux bookworm/sid" PRETTY_NAME="Raspbian GNU/Linux bullseye/sid" #### 64bit PRETTY_NAME="Debian GNU/Linux bullseye/sid" PRETTY_NAME="Debian GNU/Linux bookworm/sid" We can conclude that for the test to work also for unsupported versions, we've to test whether the `PRETTY_NAME` contains either "wheezy", "jessie" or "stretch", and conclude that in this case this is not a recent version. This (not as elegant as actual PR) bit of code would work. Any comment welcome: `bash` is not my first language 😊 ``` rpios=0 rpios_recent=0 if [ -f /etc/os-release ] then osversion=`cat /etc/os-release | grep PRETTY | cut -d'"' -f2` osversion=${osversion##* } # Remove everything before last space osversion=`echo ${osversion} | cut -d"(" -f2 | cut -d")" -f1` # Remove parens if needed osversion=${osversion%/*} # Remove everything after last slash if [[ -e /etc/rpi-issue ]]; then rpios=1 fi if ((rpios)) && !([[ "${osversion}" = "wheezy" ]] || [[ "${osversion}" = "jessie" ]] || [[ "${osversion}" = "stretch" ]] ); then rpios_recent=1 fi fi ```
framps commented 2023-03-15 13:34:40 +01:00 (Migrated from github.com)
Copy Link

I like regex 😄

rpios=0
rpios_recent=0

if [[ -f /etc/os-release ]]; then
   if [[ -f /etc/rpi-issue ]]; then
      rpios=1
   fi
   pretty="$(grep PRETTY /etc/os-release)"
   if ((rpios)) && [[ ! "$pretty" =~ wheezy|jessie|stretch ]]; then
      rpios_recent=1
   fi
fi
I like regex :smile: ``` rpios=0 rpios_recent=0 if [[ -f /etc/os-release ]]; then if [[ -f /etc/rpi-issue ]]; then rpios=1 fi pretty="$(grep PRETTY /etc/os-release)" if ((rpios)) && [[ ! "$pretty" =~ wheezy|jessie|stretch ]]; then rpios_recent=1 fi fi ```
👍 1
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin martignoni/151-rpios:martignoni/151-rpios
git checkout martignoni/151-rpios
Sign in to join this conversation.
Reviewers
No Reviewers
framps
martignoni
Labels
Clear labels
bug
duplicate
enhancement
invalid
question
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Lerking
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Lerking/rpi-clone#152
Delete Branch "martignoni/151-rpios"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?