Re: Installing testing on Acer Aspire 315 [finished]

[Paul Scott]

On 5/12/24 21:30, David Wright wrote:

On Sun 12 May 2024 at 21:10:16 (-0700), Paul Scott wrote:

On 5/9/2024 1:59 PM, Charles Curley wrote:

On Thu, 9 May 2024 09:32:32 -0700 Paul Scott wrote:


The error I'm getting is during "Install base system."  The only way
I knew to save the log was with a camera. Even though I resized the
image this list apparently didn't allow the attachment. How else can
I save the log during install?

Installation logs are saved during installation to the target's
/var/log/installer/. You can save them to a USB stick after
installation is complete, or reboot and find them.

Is this possible if the base installation failed?  If so, how?

Depends on how it failed. The last three entries in the main menu
are:

   Save debug logs
   Execute a shell
   Abort the installation

You can use the first one and follow its instructions. You can use
the second, and type suitable mount/cp/umount commands to achieve
the same thing.

During the installation, if you get a shell, then

   # more /var/log/syslog

will allow you to pick over the logs, rather like less does, with
the disadvantage that you can't go backwards. If you overshoot the
lines of interest, you have to run the more command again.


This weeks version of the testing net install worked completely. Sending 
this from Thunderbird on the new system.


Thank you everyone who helped,

Paul




Cheers,
David.

Re: Installing testing on Acer Aspire 315

[David Wright]

On Sun 12 May 2024 at 21:10:16 (-0700), Paul Scott wrote:
> On 5/9/2024 1:59 PM, Charles Curley wrote:
> > On Thu, 9 May 2024 09:32:32 -0700 Paul Scott wrote:
> > 
> > > The error I'm getting is during "Install base system."  The only way
> > > I knew to save the log was with a camera. Even though I resized the
> > > image this list apparently didn't allow the attachment. How else can
> > > I save the log during install?
> > Installation logs are saved during installation to the target's
> > /var/log/installer/. You can save them to a USB stick after
> > installation is complete, or reboot and find them.
> 
> Is this possible if the base installation failed?  If so, how?

Depends on how it failed. The last three entries in the main menu
are:

  Save debug logs
  Execute a shell
  Abort the installation

You can use the first one and follow its instructions. You can use
the second, and type suitable mount/cp/umount commands to achieve
the same thing.

During the installation, if you get a shell, then

  # more /var/log/syslog

will allow you to pick over the logs, rather like less does, with
the disadvantage that you can't go backwards. If you overshoot the
lines of interest, you have to run the more command again.

Cheers,
David.

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/9/2024 1:59 PM, Charles Curley wrote:

On Thu, 9 May 2024 09:32:32 -0700
Paul Scott  wrote:


The error I'm getting is during "Install base system."  The only way
I knew to save the log was with a camera. Even though I resized the
image this list apparently didn't allow the attachment. How else can
I save the log during install?

Installation logs are saved during installation to the target's
/var/log/installer/. You can save them to a USB stick after
installation is complete, or reboot and find them.


Is this possible if the base installation failed?  If so, how?

TIA,

Paul

Re: Installing testing on Acer Aspire 315

[Charles Curley]

On Thu, 9 May 2024 09:32:32 -0700
Paul Scott  wrote:

> The error I'm getting is during "Install base system."  The only way
> I knew to save the log was with a camera. Even though I resized the
> image this list apparently didn't allow the attachment. How else can
> I save the log during install?

Installation logs are saved during installation to the target's
/var/log/installer/. You can save them to a USB stick after
installation is complete, or reboot and find them.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/2/2024 11:31 PM, Sirius wrote:

I would appreciate any thoughts or suggestions,

Check the PCI ids of your Ethernet controller. Download the kernel image
you are considering, check if any of its modules matches these ids. n

I may need to do that.  Thank you,

In the mean time, an install seemed to be working but gave an failure
error which said it would be in the log and visible on virtual terminal 4,


These only work for me after opening a shell from the installer menu. 
That's fine now that I understand. The error screen just doesn't say that.


The error I'm getting is during "Install base system."  The only way I 
knew to save the log was with a camera. Even though I resized the image 
this list apparently didn't allow the attachment. How else can I save 
the log during install?


TIA,

Paul

Re: Installing testing on Acer Aspire 315

[Max Nikulin]

On 03/05/2024 12:16, Paul Scott wrote:
I don't have linux on the machine for which I want the information.  I 
now have the driver name from Windows/Settings.


Booting a live image may help to evaluate if hardware is supported and 
to get lspci output.


Even when windows is booted, it should be possible to find 
VendorID-ProductID pairs in device properties and search on 
https://linux-hardware.org/ and other sources.

Re: Installing testing on Acer Aspire 315

[Max Nikulin]

On 04/05/2024 13:52, Paul Scott wrote:

On 5/3/2024 11:25 PM, Max Nikulin wrote:


It may happen that F4 is not F4 unless you press and hold Fn first. It 
is default on some laptops and may be changed in firmware setup.
Inst all docs say Left Alt F4 but no combination of other keys with F4 
worked.


On my laptop F4 worked as increase screen brightness 
(XF86MonBrightnessUp) out of the box. I have not tried it with Alt. That 
is why [Fn+Alt+F4] was necessary to get the action described for [Alt+F4].


Have you tried [Alt+F1] ([Fn+Alt+F1]), F2, and other F-digit keys 
instead of F4?



Obviously vt with log is not available on the stage of grub boot menu.


I don't understand that for this install case,


Due to lack of details, I am unsure at which installation stage you 
faced issues. That is why I decided to rule out the case that you stuck 
when grub boot menu appeared.

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/3/2024 11:25 PM, Max Nikulin wrote:

On 03/05/2024 13:27, Paul Scott wrote:
In the mean time, an install seemed to be working but gave an failure 
error which said it would be in the log and visible on virtual 
terminal 4, I didn't know how to get to a virtual in the installer.  
Various combinations with F4 didn't seem to work.


It may happen that F4 is not F4 unless you press and hold Fn first. It 
is default on some laptops and may be changed in firmware setup.
Inst all docs say Left Alt F4 but no combination of other keys with F4 
worked. Fortunately I was given the opportunity to execute a shell which 
showed modules not on the installation media.  I will try different iso's


Obviously vt with log is not available on the stage of grub boot menu.


I don't understand that for this install case,

Thank you,

Paul

Re: Installing testing on Acer Aspire 315

[Max Nikulin]

On 03/05/2024 13:27, Paul Scott wrote:
In the mean time, an install seemed to be working but gave an failure 
error which said it would be in the log and visible on virtual terminal 
4, I didn't know how to get to a virtual in the installer.  Various 
combinations with F4 didn't seem to work.


It may happen that F4 is not F4 unless you press and hold Fn first. It 
is default on some laptops and may be changed in firmware setup.


Obviously vt with log is not available on the stage of grub boot menu.

Re: Installing testing on Acer Aspire 315

[David]

On Fri, 3 May 2024 at 06:27, Paul Scott  wrote:
> On 5/1/2024 10:44 AM, Nicolas George wrote:
> > Paul Scott (12024-05-01):

>>>I have many installs over many years (only a few per year)..

[...]

>>> I would appreciate any thoughts or suggestions,

[...]

> In the mean time, an install seemed to be working but gave an failure
> error which said it would be in the log and visible on virtual terminal
> 4, I didn't know how to get to a virtual in the installer.  Various
> combinations with F4 didn't seem to work.

> Google didn't seem to help.

Hi, there is an official Debian Installation Guide containing a lot
of useful information.

> Can someone tell me how to get to a virtual terminal in the installer?

Due to the amount of detail in the Installation Guide, it can be hard to find
specific answers, so it's advisable to read the whole thing.

Your specific question is covered in a couple of places:

https://www.debian.org/releases/bookworm/amd64/ch06s01.en.html
(section 6.1 paragraph 10)

https://www.debian.org/releases/bookworm/amd64/ch06s03.en.html#di-miscellaneous
(section 6.3.9.2)

Also, this is a bad time to try to install the 'Testing' distribution.
It is currently undergoing major transition and might well contain
many broken/incompatible packages. See:

https://wiki.debian.org/ReleaseGoals/64bit-time
https://www.mail-archive.com/debian-devel@lists.debian.org/msg380111.html
and ongoing messages in that thread and mailing list

Re: time_t transitions in testing

[Brad Rogers]

On Fri, 03 May 2024 12:11:22 +0100
"mick.crane"  wrote:

Hello mick.crane,

>Eeeek "725 packages can be upgraded. Run 'apt list --upgradable' to see 
>them"

Quite a few here, too.  Although not as many as you had;
46 packages removed
46 packages installed (t64 versions of the packages removed)
309 packages upgraded

However..

I have noticed that GTK apps, after 'waking up' computer when screen is
powered off, don't behave nicely(1).  I use KDE Plasma for DE, in X.

I'm playing with power saving settings (i.e. turning them off) to work
around the issue (restarting each app does the necessary if that fails),
and will see if things improve over the next few days.  Lots of kde & qt
stuff has been upgraded and things may be a little 'off' on my system.

Oh, I did reboot because of the kernel and kde/qt updates.

(1)  Buttons don't respond to mouseover events, and the window displays
contents from other apps on different desktops.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
It's cool to know nothin'
Never Miss A Beat - Kaiser Chiefs


pgp837htAjaEK.pgp
Description: OpenPGP digital signature

Re: time_t transitions in testing

[songbird]

mick.crane wrote:
...
> Eeeek "725 packages can be upgraded. Run 'apt list --upgradable' to see 
> them"

  that was about where i was at as i'd been holding firefox
from unstable due to it wanting to remove a lot of Mate
packages without replacing them.

  however last night, like you, i first updated to the newest
kernel and headers and then picked groups of packages that
worked to do it in smaller chunks.  so i finally ended up with
Mate packages that were being replaced but not leaving me 
without a working desktop.

  the other reason for holding off so long was that i didn't
have enough of a block of time just in case something went 
wrong, but last night i did.  i needed to download nearly 1G
of packages and my line isnt super fast so that took some
time just waiting for chunks to come down the pipe.


> It seemed to be that "apt upgrade" installed a few of them, there was a 
> message something wouldn't be installed because there were no headers so 
> after getting the linux-headers for the kernel and rebooting apt 
> installed the rest.
> mick

  this morning so far all has been well and basically it
all is looking as it should.

  my normal morning routing is to update and upgrade if
there is anything waiting, and today is the first time i'm
back to "normal" routine in some weeks so it is nice to
have a clear update list again.  :)


  songbird

Re: time_t transitions in testing

[mick.crane]

On 2024-05-03 06:11, songbird wrote:

songbird wrote:
...

  the on-going time_t transitions may be causing some packages
to be removed for a while as dependencies get adjusted.

  i've currently not been doing full upgrades because there are
many Mate packages that would be removed.


  i decided to see what i could get upgraded tonight and
have done it in layers.

  mainly i wanted to make sure that anything removed was
being replaced and that my desktop would still be usable
and that seems to have happened.

  so far it seems to have gone well but i'm on the last 400
packages (it takes me a bit to download since i'm not on a
super-fast connection).  with how things have gone so far i
don't expect any hiccups.

  i  Debian and testing aka trixie.  :)

  thanks to all in the Debian community who have gotten this
done.



Eeeek "725 packages can be upgraded. Run 'apt list --upgradable' to see 
them"
It seemed to be that "apt upgrade" installed a few of them, there was a 
message something wouldn't be installed because there were no headers so 
after getting the linux-headers for the kernel and rebooting apt 
installed the rest.

mick

Re: time_t transitions in testing

[Erwan David]

Le 03/05/2024 à 07:11, songbird a écrit :

songbird wrote:
...

   the on-going time_t transitions may be causing some packages
to be removed for a while as dependencies get adjusted.

   i've currently not been doing full upgrades because there are
many Mate packages that would be removed.

   i decided to see what i could get upgraded tonight and
have done it in layers.

   mainly i wanted to make sure that anything removed was
being replaced and that my desktop would still be usable
and that seems to have happened.

   so far it seems to have gone well but i'm on the last 400
packages (it takes me a bit to download since i'm not on a
super-fast connection).  with how things have gone so far i
don't expect any hiccups.

   i  Debian and testing aka trixie.  :)

   thanks to all in the Debian community who have gotten this
done.


   songbird




Doing regular upgrades, checking what is removed, what is installed, 
waiting when situation is complex leads me to a perfectly working 
trixie. That's a good work from the team doing the transition.


As always in testing, one must be careful (and I woul stringly advise 
against auto-upgrades...), but when a little attention and sometimes 
patience, it works.



--
Erwan David

Re: time_t transitions in testing

[Brad Rogers]

On Fri, 3 May 2024 01:11:31 -0400
songbird  wrote:

Hello songbird,

>  mainly i wanted to make sure that anything removed was
>being replaced and that my desktop would still be usable
>and that seems to have happened.

This has been my experience, too.

I will also add my thanks to the many, many, people that make this
possible;

Thank you, one and all.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Down the stairs no one cares, he who wins is he who dares
Disco Man - The Damned


pgpdp_nZ8jTbx.pgp
Description: OpenPGP digital signature

Re: Installing testing on Acer Aspire 315

[Sirius]

In days of yore (Thu, 02 May 2024), Paul Scott thus quoth: 
> 
> On 5/1/2024 10:44 AM, Nicolas George wrote:
> > Paul Scott (12024-05-01):
> > > I read that I should try a more complete image which I am downloading
> > > (jigdo) now.
> > Waste of time. The drivers are either in the kernel image or in
> > individual packages, you can install them on top of what you have.
> > 
> > > I would appreciate any thoughts or suggestions,
> > Check the PCI ids of your Ethernet controller. Download the kernel image
> > you are considering, check if any of its modules matches these ids. n
> 
> I may need to do that.  Thank you,
> 
> In the mean time, an install seemed to be working but gave an failure
> error which said it would be in the log and visible on virtual terminal 4,
> I didn't know how to get to a virtual in the installer.  Various
> combinations with F4 didn't seem to work.
> 
> Google didn't seem to help. Can someone tell me how to get to a virtual
> terminal in the installer?

Control-Alt-F4 should get you to vc4. It might be enough with Alt-F4 if it
is text-mode installation, but if you are doing a GUI install (Wayland or
X running) you need the Control-Alt combo.

-- 
Kind regards,

/S

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/1/2024 10:44 AM, Nicolas George wrote:

Paul Scott (12024-05-01):

I read that I should try a more complete image which I am downloading
(jigdo) now.

Waste of time. The drivers are either in the kernel image or in
individual packages, you can install them on top of what you have.


I would appreciate any thoughts or suggestions,

Check the PCI ids of your Ethernet controller. Download the kernel image
you are considering, check if any of its modules matches these ids. n


I may need to do that.  Thank you,

In the mean time, an install seemed to be working but gave an failure 
error which said it would be in the log and visible on virtual terminal 
4, I didn't know how to get to a virtual in the installer.  Various 
combinations with F4 didn't seem to work.


Google didn't seem to help. Can someone tell me how to get to a virtual 
terminal in the installer?


TIA

Paul




Regards,

Re: time_t transitions in testing

[songbird]

songbird wrote:
...
>   thanks to all in the Debian community who have gotten this
> done.

  all looks ok.  :)


  songbird

time_t transitions in testing

[songbird]

songbird wrote:
...
>   the on-going time_t transitions may be causing some packages
> to be removed for a while as dependencies get adjusted.
>
>   i've currently not been doing full upgrades because there are
> many Mate packages that would be removed.

  i decided to see what i could get upgraded tonight and
have done it in layers.

  mainly i wanted to make sure that anything removed was
being replaced and that my desktop would still be usable
and that seems to have happened.

  so far it seems to have gone well but i'm on the last 400
packages (it takes me a bit to download since i'm not on a
super-fast connection).  with how things have gone so far i
don't expect any hiccups.

  i  Debian and testing aka trixie.  :)

  thanks to all in the Debian community who have gotten this
done.


  songbird

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/2/2024 8:06 PM, Max Nikulin wrote:

On 02/05/2024 12:19, Sirius wrote:

If your wifi is also the AX200 (maybe a different revision), it *should*
work.


lspci -nn

may help with more precise identification.


I don't have linux on the machine for which I want the information.  I 
now have the driver name from Windows/Settings.





It requires firmware-iwlwifi from non-free-firmware, so check that 
install image contains firmware.


I would avoid installing testing for several weeks. Maybe a huge 
change with 64 bit time_t has not settled yet.


My experience with

02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 
[8086:2723] (rev 1a)


is far from being positive. Firmware crashes are not infrequent. Not 
all applications handle lost packets and disabling/enabling network 
adapter gracefully. It might depend on the WiFi router (and others 
around).



I'll consider that strongly,

Thank you,

Paul

Re: Installing testing on Acer Aspire 315

[Max Nikulin]

On 02/05/2024 12:19, Sirius wrote:

If your wifi is also the AX200 (maybe a different revision), it *should*
work.


lspci -nn

may help with more precise identification.

It requires firmware-iwlwifi from non-free-firmware, so check that 
install image contains firmware.


I would avoid installing testing for several weeks. Maybe a huge change 
with 64 bit time_t has not settled yet.


My experience with

02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 
[8086:2723] (rev 1a)


is far from being positive. Firmware crashes are not infrequent. Not all 
applications handle lost packets and disabling/enabling network adapter 
gracefully. It might depend on the WiFi router (and others around).

Re: Installing testing on Acer Aspire 315

[Sirius]

In days of yore (Wed, 01 May 2024), Paul Scott thus quoth: 
> 
> On 5/1/2024 10:57 AM, Sirius wrote:
> > I have an Aspire A715-41G and the wireless is an Intel AX200. I am
> > currently using iwd and iwctl to manage it, but NetworkManager picked it
> > up off the bat and allowed it to be configured - even during installation.
> > 
> > You will want to use 'lspci' to figure out if the card is seen at all and
> > you should get a line like:
> > 
> > 04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
> > 
> > Once you know what make/model the wifi is, you can start looking for the
> > right driver if it is not auto-detected.
> 
> How did you install Debian?

I have a USB stick with Ventoy on it, and a collection of ISOs that I can
pick through depending on what I am doing. The Debian ISO is the 12.5 DVD
version.

It was surprising to me just how much the installer detected and got
right, because it asked me about wifi network and key and then off it
went.

If your wifi is also the AX200 (maybe a different revision), it *should*
work. There is a lot to be said about Intel, but their drivers do get
pushed upstream and make it into the distribution kernels. iwd is also an
Intel thing and quite nice to use when digging into it.

-- 
Kind regards,

/S

Re: Installing testing on Acer Aspire 315

[Paul Scott]

On 5/1/2024 10:57 AM, Sirius wrote:

In days of yore (Wed, 01 May 2024), Paul Scott thus quoth:

Hello,

I have many installs over many years (only a few per year)..

I tried a Testing net install pn my new Acer Aspire 315 and it didn't find
an Ethernet driver.  (wireless?).

I read that I should try a more complete image which I am downloading
(jigdo) now.

I would appreciate any thoughts or suggestions,

I have an Aspire A715-41G and the wireless is an Intel AX200. I am
currently using iwd and iwctl to manage it, but NetworkManager picked it
up off the bat and allowed it to be configured - even during installation.

You will want to use 'lspci' to figure out if the card is seen at all and
you should get a line like:

04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

Once you know what make/model the wifi is, you can start looking for the
right driver if it is not auto-detected.


How did you install Debian?

Thank you,

Paul

Re: Installing testing on Acer Aspire 315

[Sirius]

In days of yore (Wed, 01 May 2024), Paul Scott thus quoth: 
> Hello,
> 
> I have many installs over many years (only a few per year)..
> 
> I tried a Testing net install pn my new Acer Aspire 315 and it didn't find
> an Ethernet driver.  (wireless?).
> 
> I read that I should try a more complete image which I am downloading
> (jigdo) now.
> 
> I would appreciate any thoughts or suggestions,

I have an Aspire A715-41G and the wireless is an Intel AX200. I am
currently using iwd and iwctl to manage it, but NetworkManager picked it
up off the bat and allowed it to be configured - even during installation.

You will want to use 'lspci' to figure out if the card is seen at all and
you should get a line like:

04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

Once you know what make/model the wifi is, you can start looking for the
right driver if it is not auto-detected.

-- 
Kind regards,

/S

Re: Installing testing on Acer Aspire 315

[Nicolas George]

Paul Scott (12024-05-01):
> I read that I should try a more complete image which I am downloading
> (jigdo) now.

Waste of time. The drivers are either in the kernel image or in
individual packages, you can install them on top of what you have.

> I would appreciate any thoughts or suggestions,

Check the PCI ids of your Ethernet controller. Download the kernel image
you are considering, check if any of its modules matches these ids.

Regards,

-- 
  Nicolas George

Installing testing on Acer Aspire 315

[Paul Scott]

Hello,

I have many installs over many years (only a few per year)..

I tried a Testing net install pn my new Acer Aspire 315 and it didn't 
find an Ethernet driver.  (wireless?).


I read that I should try a more complete image which I am downloading 
(jigdo) now.


I would appreciate any thoughts or suggestions,

Paul

Gnome problem occured, system can't recover on testing

[Richard]

Hi,
after a reboot I'm now greeted by a white screen saying

Oh no! Something has gone wrong A problem has occurred and the system can't
recover. Please contact a system administrator.

I can still switch to a different tty, but I can't really tell what the
issue is. The output of journalctl -b --priority 3 is:

kernel: cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
bluetoothd[894]: profiles/sap/server.c:sap_server_register() Sap driver
initialization failed.
bluetoothd[894]: sap-server: Operation not permitted (1)
bluetoothd[894]: Failed to load LTKs for hci0: Invalid Parameters (0x0d)
systemd[1]: Failed to start firewalld.service - firewalld - dynamic
firewall daemon.
csc_vpnagent[961]: Function: startParser File:
../../vpn/Common/Xml/CVCSaxParser.cpp Line: 171 Invoked Function:
xmlCreateFileParserCtxt Return Code: -33554427 (0xFE05) Description:
GLOBAL_ERROR_NULL_POINTER
csc_vpnagent[961]: Function: LoadSettingsFromXmlFile File:
../../vpn/PhoneHome/PhoneHomeAgent.cpp Line: 626 Invoked Function:
XmlParser::parseFile Return Code: -33554423 (0xFE09) Description:
GLOBAL_ERROR_UNEXPECTED
gnome-session-binary[1447]: Unrecoverable failure in required component
org.gnome.Shell.desktop
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change:
GET_CONNECTOR_STATUS failed (-5)
gnome-session-binary[1618]: Unrecoverable failure in required component
org.gnome.Shell.desktop
gnome-session-binary[1618]: Unrecoverable failure in required component
org.gnome.SettingsDaemon.UsbProtection.desktop
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change:
GET_CONNECTOR_STATUS failed (-110)
login[2018]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No such
file or directory
PAM adding faulty module: pam_lastlog.so

Now, the first line can just be ignored, that's typical. The things that
concern me the most are the last two lines. It already has been reported as
a bug and seems to be in the works, but I haven't seen any inidcation that
this should cause a complete failure. The other reasons I've found for the
Gnome related error message was either trouble with Nvidia - but I don't
have any installed - or outdated firmware. So I've just made double shure
to really have the latest firmware by copying over the 04/2024 archive from
kernel.org with rsync -rc, yet no change (I'm running on a Ryzen 7040, so
the AMD firmware available in the Debian repos is way too old, no matter
which branch).

So what's going on?

Best
Richard

Re: Testing amd64 netinst LUKS+LVM install broken

[Gilles Mocellin]

Le mercredi 10 avril 2024, 02:51:26 CEST Craig Hesling a écrit :
> Hi all,
> 
> I'm having an issue with the guided partitioner in the Debian testing amd64
> installer.
> Specifically, the "Guided - use entire disk and set up encrypted LVM"
> errors out and emit the following error message:
> 
> partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1:
> cannot open shared object file: No such file or directory
> 
> Is this a known issue?

Yes !

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067831

Correction should soon arrive in daily builds.

Re: Testing amd64 netinst LUKS+LVM install broken

[The Wanderer]

On 2024-04-10 at 02:39, Andrew M.A. Cater wrote:

> On Tue, Apr 09, 2024 at 05:51:26PM -0700, Craig Hesling wrote:
> 
>> Hi all,
>> 
>> I'm having an issue with the guided partitioner in the Debian
>> testing amd64 installer. Specifically, the "Guided - use entire
>> disk and set up encrypted LVM" errors out and emit the following
>> error message:
>> 
>> partman-lvm: pvcreate: error while loading shared libraries:
>> libaio.so.1: cannot open shared object file: No such file or
>> directory

The fact that this is libaio catches my eye.

> Hi,
> 
> I suspect that Debian Testing _might_ be uninstallable just at the
> moment. There's a large scale migration and change of packages (to do
> with securing a workable time implementation post-2038 and moving
> from 32 bit values).
> 
> That's taken a lot longer than expected: Debian Unstable and
> therefore Debian Testing have been hit. It's just possible that this
> library is caught up in the dependencies.

Yes, this is almost certainly what's going on. libaio is one of the
small handful of libraries (that I'm aware of) for which the 't64'
version of the package appears to have slipped through the cracks on the
measures being taken to prevent things from migrating to testing until
the transition is properly ready.

$ apt-cache search libaio
libaio-dev - Linux kernel AIO access library - development files
libaio1 - Linux kernel AIO access library - shared library
libaio1t64 - Linux kernel AIO access library - shared library


$ apt-cache search t64 | egrep '^lib[^ ]+t64 ' | cut -d ' ' -f 1
libfyba0t64
libglibmm-2.68-1t64
libaio1t64
libnetcdf19t64
libudns0t64

> This will resolve itself in due course - but it might be better to
> install a minimal stable and then upgrade to testing later.
> 
> Be aware also that the problematic version of xz libraries is also in
> Debian testing - someone else pointed this up the other day.

For some values of "the problematic version". The one that is *known* to
be backdoored has been reverted:

$ apt-cache policy xz-utils
xz-utils:
  Installed: 5.6.1+really5.4.5-1
  Candidate: 5.6.1+really5.4.5-1
  Version table:
 *** 5.6.1+really5.4.5-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

However, while the version reverted *to* in this case - 5.4.5 - is from
prior to the introduction of the known backdoor, it *is* from well after
the now-apparent bad actor began contributing to the upstream project,
and there is discussion of possibly needing to revert to as far back as
a 5.2.x version in order to be completely sure of not having any commits
that come from that bad actor.

(If there's a detail I've missed catching which would mean that any of
that is inaccurate, I would be pleased if someone would point it out to
me.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Testing amd64 netinst LUKS+LVM install broken

[Andrew M.A. Cater]

On Tue, Apr 09, 2024 at 05:51:26PM -0700, Craig Hesling wrote:
> Hi all,
> 
> I'm having an issue with the guided partitioner in the Debian testing amd64
> installer.
> Specifically, the "Guided - use entire disk and set up encrypted LVM"
> errors out and emit the following error message:
> 
> partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1:
> cannot open shared object file: No such file or directory
> 

Hi,

I suspect that Debian Testing _might_ be uninstallable just at the moment.
There's a large scale migration and change of packages (to do with securing
a workable time implementation post-2038 and moving from 32 bit values).

That's taken a lot longer than expected: Debian Unstable and therefore
Debian Testing have been hit. It's just possible that this library
is caught up in the dependencies.

This will resolve itself in due course - but it might be better to
install a minimal stable and then upgrade to testing later.

Be aware also that the problematic version of xz libraries is also
in Debian testing - someone else pointed this up the other day.

Hope this helps,

Andy
(amaca...@debian.org)


> Is this a known issue?
> 
> *Reproduction:*
> 
> md5sum ~/Downloads/debian-testing-amd64-netinst.iso
> > d80f2f073cdb2db52d9d1dd8e625b04b
>  /home/craig/Downloads/debian-testing-amd64-netinst.iso
> dd if=/dev/zero of=~/Downloads/test-hda.img bs=1G count=8
> qemu-system-x86_64 -cdrom ~/Downloads/debian-testing-amd64-netinst.iso -hda
> ~/Downloads/test-hda.img -m 8G
> 
> https://youtu.be/jJ-oOA2s8Wc
> 
> All the best,
> 
> Craig

Re: Testing amd64 netinst LUKS+LVM install broken

[Craig Hesling]

I also, just tried the latest download from
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/:

md5sum debian-testing-amd64-netinst.iso
> e618afbebbbdf9495c74140bc87f2a4b  debian-testing-amd64-netinst.iso
sha256sum debian-testing-amd64-netinst.iso
> a72e2cd87f8bc1af3a6df65a12194c8e043c617fd15f23d545ddab8c55c82e51
 debian-testing-amd64-netinst.iso
sha512sum debian-testing-amd64-netinst.iso
>
db2ea5d9aecf92768d3904b2101a32b73a140e450335fcbfd4c640247b779c0b30938d50ad13938fb158f1063fdfd6514d1bbf38dd9b059fc5c6ac7b1ff3a50a
 debian-testing-amd64-netinst.iso

This shows the issue.

All the best,

Craig

On Tue, Apr 9, 2024 at 5:51 PM Craig Hesling 
wrote:

> Hi all,
>
> I'm having an issue with the guided partitioner in the Debian testing
> amd64 installer.
> Specifically, the "Guided - use entire disk and set up encrypted LVM"
> errors out and emit the following error message:
>
> partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1:
> cannot open shared object file: No such file or directory
>
> Is this a known issue?
>
> *Reproduction:*
>
> md5sum ~/Downloads/debian-testing-amd64-netinst.iso
> > d80f2f073cdb2db52d9d1dd8e625b04b
>  /home/craig/Downloads/debian-testing-amd64-netinst.iso
> dd if=/dev/zero of=~/Downloads/test-hda.img bs=1G count=8
> qemu-system-x86_64 -cdrom ~/Downloads/debian-testing-amd64-netinst.iso
> -hda ~/Downloads/test-hda.img -m 8G
>
> https://youtu.be/jJ-oOA2s8Wc
>
> All the best,
>
> Craig
>

Testing amd64 netinst LUKS+LVM install broken

[Craig Hesling]

Hi all,

I'm having an issue with the guided partitioner in the Debian testing amd64
installer.
Specifically, the "Guided - use entire disk and set up encrypted LVM"
errors out and emit the following error message:

partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1:
cannot open shared object file: No such file or directory

Is this a known issue?

*Reproduction:*

md5sum ~/Downloads/debian-testing-amd64-netinst.iso
> d80f2f073cdb2db52d9d1dd8e625b04b
 /home/craig/Downloads/debian-testing-amd64-netinst.iso
dd if=/dev/zero of=~/Downloads/test-hda.img bs=1G count=8
qemu-system-x86_64 -cdrom ~/Downloads/debian-testing-amd64-netinst.iso -hda
~/Downloads/test-hda.img -m 8G

https://youtu.be/jJ-oOA2s8Wc

All the best,

Craig

Re: testing new sdm drive

[David Wright]

On Tue 26 Mar 2024 at 04:38:52 (-0400), gene heskett wrote:
> On 2/9/24 20:36, Alexander V. Makartsev wrote:
[ … ]
> > It's not possible for me to know what went wrong.
> > Have you created "reftestfile" inside "/mnt/disktest" directory?
> > How many "testfile*" files, if any, were created on the filesystem
> > mounted at "/mnt/disktest"?
> > Was there anything relevant in the syslog about "sdm" drive after the test?
> > If you'd followed my instructions step by step, you'd end up
> > inside "/mnt/disktest" directory and for the last step all you had
> > to do is copy and paste that one-liner 'for' loop into the command
> > line.
> > It's a long line and it really meant to be copied and pasted not
> > typed by hand, and also to give you the idea of the process, so
> > you could adjust it if needed.
> > I've tested it again on my computer and it worked as expected,
> > synchronously created "testfiles" inside current directory and
> > calculated their hashes one by one.
> > 
> And by now, I've forgotten what it was that we were trying to
> accomplish.  One of the hazards of my next b-day being the 90'th.
> Sorry. Or t-bird is messing  with my mind by reserectiing older messages.

You seem to have mislaid your first reply to Alexander, at:
  https://lists.debian.org/debian-user/2024/02/msg00422.html
which appears to show that the drive was a dud 64GB disk, and
not 2TB in capacity.

Cheers,
David.

Re: testing new sdm drive

[gene heskett]

On 2/9/24 20:36, Alexander V. Makartsev wrote:

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

     $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.


And by now, I've forgotten what it was that we were trying to 
accomplish.  One of the hazards of my next b-day being the 90'th.

Sorry. Or t-bird is messing  with my mind by reserectiing older messages.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: [testing] plus de session graphique !

[Gaëtan Perrier]

Merci ! :)

Le 18 mars 2024 08:50:26 GMT+01:00, "Sébastien NOBILI" 
 a écrit :
>Bonjour,
>
>Le 2024-03-17 15:53, Gaëtan Perrier a écrit :
>> Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets
>> libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme
>> plus disponibles j'ai perdu ma session graphique. Elle s'est fermée
>> pendant la mise à jour ...
>
>Le fichier /var/log/apt/history.log permet de retrouver l'historique APT.
>
>Sébastien
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: [testing] plus de session graphique !

[Sébastien NOBILI]

Bonjour,

Le 2024-03-17 15:53, Gaëtan Perrier a écrit :

Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets
libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme
plus disponibles j'ai perdu ma session graphique. Elle s'est fermée
pendant la mise à jour ...


Le fichier /var/log/apt/history.log permet de retrouver l'historique 
APT.


Sébastien

Re: [testing] plus de session graphique !

[Klaus Becker]

Non, il faut chercher la commande correspondante pour gnome, à lancer en tant 
que utilisateur. Ou lightdm ou qc de ce genre pour lancer le gestionnaire de 
connexion graphique installé.

Mais si X ne fonctionne pas du tout, ça ne peut pas fonctionner non plus

Klaus

[resolu] Re: [testing] plus de session graphique !

[Gaëtan Perrier]

Problème résolu !
Je ne sais pas comment ça s'est fait mais gdm3, gnome-shell et gnome-
session avaient été déinstallés ...
Après les avoir remis tout est rentré dans l'ordre.
Ouf !

Gaëtan

Re: [testing] plus de session graphique !

[Gaëtan Perrier]

Le dimanche 17 mars 2024 à 16:47 +0100, Gaëtan Perrier a écrit :
> Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit :
> > 
> > Salut,
> > 
> > j'ai parfois un problème du même genre sous instable. Comme
> > workaround, 
> > je démarre XFCE4 en tty avec "startxfce4".
> > 
> 
> Pour Gnome, est-ce que c'est startx ?
> 
> Gaëtan
> 

Si je lance startx, j'ai un écran noir avec curseur de la souris
uniquement.

Gaëtan

Re: [testing] plus de session graphique !

[Gaëtan Perrier]

Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit :
> 
> Salut,
> 
> j'ai parfois un problème du même genre sous instable. Comme
> workaround, 
> je démarre XFCE4 en tty avec "startxfce4".
> 

Pour Gnome, est-ce que c'est startx ?

Gaëtan

Re: [testing] plus de session graphique !

[Gaëtan Perrier]

J'ai pu lancer synaptic via ssh -X et j'ai pu constater que le problème
n'est pas lié aux paquets que je voulais retirer car en fait ils n'ont
pas été retirés. Le plantage de X est donc intervenu juste avant et
sans rapport. C'est donc liés aux mises à jours d'aujourd'hui...

Le dimanche 17 mars 2024 à 15:53 +0100, Gaëtan Perrier a écrit :
> Bonjour,
> 
> Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets 
> libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme
> plus disponibles j'ai perdu ma session graphique. Elle s'est fermée
> pendant la mise à jour ...
> Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog
> ou
> dans journalctl.
> J'utilise les pilotes nvidia-legacy-driver-390xx.
> J'ai juste le service ocserv qui est failed mais je ne pense pas que
> ça
> ait un lien ?
> Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les
> retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui
> est sous stable mais je ne vois pas de paquet pouvant correspondre
> ...
> 
> C'était un nom court et dans un des deux il me semble qu'il y avait
> 64.
> 
> Si quelqu'un a une idée je suis preneur.
> 
> Gaëtan
> 

Re: [testing] plus de session graphique !

[Klaus Becker]

Am 17/03/2024 um 15:53 schrieb Gaëtan Perrier:

Bonjour,

Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets
libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme
plus disponibles j'ai perdu ma session graphique. Elle s'est fermée
pendant la mise à jour ...
Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou
dans journalctl.
J'utilise les pilotes nvidia-legacy-driver-390xx.
J'ai juste le service ocserv qui est failed mais je ne pense pas que ça
ait un lien ?
Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les
retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui
est sous stable mais je ne vois pas de paquet pouvant correspondre ...

C'était un nom court et dans un des deux il me semble qu'il y avait 64.

Si quelqu'un a une idée je suis preneur.

Gaëtan



Salut,

j'ai parfois un problème du même genre sous instable. Comme workaround, 
je démarre XFCE4 en tty avec "startxfce4".


librement

Klaus

[testing] plus de session graphique !

[Gaëtan Perrier]

Bonjour,

Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets 
libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme
plus disponibles j'ai perdu ma session graphique. Elle s'est fermée
pendant la mise à jour ...
Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou
dans journalctl.
J'utilise les pilotes nvidia-legacy-driver-390xx.
J'ai juste le service ocserv qui est failed mais je ne pense pas que ça
ait un lien ?
Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les
retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui
est sous stable mais je ne vois pas de paquet pouvant correspondre ...

C'était un nom court et dans un des deux il me semble qu'il y avait 64.

Si quelqu'un a une idée je suis preneur.

Gaëtan

problem with installer (testing)

[Angelo Mose Pozzi]

The newly released debian installer (daily build) for testing do not show

the LVM logical volumes and fail when asked for LVM configuration.

The problem is quite new because a installer build im mid February

worked fine.

So who do I have to file the bug to?

Regards

Angelo Pozzi

Re: compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40

[Étienne Mollier]

Bonjour Basile,

Mon avis à deux sous d'internaute vaut ce qu'il vaut, et je ne
suis pas à l'abri de me prendre les pieds dans le tapis, donc
n'hésitez pas à prendre d'autres avis par ailleurs avant
d'engager des frais.  En particulier, je décline toute
responsabilité s'il devait y avoir un ou des pépins après achat.
;)

Basile Starynkevitch, on 2024-02-22:
> Est ce ia carte mère et le processeur susdits sont compatible Debian
> Testing? En particulier pour faire tourner un serveur Xorg et Gimp. Je
> m'interroge sur la compatibilité de la carte mère avec le coprocesseur
> graphique du AMD Ryzen  7 8700G.

Je ne vois pas d'objections : les nouvelles moutures de
l'installateur Debian devraient automatiquement ajouter les
microprogrammes nécessaires au bon fonctionnement du processeur
et de sa puce graphique embarquée.  Évidemment, le diable se
cache dans les détails, et on n'est pas à l'abri que certains
composants se trouvent être retors : cartes réseau, puces WiFi,
ce genre de choses.

En fait, ce pourrait être intéressant à la fin de l'installation
de la machine de rédiger un rapport via le système de suivi de
bogues, pour indiquer à l'équipe en charge de l'installateur ce
qui s'est bien passé et ce qui s'est moins bien passé :

$ reportbug installation-reports

Pour le moment, aucun des rapports d'installation[1] ne semblent
concerner les cartes mères à chipset B650, ce qui suggère que :
soit elles n'ont pas de problèmes, soit personne ne s'en sert.

[1] : https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports

> (l'usage principal étant le traitement d'images numériques, notamment avec
> Gimp et Inkscape; accessoirement la compilation par GCC)
> 
> Pour ceux qui connaissent materiel.net les composants qu'on souhaite
> assembler sont listés en https://materiel.net/s/5CKV6K et vos critiques
> constructives sont bienvenues (pour un usage professionnel pour un
> photographe professionnel)

Pour éviter de perdre du temps sur de la casse, surtout pour un
usage professionnel où le temps est littéralement de l'argent,
est-ce que ça ne vaudrait pas le coup de rajouter un disque pour
constituer une colonne Raid 1, et ainsi éviter de perdre une
journée de travail à jongler avec des sauvegardes lors de la
panne du disque ?  Attention, le Raid 1 ne remplace pas la mise
en place d'une stratégie de sauvegarde.

Autrement, compter uniquement sur une puce graphique embarquée
peut paraître un peu léger pour un usage professionnel, mais la
configuration a l'air suffisamment solide pour rajouter une
carte graphique dédiée après coup, si la puce intégrée devait
être insuffisante.

Bonne journée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.


signature.asc
Description: PGP signature

compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40

[Basile Starynkevitch]

Bonsoir,

Est ce ia carte mère et le processeur susdits sont compatible Debian 
Testing? En particulier pour faire tourner un serveur Xorg et Gimp. Je 
m'interroge sur la compatibilité de la carte mère avec le coprocesseur 
graphique du AMD Ryzen  7 8700G.


(l'usage principal étant le traitement d'images numériques, notamment 
avec Gimp et Inkscape; accessoirement la compilation par GCC)


Pour ceux qui connaissent materiel.net les composants qu'on souhaite 
assembler sont listés en https://materiel.net/s/5CKV6K et vos critiques 
constructives sont bienvenues (pour un usage professionnel pour un 
photographe professionnel)


Merci

NB. Je me réjouis de l'arrêt de la Cour de Cassation 
https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563?search_api_fulltext=licence%20GPL=Rechercher_du=_au=_juridiction=all===0=1 
<https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563?search_api_fulltext=licence%20GPL=Rechercher_du=_au=_juridiction=all===0=1> 
en faveur la la licence GPL, qui est celle utilisée dans le moteur 
d'inference RefPerSys dont le code source est en


https://github.com/RefPerSys/RefPerSys

--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See/voir:   https://github.com/RefPerSys/RefPerSys

Fix for boot failure with testing stream and 6.6.13-amd64 kernel

[Sam Varghese]

This is a post meant to help anyone who finds his/her system unbootable 
- as I did - after updating to the latest version of the testing stream 
which comes with a 6.6.13-amd64 kernel.


When I updated last week, my system refused to boot. Checking revealed 
that the system-load-modules service was missing.


I then checked to see if the linux-headers for this version had been 
installed.


root@zizyphus:~# dpkg -l | grep linux-headers-6.6.13-amd64

Turns out it has not been installed.

Installing it also brings along a couple of other packages; these three 
packages fix the issue and make the machine bootable again.


Sam
--

(Sam Varghese)

Re: testing new sdm drive continued

[David Christensen]

On 2/10/24 08:25, gene heskett wrote:

I managed to kill f3write, so f3probe could access it:
ene@coyote:/mnt/disktest$ sudo f3probe --destructive --time-ops /dev/sdm
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
  it can take longer. Please be patient.

Bad news: The device `/dev/sdm' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=124050943 /dev/sdm

Device geometry:
  *Usable* size: 59.15 GB (124050944 blocks)
     Announced size: 1.91 TB (409600 blocks)
     Module: 2.00 TB (2^41 Bytes)
     Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
    Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2.07s
  Operation: total time / count = avg time
   Read: 311.9ms / 4212 = 74us
  Write: 1.75s / 24740 = 70us
  Reset: 1us / 1 = 1us
gene@coyote:/mnt/disktest$
No faster than it is, its not worth the f3fix effort, I can buy 
reputable, much faster sd cards at 1/3rd the cost.



Okay -- here is the thread Thomas referenced.  It has not hit the 
archive servers yet.



The f3probe results are bad news, but not unexpected.  At least you have 
a definite answer that you can send to the seller and/or Amazon (?).



David

Re: testing new sdm drive

[gene heskett]

On 2/10/24 00:46, David Christensen wrote:

On 2/9/24 00:51, gene heskett wrote:

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta
...
Please try again with the drive connected directly to a motherboard 
USB 3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.



Does smartctl(8) fail when you connect the USB SSD to other USB ports?

Allready packed up for return, I found enough fraud with the f3 package 
to jail somebody.


David

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/9/24 20:37, Alexander V. Makartsev wrote:

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

     $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.


Someone else advised me of the f3 package, designed to do exactly this, 
disclosed that the first one tested was actually an undersized and slow 
64G drive. Got them packed up and return authorization already for a 
mailing label,  Thank you very much for your assistance Alexander, 
interest much apprecaited.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive continued

[gene heskett]

On 2/8/24 15:36, Linux-Fan wrote:

Alexander V. Makartsev writes:


[...]
I managed to kill f3write, so f3probe could access it:
ene@coyote:/mnt/disktest$ sudo f3probe --destructive --time-ops /dev/sdm
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
 it can take longer. Please be patient.

Bad news: The device `/dev/sdm' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=124050943 /dev/sdm

Device geometry:
 *Usable* size: 59.15 GB (124050944 blocks)
Announced size: 1.91 TB (409600 blocks)
Module: 2.00 TB (2^41 Bytes)
Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2.07s
 Operation: total time / count = avg time
  Read: 311.9ms / 4212 = 74us
 Write: 1.75s / 24740 = 70us
 Reset: 1us / 1 = 1us
gene@coyote:/mnt/disktest$
No faster than it is, its not worth the f3fix effort, I can buy 
reputable, much faster sd cards at 1/3rd the cost.




HTH
Linux-Fan

öö

[...]

c
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/8/24 15:36, Linux-Fan wrote:

Alexander V. Makartsev writes:


On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
http://www.smartmontools.org>www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0


[...]

Looks like a scam. Probably a reprogrammed controller to falsely 
report 2TB of space to the system.


I support this view :)


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest



From here on I'd suggest trying the tools from package `f3`.


After installing it, find the documentation under
/usr/share/doc/f3/README.rst.gz. Basic usage requires only two commands:

 f3write .

Which has now stopped after severa hours of quitelatharic speeds in the 
20m/second are, showing a litle over 1.5%.  The bash shell shows it has 
written:

ree space: 1.87 TB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Creating file 17.h2w ... OK!
Creating file 18.h2w ... OK!
Creating file 19.h2w ... OK!
Creating file 20.h2w ... OK!
Creating file 21.h2w ... OK!
Creating file 22.h2w ... OK!
Creating file 23.h2w ... OK!
Creating file 24.h2w ... OK!
Creating file 25.h2w ... OK!
Creating file 26.h2w ... OK!
Creating file 27.h2w ... OK!
Creating file 28.h2w ... OK!
Creating file 29.h2w ... OK!
Creating file 30.h2w ... OK!
Creating file 31.h2w ... OK!
Creating file 32.h2w ... OK!
Creating file 33.h2w ... OK!
Creating file 34.h2w ... OK!
Creating file 35.h2w ... OK!
Creating file 36.h2w ... OK!
Creating file 37.h2w ... OK!
Creating file 38.h2w ... OK!
Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32

but is taking a few bytes now and then. I 'd thing if f3write was having 
a problem, it would exist with a report. An ls -l in another shell took 
about two minutes to respond:

gene@coyote:/mnt/disktest$ ls -l
total 40627044
-rw--- 1 root root 1073741824 Feb 10 05:49 10.h2w
-rw--- 1 root root 1073741824 Feb 10 05:51 11.h2w
-rw--- 1 root root 1073741824 Feb 10 05:59 12.h2w
-rw--- 1 root root 1073741824 Feb 10 06:16 13.h2w
-rw--- 1 root root 1073741824 Feb 10 06:25 14.h2w
-rw--- 1 root root 1073741824 Feb 10 06:33 15.h2w
-rw--- 1 root root 1073741824 Feb 10 06:44 16.h2w
-rw--- 1 root root 1073741824 Feb 10 06:45 17.h2w
-rw--- 1 root root 1073741824 Feb 10 06:57 18.h2w
-rw--- 1 root root 1073741824 Feb 10 07:06 19.h2w
-rw--- 1 root root 1073741824 Feb 10 05:22 1.h2w
-rw--- 1 root root 1073741824 Feb 10 07:16 20.h2w
-rw--- 1 root root 1073741824 Feb 10 07:22 21.h2w
-rw--- 1 root root 1073741824 Feb 10 07:32 22.h2w
-rw--- 1 root root 1073741824 Feb 10 07:35 23.h2w
-rw--- 1 root root 1073741824 Feb 10 07:39 24.h2w
-rw--- 1 root root 1073741824 Feb 10 07:50 25.h2w
-rw--- 1 root root 1073741824 Feb 10 08:09 26.h2w
-rw--- 1 root root 1073741824 Feb 10 08:19 27.h2w
-rw--- 1 root root 1073741824 Feb 10 08:29 28.h2w
-rw--- 1 root root 1073741824 Feb 10 08:31 29.h2w
-rw--- 1 root root 1073741824 Feb 10 05:24 2.h2w
-rw--- 1 root root 1073741824 Feb 10 08:37 30.h2w
-rw--- 1 root root 1073741824 Feb 10 08:57 31.h2w
-rw--- 1 root root 1073741824 Feb 10 09:06 32.h2w
-rw--- 1 root root 1073741824 Feb 10 09:32 33.h2w
-rw--- 1 root root 1073741824 Feb 10 09:42 34.h2w
-rw--- 1 root root 1073741824 Feb 10 10:00 35.h2w
-rw--- 1 root root 1073741824 Feb 10 10:11 36.h2w
-rw--- 1 root root  799719936 Feb 10 10:21 37.h2w
-rw--- 1 root root 1073741824 Feb 10 05:26 3.h2w
-rw--- 1 root root 1073741824 Feb 10 05:29 4.h2w
-rw--- 1 root root 1073741824 Feb 10 05:31 5.h2w
-rw--- 1 root root 1073741824 Feb 10 05:33 6.h2w

Re: testing new sdm drive

[David Christensen]

On 2/9/24 00:51, gene heskett wrote:

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta
...
Please try again with the drive connected directly to a motherboard 
USB 3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.



Does smartctl(8) fail when you connect the USB SSD to other USB ports?


David

Re: testing new sdm drive

[Alexander V. Makartsev]

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

    $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: testing new sdm drive

[gene heskett]

On 2/8/24 07:22, Alexander V. Makartsev wrote:

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
     $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
     $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
     $ sudo mkdir /mnt/disktest check
     $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
     $ cd /mnt/disktest check
     $ sudo fallocate -l 1G ./reftestfile check
     $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

     $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run or 
be killed. I don't care how big you've made the t-bird font, by the time 
you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd showing 
and started killing them but cannot kill the last 2 in the D state.


And cannot find .disktest.txt running in a root htop and the2 copy's of 
dd can't be killall'd.



     3f2c5fa95492bfaa18f08c801037d80b *./reftestfile


Next?
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

     3f2c5fa95492bfaa18f08c801037d80b *./testfile1
     3f2c5fa95492bfaa18f08c801037d80b *./testfile2
     ...
     3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 09:21:24AM -0500, Stefan Monnier wrote:
> >> So, if you want to use `badblocks`, you may want to do it on an
> >> encrypted partition (that covers the whole device) rather than on the
> >> raw device.
> > This is an interesting idea. I haven't wrapped my head around "what if
> > the controller maps several block addresses to the same physical block"?
> 
> I assume that's what those thingies do.  But disk encryption encrypts
> every block in a different way (otherwise, your encryption system is too
> poor and will leak information when comparing different blocks), so even
> if you write nothing but zeroes over your whole encrypted partition, the
> encryption will turn them into blocks that have all different contents.

Yes, but those device cheat, they do wear levelling and move (physical)
blocks around behind your back. If you write (logical) block N and read
it right away, chances are good that it comes out clean. But (logical)
block M (fr M << N) may just have been corrupted. That's why I think
you'll have to fill first, then check.

> This said, for the task at hand F3 seems like a simpler and more
> direct answer.

Possibly. I haven't read the man page yet.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Max Nikulin]

On 09/02/2024 20:23, Dan Ritter wrote:

I would (I have, in the past) generate a non-random but mostly
incompressible large file


There are 2 kinds of random number generators:
- Cryptographic grade are intentionally hard to predict
- Pseudo-random

A pseudo-random generator of reasonable quality allows to get long 
enough non-repeating sequence. It can be reproduced if its initial state 
is saved. This property is used for Monte-Carlo simulations in physics, etc.


So you may save a hundred bytes and may check if several Tb generated 
from it is the same.


Is there a reason to avoid the f3 tool? I have tried it only on 32G USB 
and µSD cards, however I do not see a reason why I can not be used for a 
SSD.


As another test I would leave a suspicious drive for a month unpowered 
and check if data are not corrupted. I think, a scenario like

https://blog.gsmarena.com/how-do-you-spot-fake-chinese-usb-hard-drives-well-you-take-them-apart/
is a pessimistic one. A more realistic case is faulty chips with leaking 
memory cells that did not pass quality control.

Re: testing new sdm drive

[Stefan Monnier]

>> So, if you want to use `badblocks`, you may want to do it on an
>> encrypted partition (that covers the whole device) rather than on the
>> raw device.
> This is an interesting idea. I haven't wrapped my head around "what if
> the controller maps several block addresses to the same physical block"?

I assume that's what those thingies do.  But disk encryption encrypts
every block in a different way (otherwise, your encryption system is too
poor and will leak information when comparing different blocks), so even
if you write nothing but zeroes over your whole encrypted partition, the
encryption will turn them into blocks that have all different contents.

This said, for the task at hand F3 seems like a simpler and more
direct answer.


Stefan

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 08:23:30AM -0500, Dan Ritter wrote:
> to...@tuxteam.de wrote: 
> > On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > > So, if you want to use `badblocks`, you may want to do it on an
> > > encrypted partition (that covers the whole device) rather than on the
> > > raw device.
> > 
> > This is an interesting idea. I haven't wrapped my head around "what if
> > the controller maps several block addresses to the same physical block"?
> > 
> > Perhaps you'd have to fill the disk and check afterwards?
> 
> Blocks are very likely to be 128KB, sometimes 64KB.
> 
> I would (I have, in the past) generate a non-random but mostly
> incompressible large file -- a compressed movie is pretty good for this -- 
> use md5sum to get its hash, and then write it under a variety of
> names until I fill the disk. 
> 
> Then read back each file and compare the md5sum of each file to
> the known value. They should be all the same.
> 
> I found a bad RAID controller this way.

What I'd do is encrypt the block number (in whichever form) padded
with zeros to block size with some symmetric scheme (e.g. AES) and
a constant symmetric key. That should be "random enough" and still
repeatable in the sense that, given the block number you know how
it is supposed to look like.

Plus, if you're lucky and have chosen the cipher judiciously, your
CPU might help you to make it fast.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > So, if you want to use `badblocks`, you may want to do it on an
> > encrypted partition (that covers the whole device) rather than on the
> > raw device.
> 
> This is an interesting idea. I haven't wrapped my head around "what if
> the controller maps several block addresses to the same physical block"?
> 
> Perhaps you'd have to fill the disk and check afterwards?

Blocks are very likely to be 128KB, sometimes 64KB.

I would (I have, in the past) generate a non-random but mostly
incompressible large file -- a compressed movie is pretty good for this -- 
use md5sum to get its hash, and then write it under a variety of
names until I fill the disk. 

Then read back each file and compare the md5sum of each file to
the known value. They should be all the same.

I found a bad RAID controller this way.

-dsr-

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
> > chances are it's installed. I'd look into that man page.
> 
> `badblocks` sadly writes the same pattern on every block, AFAIK, so if
> the drive just remaps new logical blocks to already used physical
> blocks, `badblocks` may be convinced that the drive works fine even when
> it doesn't.

Absolutely right. And most probably it checks a block right after writing,
and doesn't try to fill up the disk first.

> So, if you want to use `badblocks`, you may want to do it on an
> encrypted partition (that covers the whole device) rather than on the
> raw device.

This is an interesting idea. I haven't wrapped my head around "what if
the controller maps several block addresses to the same physical block"?

Perhaps you'd have to fill the disk and check afterwards?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Stefan Monnier]

> BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
> chances are it's installed. I'd look into that man page.

`badblocks` sadly writes the same pattern on every block, AFAIK, so if
the drive just remaps new logical blocks to already used physical
blocks, `badblocks` may be convinced that the drive works fine even when
it doesn't.

So, if you want to use `badblocks`, you may want to do it on an
encrypted partition (that covers the whole device) rather than on the
raw device.


Stefan

Re: testing new sdm drive

[gene heskett]

On 2/8/24 15:11, Alexander V. Makartsev wrote:

On 09.02.2024 00:23, gene heskett wrote:
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.
Well, it will consume CPU cycles for sure, at least to calculate md5 
hashes and perform I/O on the target drive and RAM.
I don't think it could crash the system, but the load could be 
significant enough to disturb your work, so
if I was in your place I'd wait until the machine is free from any work 
or load and then test the new drive.


That is my intentions, but I'm in the middle of making a tronxy400-pro 
that has never worked so I using the frame to build a printer that 
works.  Doing essentially the same with an Ender 5 Plus. Including 
klipper, a bpi5-m5, the whole MaryAnn.  So OpenSCAD is busier than that 
famous cat on a tin roof.

--
With kindest regards, Alexander.

Take care yourself Alexander.


⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.



Please try again with the drive connected directly to a motherboard USB 
3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.


I seem to recall that you have a lot of USB devices connected to your 
computer(s).  The Asus PRIME Z370-A II Series manual page ix states:


Intel ® Z370 Chipset
- 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
USB
- 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
Asmedia ® USB 3.1 Gen 2 controller
- 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
- 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)


Page 1-16 states:

USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)

This connector allows you to connect a USB 3.1 Gen 1 module for 
additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
1including faster data transfer speeds of up to 5 Gb/s, faster charging 
time for USB-chargeable devices, optimized power efficiency, and 
backward compatibility with USB 2.0.


The USB 3.1 Gen 1 module is purchased separately.


Page 1-17 states:

USB 2.0 connectors (10-1 pin USB910; USB1112)

These connectors are for USB 2.0 ports. Connect the USB module cable to 
these connectors, then install the module to a slot opening at the back 
of the system chassis. This USB connector complies with USB 2.0 
specification that supports up to 480 Mb/s connection speed.


The USB 2.0 module is purchased separately.


STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
"USB 2.0 module" (?).



Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
with cables and matching connectors?  Have you connected them to the 
motherboard headers?  Do they work?



Alternatively, if you have an available chassis expansion slot:

https://www.startech.com/en-us/cables/usbplate4


I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
20-pin headers.  Perhaps a USB 3.0 will work (?):


https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W


Or, if you have an available motherboard PCIe slot:

https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express


David

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[David Christensen]

On 2/8/24 12:36, Linux-Fan wrote:

Alexander V. Makartsev writes:

From here on I'd suggest trying the tools from package `f3`.



Thank you for the suggestion -- I was hoping somebody knew of a FOSS 
Debian package that can validate drive capacity:


https://packages.debian.org/bookworm/f3

https://oss.digirati.com.br/f3/

https://fight-flash-fraud.readthedocs.io/en/stable/


David

Re: testing new sdm drive

[David Christensen]

On 2/8/24 11:23, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
...
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.



Do not use a production computer for drive maintenance; especially not 
your primary workstation.  Use a spare computer.



I thought you were going to hook up all the new USB SSD's to a USB hub 
to a SBC, and turn it into a file server, backup server, or some such?



David

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 01:11:05AM +0500, Alexander V. Makartsev wrote:
> On 09.02.2024 00:23, gene heskett wrote:
> > Looks neat. Any chance this will crash my machine? I have other design
> > work going on, and I'd hate to have to start from scratch.
> Well, it will consume CPU cycles for sure, at least to calculate md5 hashes
> and perform I/O on the target drive and RAM.

...unless the device under test starts misbehaving (what, after all, is
the thing we are after). Then, probably, all bets are off. If it "just"
starts reporting bad blocks or just returning corrupted data, I guess
the kernel will cope, but things are... complex ;-)

> I don't think it could crash the system, but the load could be significant
> enough to disturb your work, so
> if I was in your place I'd wait until the machine is free from any work or
> load and then test the new drive.

Sound wise, yes. Perhaps you have a spare raspi you can dedicate to this
boring task. Or an old laptop gathering dust.

BTW, if it was me, I'd skip the file system part and just dd checksummed
blocks to it (and read them back with dd), thus sparing a whole layer of
complexity and difficult to predict behaviour (caching, what not).

BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
chances are it's installed. I'd look into that man page.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Linux-Fan]

Alexander V. Makartsev writes:


On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local  
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke,  
http://www.smartmontools.org>www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0


[...]

Looks like a scam. Probably a reprogrammed controller to falsely report 2TB  
of space to the system.


I support this view :)


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" and  
"blkid" utilities.  /!\
/!\    It could change from 'sdm' to another name  
after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to create  
a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to device  
press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest



From here on I'd suggest trying the tools from package `f3`.


After installing it, find the documentation under
/usr/share/doc/f3/README.rst.gz. Basic usage requires only two commands:

f3write .

Fills the drive until it is full (No Space Left on Device). Umount and re- 
mount it to ensure that data is actually written to the disk. Then switch  
back to /mnt/disktest and read it back using


f3read .

It should output a tabular summary about what could be read successfully and  
what couldn't.


As to whether this affects the stability of the running system: If the drive  
is fake (which I think is a real possibility) then it may as well cause  
hickups in the system. If the work you are doing on the machine is mission- 
critical, don't run tests with suspect hardware on it...


HTH
Linux-Fan

öö

[...]


pgpxY5QIR73gw.pgp
Description: PGP signature

Re: testing new sdm drive

[Alexander V. Makartsev]

On 09.02.2024 00:23, gene heskett wrote:
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.
Well, it will consume CPU cycles for sure, at least to calculate md5 
hashes and perform I/O on the target drive and RAM.
I don't think it could crash the system, but the load could be 
significant enough to disturb your work, so
if I was in your place I'd wait until the machine is free from any work 
or load and then test the new drive.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: testing new sdm drive

[gene heskett]

On 2/8/24 07:22, Alexander V. Makartsev wrote:

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
     $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
     $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
     $ sudo mkdir /mnt/disktest
     $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
     $ cd /mnt/disktest
     $ sudo fallocate -l 1G ./reftestfile
     $ sudo badblocks -w -s -t random ./reftestfile

Now we can use script to create 1830 1GB files and check their checksum:
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

     $ md5sum -b ./reftestfile
     3f2c5fa95492bfaa18f08c801037d80b *./reftestfile

     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

     3f2c5fa95492bfaa18f08c801037d80b *./testfile1
     3f2c5fa95492bfaa18f08c801037d80b *./testfile2
     ...
     3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.


Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.


--
With kindest regards, Alexander.

Thank you Alexander.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[Dan Ritter]

David Christensen wrote: 
> 
> Page 1-16 states:
> 
> USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)
> 
> This connector allows you to connect a USB 3.1 Gen 1 module for additional
> USB 3.1 Gen 1 front or rear panel ports. With an installed USB 3.1 Gen 1
> module, you can enjoy all the benefits of USB 3.1 Gen 1including faster data
> transfer speeds of up to 5 Gb/s, faster charging time for USB-chargeable
> devices, optimized power efficiency, and backward compatibility with USB
> 2.0.
> 
> The USB 3.1 Gen 1 module is purchased separately.
> 
> 
> STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or "USB
> 2.0 module" (?).

USB 3.0 Gen 1 is a rename of USB 3.0.

2x Type A from standard motherboard header:
https://www.newegg.com/p/181-0783-00017?Item=9SIAPY9F266548

-dsr-

Re: testing new sdm drive

[David Christensen]

On 2/8/24 10:24, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

...
Please try again with the drive connected directly to a motherboard USB 
3.0 port.



Error:  The motherboard has no USB 3.0 ports.


Correction:  Please try connecting the drive to each and every 
motherboard USB port to see if and which ports work with the drive and 
smartctl(8).



David

Re: testing new sdm drive

[David Christensen]

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)

Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more 
'-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.



Please try again with the drive connected directly to a motherboard USB 
3.0 port.



I seem to recall that you have a lot of USB devices connected to your 
computer(s).  The Asus PRIME Z370-A II Series manual page ix states:


Intel ® Z370 Chipset
- 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
USB
- 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
Asmedia ® USB 3.1 Gen 2 controller
- 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
- 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)


Page 1-16 states:

USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)

This connector allows you to connect a USB 3.1 Gen 1 module for 
additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
1including faster data transfer speeds of up to 5 Gb/s, faster charging 
time for USB-chargeable devices, optimized power efficiency, and 
backward compatibility with USB 2.0.


The USB 3.1 Gen 1 module is purchased separately.


Page 1-17 states:

USB 2.0 connectors (10-1 pin USB910; USB1112)

These connectors are for USB 2.0 ports. Connect the USB module cable to 
these connectors, then install the module to a slot opening at the back 
of the system chassis. This USB connector complies with USB 2.0 
specification that supports up to 480 Mb/s connection speed.


The USB 2.0 module is purchased separately.


STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
"USB 2.0 module" (?).



Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
with cables and matching connectors?  Have you connected them to the 
motherboard headers?  Do they work?



Alternatively, if you have an available chassis expansion slot:

https://www.startech.com/en-us/cables/usbplate4


I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
20-pin headers.  Perhaps a USB 3.0 will work (?):


https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W


Or, if you have an available motherboard PCIe slot:

https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express


David

Re: testing new sdm drive

[Alexander V. Makartsev]

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest
    $ sudo fallocate -l 1G ./reftestfile
    $ sudo badblocks -w -s -t random ./reftestfile

Now we can use script to create 1830 1GB files and check their checksum:
    $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

    $ md5sum -b ./reftestfile
    3f2c5fa95492bfaa18f08c801037d80b *./reftestfile

    $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

    3f2c5fa95492bfaa18f08c801037d80b *./testfile1
    3f2c5fa95492bfaa18f08c801037d80b *./testfile2
    ...
    3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

testing new sdm drive

[gene heskett]

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more 
'-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Testing storage performance (Was Re: mdraid construction and testing (was: smartctl cannot access my stor...))

[Andy Smith]

Hi Felix,

On Tue, Jan 16, 2024 at 04:50:01PM -0500, Felix Miata wrote:
> What can I use to test what its write speed is? I'm not seeing any option to 
> do so
> in hdparm.

The king of storage performance testing is "fio". It's packaged in
Debian. It's really worth learning a bit about.

What sort of performance were you looking to test?

Bear in mind that not all IO is the same and can have vastly
different performance characteristics. For example, reading data is
generally faster than writing data, because you can take advantages
of several layers of caching in Linux and in your drives.

On HDDs, a streaming read will be much faster than a random read,
because the drive head will get into position once and stream the
data from there, as opposed to having to seek about the platters.
Less of a concern for non-rotational media.

Small writes will go into Linux's buffers and drive buffers and
appear to happen at memory speed, until those buffers are full,
and then you'll start to see the real ability of the underlying
drives. Various types of write IO, e.g. synchronous, bypass cache
and will be slower from the start. There are options for fio to
simulate that.

Typically you care about:

- random read and random write performance as measured in IO
  operations per second (IOPS) at a given mix of read/write and IO
  size, e.g. "100% randreads at 4KiB"

- streaming (sequential) read and write bandwidth in MB/sec at a
  given IO size

- Different levels of concurrency, e.g. queue depth of 1, 8, 64…

A modern HDD doesn't have much concurrency for the simple reason
that it generally has just one arm, whereas a modern NVMe may have
a queue depth of 64 or more.

You might expect 150 IOPS and 150MB/s 4K streaming read out of a
decent HDD, and thousands or millions of IOPSs and more than a GB/s
out of a modern NVMe.

Drive manufacturers often list IOPS and MB/sec figures for 4K IOs in
their spec sheets.

You can target fio at your underlying drives, or at any other block
device, so you can test filesystems, RAID arrays, zfs, etc. Though
obviously the write tests will write data and may destroy the
contents of the device unless done in a filesystem directory.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: mdraid construction and testing (was: smartctl cannot access my stor...)

[Felix Miata]

David Christensen composed on 2024-01-16 13:01 (UTC-0800):

> STFW and RTFM I have seen recommendations for and against using whole 
> disks for RAID and for and against using partitions for RAID.  And, as 
> this in the Internet, there are countless rumors and speculation.  As I 
> switched from mdadm(8) to zfs(8) years ago, perhaps another reader can 
> explain what mdadm(8) does when given whole disks and when given disk 
> partitions.

I've been running RAID1 on pairs of multi-partition disks for well over a 
decade,
first with 320G, then 500G, currently 1T. Since the move to 1T, I've replaced 
both
disks. Both were originally 512/512 v2.0 Hitachis. Now, one is a ST1000NM0011
512l/512p Seagate Constellation, the other a ST1000DM003-1CH1 512l/4096p Seagate
Barracuda.

They've been divided into partitions to comprise 5-6 md devices, currently 6, 
with
small other partitions not parts of any RAID, such as no longer used /boot/s.
Since moving the OS onto an SSD, I have one md device not in use, previously 
used
for swap:

# hdparm -t /dev/md0

/dev/md0:
 Timing buffered disk reads: 554 MB in  3.02 seconds = 183.59 MB/sec
#
What can I use to test what its write speed is? I'm not seeing any option to do 
so
in hdparm.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

On 07.01.24 20:33, songbird wrote:

i see you've solved your issue, but i just wanted to
point out that it works and is ok for people who want to
try it out.

Says who?

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[songbird]

Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond repair, I 
> today tried to just replace it with rEFInd. Installation succeeded 
> without any trouble. But when I start my system, rEFInd just asks me if 
> I want to boot with fwupd or with the still very broken Grub. Am I 
> missing something? Is rEFInd really just something to select between 
> different OSs (and not just different distributions like Grub can very 
> well do) and then gives the rest over to their bootloaders or am I 
> missing something so rEFInd will take over all of Grubs jobs?

...

  i don't do encryption or raid so i keep things pretty
simple.

  i've been using refind for years without issues.  i also
have grub installed so if either of them breaks the other
is still likely going to work.

  i've also set it up so that each can be reached from the
other through their menus.

  i see you've solved your issue, but i just wanted to 
point out that it works and is ok for people who want to
try it out.


  songbird

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 04.01.24 19:49, Richard Rosner wrote:

On 04.01.24 19:02, David Wright wrote:

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.


Let's hope the mailing list let's this go through.

It did, but since it seems to have been malformed yet again, let's try 
again.


Keep in mind, this is based on the assumption that your whole / 
partition is LUKS encrypted (in my case now LUKS2). "root partition 
UUID1" is the UUID that's shown in Disks or on the Grub screen for the 
decryption password prompt. Now, I can't say for sure what 
"root-partition-UUID2" is, but that's what seems to be symlinked to 
/dev/dm-0 and with blkid, one of the entries will look like this:



/dev/mapper/luks-: UUID="" 
BLOCK_SIZE="4096" TYPE="ext4"



So maybe it's just some kind of virtual UUID for the decrypted root 
partition.


Adding to that, "root partition UUID1.1" is basically the same as  
UUID1.1, just without dashes. So it's the same format as Grub shows for 
the ususal bootup password prompt. Let's hope this time this is the 
right one.


#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u 
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

else
  search --no-floppy --fs-uuid --set=root 
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u 
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

else
  search --no-floppy --fs-uuid --set=root 
fi
insmod png
if background_image 
/usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; then

  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
    set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 'gnulinux-simple-UUID2>' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    cryptomount -u 
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 root=UUID=UUID2> ro  quiet root=/dev/mapper/luks- splash 
resume=/dev/mapper/luks-

    echo    'Loading initial ramdisk ...'
 

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 07.01.24 18:07, David Wright wrote:

I compared your new grub.cfg with mine (suitably decimated and edited)
and the significant differences are very few; extra modules are loaded:
cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256.
Myset root='hd0,gpt5' is replaced by
   set root='cryptouuid/'
and my
   --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5
is replaced by
   hint='cryptouuid/'

Unlike the first version of grub.cfg that you pasted earlier:

   cryptomount -u 
   set root='cryptouuid/

there's no cryptomount in your new one. I'm guessing that means that
the LUKS2 partition has been decrypted by Grub before grub.cfg is
commanded. Do you now get just the one prompt for the passphrase
when you boot? (I'm not very familiar with how far encrypted
/boot has progressed.)


There was always only one prompt for the passphrase when boot was 
working on its own. Only if you had to manually decrypt all partitions, 
you'd need to enter it for every encrypted partition there is — probably 
because you don't necessarily need to have the same password for 
everything. There might be an option to have it reuse the key, but I 
have yet to find that.


Also, that the cryptomount lines are missing must be why Grub was still 
a bit unreliable. I'll write my current grub.cfg in a separate message, 
as they are back now after some experiments with rEFInd, systemd-boot 
and trying to get resume from hibernation to work reliably.



The other difference in the earlier, pasted grub.cfg is that its
linux line was extremely long, and looked as though a large amount
of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or
GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub?
I commented previously on the multiple root= parameters, and have
also noticed that the recovery mode lines had "single" duplicated.
I presume all that configuration stuff has gone away now.


Well, that bunch of text is necessary, since grub has to communicate the 
location of the root and the swap partitions to the kernel, so of course 
they are automatically included in the default/grub. The last one there 
is just a little fix for better handling very old Synaptic touchpads in 
Wayland.


In my current grub.cfg the multiple root= entries in one line seem to be 
gone, but there are still multiple single in the recovery parts.



I somehow doubt whether all this will be any help, as you're working
well beyond my experience, and somewhere near the cutting edge of Grub.
Just shows how hopelessly outdated Grub is and that it sorely needs a 
replacement — and a better experience in replacing it. Grub 2.12 was 
just released in December. On the other hand, LUKS was originally 
released in 2004, LUKS2 followed in 2018 and became the default with 
cryptsetup 2.1.0 in early 2019 — though Debian seems to ignore that, 
since the installer still by default creates LUKS1 volumes. Also, by 
default, LUKS2 uses Argon2 key derivation function — unsupported even by 
Grub 2.12. All this in a time when smartphones have been encrypted for 
years by default, so have MacBooks and even Windows is slowing making it 
a default. Not to mention the fact that Linux distributions are offering 
encryption in their installers for many years now, with a few even 
making it a default, like Pop.

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Thu 04 Jan 2024 at 19:49:43 (+0100), Richard Rosner wrote:
> On 04.01.24 19:02, David Wright wrote:
> > Could you post the new grub.cfg file, so that people running testing,
> > and following along the thread later, can see how boot-repair fixed it?
> 
> Keep in mind, this is based on the assumption that your whole /
> partition is LUKS encrypted (in my case now LUKS2).
> "root-partition-UUID" is the UUID that's shown in Disks or on the Grub
> screen for the decryption password prompt. Now, I can't say for sure
> what "root-partition-UUID2" is, but that's what seems to be symlinked
> to /dev/dm-0 and with blkid, one of the entries will look like this:
> 
> /dev/mapper/luks-: UUID=""
> BLOCK_SIZE="4096" TYPE="ext4"
> 
> So maybe it's just some kind of virtual UUID for the decrypted root
> partition.

(I would have thought that you'd know encrypted filesystems have UUIDs.)

I compared your new grub.cfg with mine (suitably decimated and edited)
and the significant differences are very few; extra modules are loaded:
cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256.
Myset root='hd0,gpt5' is replaced by
  set root='cryptouuid/'
and my
  --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5
is replaced by
  hint='cryptouuid/'

Unlike the first version of grub.cfg that you pasted earlier:

  cryptomount -u 
  set root='cryptouuid/

there's no cryptomount in your new one. I'm guessing that means that
the LUKS2 partition has been decrypted by Grub before grub.cfg is
commanded. Do you now get just the one prompt for the passphrase
when you boot? (I'm not very familiar with how far encrypted
/boot has progressed.)

The other difference in the earlier, pasted grub.cfg is that its
linux line was extremely long, and looked as though a large amount
of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or
GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub?
I commented previously on the multiple root= parameters, and have
also noticed that the recovery mode lines had "single" duplicated.
I presume all that configuration stuff has gone away now.

I passed over a couple of other, minor differences that probably don't
affect things, like the pasted grub.cfg allowing for decrypting / to
get at fonts in /usr/share/grub/, and the similar code (extra relative
to mine) in 05_debian_theme for prettyfying the main Grub screen.

I somehow doubt whether all this will be any help, as you're working
well beyond my experience, and somewhere near the cutting edge of Grub.

Cheers,
David.

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Thu, Jan 4, 2024 at 6:18 PM Joel Roth  wrote:
>
> On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote:
> > In theory, it should
> > be as simple as refind-install. So the only reason I could guess to be the
> > reason would be that rEFInd might not be capable of handling LUKS, which
> > would be quite disappointing.
>
> My experiences are with vanilla filesystems only. LUKS
> obviously has specific requirements. Perhaps you could try
> having a root partition that is unencrypted?

Be careful of that. Someone who is encrypting the filesystem likely
has password protected the firmware, disabled booting from USB sticks,
and disabled the root account so a rescue console cannot be used to
sidestep access restrictions. That is, you don't want to hand out a
passwordless root shell in rescue mode. Also see
.

Jeff

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 04.01.24 19:02, David Wright wrote:

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.


Let's hope the mailing list let's this go through.


Keep in mind, this is based on the assumption that your whole / 
partition is LUKS encrypted (in my case now LUKS2). 
"root-partition-UUID" is the UUID that's shown in Disks or on the Grub 
screen for the decryption password prompt. Now, I can't say for sure 
what "root-partition-UUID2" is, but that's what seems to be symlinked to 
/dev/dm-0 and with blkid, one of the entries will look like this:



/dev/mapper/luks-: UUID="" 
BLOCK_SIZE="4096" TYPE="ext4"



So maybe it's just some kind of virtual UUID for the decrypted root 
partition.



#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if loadfont unicode ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

else
  search --no-floppy --fs-uuid --set=root 
fi
insmod png
if background_image /boot/grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
    set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'gnulinux-simple-' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 
root=UUID= ro  quiet

    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-' {
    menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class 
debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.5.0-5-amd64-advanced-' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 
root=UUID= ro  quiet

    echo    'Loading initial ramdis

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Wed 03 Jan 2024 at 22:00:20 (+0100), Richard Rosner wrote:
> On 03.01.24 21:04, Eddie wrote:
> > On 1/3/24 14:23, Richard Rosner wrote:
> > > So, since for whatever reason Grub seems to be broken beyond
> > > repair, I today tried to just replace it with rEFInd.
> > > Installation succeeded without any trouble. But when I start
> > > my system, rEFInd just asks me if I want to boot with fwupd or
> > > with the still very broken Grub. Am I missing something? Is
> > > rEFInd really just something to select between different OSs
> > > (and not just different distributions like Grub can very well
> > > do) and then gives the rest over to their bootloaders or am I
> > > missing something so rEFInd will take over all of Grubs jobs?
> > 
> > I have had very good results using "Boot-Repair" software to
> > recover Grub difficulties.
> > 
> Thanks, this actually did the job. I don't know what it was, but my
> guess is it was the step "purge Grub before reinstalling it".
> 
> 
> PS: rewrote to the old subject, as this is clearly an answer to the
> original problem, as it doesn't have anything to do with replacing
> Grub all together.

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Joel Roth]

On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote:
> In theory, it should
> be as simple as refind-install. So the only reason I could guess to be the
> reason would be that rEFInd might not be capable of handling LUKS, which
> would be quite disappointing. 

My experiences are with vanilla filesystems only. LUKS
obviously has specific requirements. Perhaps you could try
having a root partition that is unencrypted?

-- 
Joel Roth

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Well, that was a bust. I accidentally didn't just format the EFI 
partition, but deleted it. So I re-created it with the help of disks and 
gparted (to leave the first 3 MB empty, I remeber that being a fix added 
kinda recently to combat bad BIOS/EFI implementations, since Windows is 
doing the same and nobody could come up with anything better.


Anyways, after installing rEFInd with no grub present, it would boot 
into rEFInd, but that's it. No boot options, nothing under F2. Also, I 
couldn't find anything helpful on the Arch Wiki page for this. In 
theory, it should be as simple as refind-install. So the only reason I 
could guess to be the reason would be that rEFInd might not be capable 
of handling LUKS, which would be quite disappointing. Maybe I'll take a 
look at systemd-boot in the next days, as I don't need any customization 
anyways, and maybe it can handle encryption (or better decryption) 
better than Grub — especially with LUKS2 grub seems a bit unreasonably slow.


On 04.01.24 11:56, Richard Rosner wrote:
Good to know that it should be possible. But as mentioned, these 
symbols only offer me to boot from grub or fwupd. F2 also doesn't show 
that much more, it merely gives me the option to boot into the BIOS 
settings. Maybe I'll have to completely purge all Grub packages, wipe 
the existing EFI partition and then try to install rEFInd. I'll have 
to check.


On Thu, Jan 4, 2024, 09:29 Joel Roth  wrote:

On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond
repair, I today
> tried to just replace it with rEFInd. Installation succeeded
without any
> trouble. But when I start my system, rEFInd just asks me if I
want to boot
> with fwupd or with the still very broken Grub. Am I missing
something? Is
> rEFInd really just something to select between different OSs
(and not just
> different distributions like Grub can very well do) and then
gives the rest
> over to their bootloaders or am I missing something so rEFInd
will take over
> all of Grubs jobs?

I boot my debian-based system with rEFInd.  Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present.

rEFInd installs into  EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.




> On 01.01.24 21:45, Richard Rosner wrote:
> >
> >
> > On 01.01.24 21:20, Richard Rosner wrote:
> > >
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived
anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how
to even do
> > > > > this, it might as well be a documentation for users
having such
> > > > > troubles in the future.
> > > > >
> > > > > Also, besides the way that I have no clue how it would
have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply
don't see
> > > > > anything wrong with it anyways. So I can't even look at
the grub
> > > > > settings files grub.cfg is being generated from to check
where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually
with into
> > > > /etc/grub.d/40_custom, observing the comments there, and
also into
> > > > grub.cfg itself at the appropriate place (near the
bottom). The
> > > > former is so that Grub includes it in any new grub.cfg
that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the
UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should
Grub have,
> > besides the fact that I can't even be entirely sure Grub is to
blame and
> > not something else.

-- 
Joel Roth

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

You should really re-read the FAQ that was sent in just two days ago...

On January 4, 2024 11:58:28 AM GMT+01:00, Jeffrey Walton  
wrote:
>On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner  wrote:
>>
>> Wow, what a bunch of unhelpful comments.
>>
>> First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
>> repair" in fact was the very fitting term.
>
>Here was Eddie's comment" I have had very good results using
>"Boot-Repair" software to recover Grub difficulties."
>
>"Broken beyond repair" seems to be context dependent. And it seems to
>depend on the user.
>
>> Second, have you maybe considered that I've already read the home page of 
>> rEFInd and came to the same conclusion? Besides the fact that the page is 
>> virtually unreadable - both from a visual and a content point of view - I 
>> have yet to find anything indicating what it is actually capable of and what 
>> not. Because as far as I can tell, it should be able to do what I want it to 
>> do.
>
>No. You did not state it. And you did not cite something you did not
>understand. I think you are full of shit.
>
>> So please, if you don't have anything to add other than snarky remarks, just 
>> don't answer.
>
>You mean like: "So, since for whatever reason Grub seems to be broken
>beyond repair"?
>
>Jeff
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner  wrote:
>
> Wow, what a bunch of unhelpful comments.
>
> First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
> repair" in fact was the very fitting term.

Here was Eddie's comment" I have had very good results using
"Boot-Repair" software to recover Grub difficulties."

"Broken beyond repair" seems to be context dependent. And it seems to
depend on the user.

> Second, have you maybe considered that I've already read the home page of 
> rEFInd and came to the same conclusion? Besides the fact that the page is 
> virtually unreadable - both from a visual and a content point of view - I 
> have yet to find anything indicating what it is actually capable of and what 
> not. Because as far as I can tell, it should be able to do what I want it to 
> do.

No. You did not state it. And you did not cite something you did not
understand. I think you are full of shit.

> So please, if you don't have anything to add other than snarky remarks, just 
> don't answer.

You mean like: "So, since for whatever reason Grub seems to be broken
beyond repair"?

Jeff

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Good to know that it should be possible. But as mentioned, these symbols
only offer me to boot from grub or fwupd. F2 also doesn't show that much
more, it merely gives me the option to boot into the BIOS settings. Maybe
I'll have to completely purge all Grub packages, wipe the existing EFI
partition and then try to install rEFInd. I'll have to check.

On Thu, Jan 4, 2024, 09:29 Joel Roth  wrote:

> On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> > So, since for whatever reason Grub seems to be broken beyond repair, I
> today
> > tried to just replace it with rEFInd. Installation succeeded without any
> > trouble. But when I start my system, rEFInd just asks me if I want to
> boot
> > with fwupd or with the still very broken Grub. Am I missing something? Is
> > rEFInd really just something to select between different OSs (and not
> just
> > different distributions like Grub can very well do) and then gives the
> rest
> > over to their bootloaders or am I missing something so rEFInd will take
> over
> > all of Grubs jobs?
>
> I boot my debian-based system with rEFInd.  Grub is not
> present. A couple big icons show on the boot screen. The
> small print at the bottom mentions hit F2 for more options.
> On my system, F2 offers a selection among all kernels
> present.
>
> rEFInd installs into  EFI/refind/ in the EFI partition.
> I originally encountered it looking for something to
> boot debian on a Intel Mac. It's been trouble-free.
>
>
>
>
> > On 01.01.24 21:45, Richard Rosner wrote:
> > >
> > >
> > > On 01.01.24 21:20, Richard Rosner wrote:
> > > >
> > > > On 01.01.24 20:30, David Wright wrote:
> > > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > > I can boot by hand, but since this is all archived anyways and
> it's
> > > > > > uneccessarily difficult to find some sort of guide how to even do
> > > > > > this, it might as well be a documentation for users having such
> > > > > > troubles in the future.
> > > > > >
> > > > > > Also, besides the way that I have no clue how it would have to
> look
> > > > > > like to set up a paragraph in the grub.cfg, I simply don't see
> > > > > > anything wrong with it anyways. So I can't even look at the grub
> > > > > > settings files grub.cfg is being generated from to check where
> the
> > > > > > error lies.
> > > > > You append the commands that you used to boot manually with into
> > > > > /etc/grub.d/40_custom, observing the comments there, and also into
> > > > > grub.cfg itself at the appropriate place (near the bottom). The
> > > > > former is so that Grub includes it in any new grub.cfg that you
> > > > > create.
> > > > Good to know.
> > > Edit:, never mind. Tried that, it still booted straight to the UEFI
> BIOS
> > > menu after entering my password. At this point, I'm seriously
> > > considering slapping rEFInd on it and pray that it picks up on
> > > everything automatically and fix the situation. But so should Grub
> have,
> > > besides the fact that I can't even be entirely sure Grub is to blame
> and
> > > not something else.
>
> --
> Joel Roth
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Pocket]

On 1/4/24 02:45, Richard Rosner wrote:

Wow, what a bunch of unhelpful comments.

First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
repair" in fact was the very fitting term.


Second, have you maybe considered that I've already read the home page 
of rEFInd and came to the same conclusion? Besides the fact that the 
page is virtually unreadable - both from a visual and a content point of 
view - I have yet to find anything indicating what it is actually 
capable of and what not. Because as far as I can tell, it should be able 
to do what I want it to do.





Have you looked at this?

https://wiki.archlinux.org/title/REFInd

I don't know if it will help as I do not use REFInd nor have I any 
experience with it.


--
Hindi madali ang maging ako

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Joel Roth]

On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond repair, I today
> tried to just replace it with rEFInd. Installation succeeded without any
> trouble. But when I start my system, rEFInd just asks me if I want to boot
> with fwupd or with the still very broken Grub. Am I missing something? Is
> rEFInd really just something to select between different OSs (and not just
> different distributions like Grub can very well do) and then gives the rest
> over to their bootloaders or am I missing something so rEFInd will take over
> all of Grubs jobs?

I boot my debian-based system with rEFInd.  Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present. 

rEFInd installs into  EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.




> On 01.01.24 21:45, Richard Rosner wrote:
> > 
> > 
> > On 01.01.24 21:20, Richard Rosner wrote:
> > > 
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how to even do
> > > > > this, it might as well be a documentation for users having such
> > > > > troubles in the future.
> > > > > 
> > > > > Also, besides the way that I have no clue how it would have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply don't see
> > > > > anything wrong with it anyways. So I can't even look at the grub
> > > > > settings files grub.cfg is being generated from to check where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually with into
> > > > /etc/grub.d/40_custom, observing the comments there, and also into
> > > > grub.cfg itself at the appropriate place (near the bottom). The
> > > > former is so that Grub includes it in any new grub.cfg that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should Grub have,
> > besides the fact that I can't even be entirely sure Grub is to blame and
> > not something else.

-- 
Joel Roth

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I have kept the referral to the old problem in the topic for a reason. Been
there, done that. I'm not entirely sure how, but boot-repair was the only
thing that was able to fix Grub. Before that I've reinstalled it countless
times, thanks.

But since this is very much not an answer to the question at hand, but to
the original question - and as such an entirely different topic - I'm
rewriting this to the old topic too.

On Thu, Jan 4, 2024, 02:12 Jeffrey Walton  wrote:

> On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
> wrote:
> >
> > So, since for whatever reason Grub seems to be broken beyond repair,
>
> I seriously doubt this is the case. I'm guessing the problem lies
> elsewhere.
>
> > I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
>
> The rEFInd website is at . I'm
> guessing you have not taken time to read about it based on your
> questions.
>
> Jeff
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Wow, what a bunch of unhelpful comments.

First, if it wasn't for Eddie recommending boot-repair, "broken beyond
repair" in fact was the very fitting term.

Second, have you maybe considered that I've already read the home page of
rEFInd and came to the same conclusion? Besides the fact that the page is
virtually unreadable - both from a visual and a content point of view - I
have yet to find anything indicating what it is actually capable of and
what not. Because as far as I can tell, it should be able to do what I want
it to do.

So please, if you don't have anything to add other than snarky remarks,
just don't answer.

On Thu, Jan 4, 2024, 02:12 Jeffrey Walton  wrote:

> On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
> wrote:
> >
> > So, since for whatever reason Grub seems to be broken beyond repair,
>
> I seriously doubt this is the case. I'm guessing the problem lies
> elsewhere.
>
> > I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
>
> The rEFInd website is at . I'm
> guessing you have not taken time to read about it based on your
> questions.
>
> Jeff
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Timothy M Butterworth]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
wrote:

> So, since for whatever reason Grub seems to be broken beyond repair,
>

I am not sure what you mean by "broken beyond repair." I have no issues
with Grub on Debian 12 on AMD64. I had no issues with Grub on Debian 11 or
Debian 10 on AMD64 either. I also had no issues upgrading from Debian 11 to
Debian 12. Is it possible that you simply have a corrupted hard drive and
simply need to reinstall from scratch?

You can download a Debian LiveCD for AMD64 from here:
https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/ you can
then boot with it and mount your drive and copy your home directory to a
USB portable drive. When you reinstall I would create a separate partition
for /home. That way in the future you can always reinstall and just tell
the system to mount the existing /home partition.


> I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
> On 01.01.24 21:45, Richard Rosner wrote:
>
>
> On 01.01.24 21:20, Richard Rosner wrote:
>
>
> On 01.01.24 20:30, David Wright wrote:
>
> On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
>
> On 01.01.24 18:13, David Wright wrote:
> I can boot by hand, but since this is all archived anyways and it's
> uneccessarily difficult to find some sort of guide how to even do
> this, it might as well be a documentation for users having such
> troubles in the future.
>
> Also, besides the way that I have no clue how it would have to look
> like to set up a paragraph in the grub.cfg, I simply don't see
> anything wrong with it anyways. So I can't even look at the grub
> settings files grub.cfg is being generated from to check where the
> error lies.
>
> You append the commands that you used to boot manually with into
> /etc/grub.d/40_custom, observing the comments there, and also into
> grub.cfg itself at the appropriate place (near the bottom). The
> former is so that Grub includes it in any new grub.cfg that you
> create.
>
> Good to know.
>
> Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS
> menu after entering my password. At this point, I'm seriously considering
> slapping rEFInd on it and pray that it picks up on everything automatically
> and fix the situation. But so should Grub have, besides the fact that I
> can't even be entirely sure Grub is to blame and not something else.
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner  wrote:
>
> So, since for whatever reason Grub seems to be broken beyond repair,

I seriously doubt this is the case. I'm guessing the problem lies elsewhere.

> I today tried to just replace it with rEFInd. Installation succeeded without 
> any trouble. But when I start my system, rEFInd just asks me if I want to 
> boot with fwupd or with the still very broken Grub. Am I missing something? 
> Is rEFInd really just something to select between different OSs (and not just 
> different distributions like Grub can very well do) and then gives the rest 
> over to their bootloaders or am I missing something so rEFInd will take over 
> all of Grubs jobs?

The rEFInd website is at . I'm
guessing you have not taken time to read about it based on your
questions.

Jeff

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

Thanks, this actually did the job. I don't know what it was, but my 
guess is it was the step "purge Grub before reinstalling it".



PS: rewrote to the old subject, as this is clearly an answer to the 
original problem, as it doesn't have anything to do with replacing Grub 
all together.


On 03.01.24 21:04, Eddie wrote:
I have had very good results using "Boot-Repair" software to recover 
Grub difficulties.


Eddie

On 1/3/24 14:23, Richard Rosner wrote:
So, since for whatever reason Grub seems to be broken beyond repair, 
I today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me 
if I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can 
very well do) and then gives the rest over to their bootloaders or am 
I missing something so rEFInd will take over all of Grubs jobs?

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Eddie]

I have had very good results using "Boot-Repair" software to recover 
Grub difficulties.


Eddie

On 1/3/24 14:23, Richard Rosner wrote:
So, since for whatever reason Grub seems to be broken beyond repair, I 
today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me if 
I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can very 
well do) and then gives the rest over to their bootloaders or am I 
missing something so rEFInd will take over all of Grubs jobs?

Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

So, since for whatever reason Grub seems to be broken beyond repair, I 
today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me if 
I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can very 
well do) and then gives the rest over to their bootloaders or am I 
missing something so rEFInd will take over all of Grubs jobs?


On 01.01.24 21:45, Richard Rosner wrote:



On 01.01.24 21:20, Richard Rosner wrote:


On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.
Edit:, never mind. Tried that, it still booted straight to the UEFI 
BIOS menu after entering my password. At this point, I'm seriously 
considering slapping rEFInd on it and pray that it picks up on 
everything automatically and fix the situation. But so should Grub 
have, besides the fact that I can't even be entirely sure Grub is to 
blame and not something else.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 01.01.24 21:20, Richard Rosner wrote:


On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.
Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS 
menu after entering my password. At this point, I'm seriously 
considering slapping rEFInd on it and pray that it picks up on 
everything automatically and fix the situation. But so should Grub have, 
besides the fact that I can't even be entirely sure Grub is to blame and 
not something else.