Devuan bug report logs -
#828
devuan-project: After an upgrade (apt update; apt full-upgrade) the PC fails to reboot correctly.
Reply or subscribe to this bug.
Toggle useless messages
Report forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 12:00:01 GMT) (full text, mbox, link).
Acknowledgement sent
to David Haworth <dh@thelancashireman.org>
:
New bug report received and forwarded. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 12:00:02 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):
Package: devuan-project
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Yesterday I updated my OS in order to install AusweisApp2.
On the first attempt I got some errors from the update command, but they
seemed to be related to source packages. The second attempt appeared to
succeed, and AusweisApp2 worked as expected.
Today, after shutdown/reboot, there were lots of error messages. The switch to
high-resolution text display failed, no display manager started and I was dumped
into an 80x25 text screen, from which I could log in.
From the error messages that flashed past, I was able to determine a few problems:
* One of the init scripts fails because it cannot find /sbin/modprobe.
** modprobe appears to be in /usr/sbin now.
** As a workaround, I created a symlink: ln -s /usr/bin/kmod /sbin/modprobe
* Similar failures for depmod and modinfo, similar symlinks created.
* After the above more error messages from /etc/init.d/mountall.sh, /etc/init.d/mountdevsubfs.sh and others
about not being able to find grep and sed. On examination, these files I noticed that the PATH is forced
to /sbin:/bin at the top. grep and sed are in /usr/bin now.
** As a workaround, I edited the files and added :/usr/sbin:/usr/bin to the path.
* After the above I got error messages about eudev. On examination of /etc/init.d/uedev I noticed a similar
problem with PATH, which I worked around in a similar way.
Now my PC boots to a display manager and I can log in as expected. I didn't notice any further error messages.
As you can see, the problems seem to be associated with several packages, so it's hard to pinpoint one package.
My guess is that the programs that I mentioned - modprobe, depmod, modinfo, grep, sed - and many others are
being installed in the wrong place. My reasoning is that, in a traditional Unix system, it should be possible
to place /usr in a separate filesystem that won't be available at the time these scripts are called.
However, on modern hardware, it's hardly ever necessary to have a separate filesystem for /usr, so it
could be simply a path problem in several init scripts of at least two packages (initscripts and eudev)
Best wishes,
Dave
-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 6 (excalibur/ceres)
Release: 6
Codename: excalibur ceres
Architecture: x86_64
Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Information forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 12:46:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Lorenzo <plorenzo@disroot.org>
:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 12:46:10 GMT) (full text, mbox, link).
Message #10 received at 828@bugs.devuan.org (full text, mbox, reply):
On Fri, 05 Jan 2024 12:58:15 +0100
David Haworth <dh@thelancashireman.org> wrote:
> Package: devuan-project
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Yesterday I updated my OS in order to install AusweisApp2.
> On the first attempt I got some errors from the update command, but
> they seemed to be related to source packages. The second attempt
> appeared to succeed, and AusweisApp2 worked as expected.
>
> Today, after shutdown/reboot, there were lots of error messages. The
> switch to high-resolution text display failed, no display manager
> started and I was dumped into an 80x25 text screen, from which I
> could log in.
>
> From the error messages that flashed past, I was able to determine a
> few problems:
>
> * One of the init scripts fails because it cannot find /sbin/modprobe.
> ** modprobe appears to be in /usr/sbin now.
> ** As a workaround, I created a symlink: ln -s /usr/bin/kmod
> /sbin/modprobe
> * Similar failures for depmod and modinfo, similar symlinks created.
>
> * After the above more error messages from /etc/init.d/mountall.sh,
> /etc/init.d/mountdevsubfs.sh and others about not being able to find
> grep and sed. On examination, these files I noticed that the PATH is
> forced to /sbin:/bin at the top. grep and sed are in /usr/bin now. **
> As a workaround, I edited the files and added :/usr/sbin:/usr/bin to
> the path.
>
> * After the above I got error messages about eudev. On examination of
> /etc/init.d/uedev I noticed a similar problem with PATH, which I
> worked around in a similar way.
>
> Now my PC boots to a display manager and I can log in as expected. I
> didn't notice any further error messages.
>
> As you can see, the problems seem to be associated with several
> packages, so it's hard to pinpoint one package.
>
> My guess is that the programs that I mentioned - modprobe, depmod,
> modinfo, grep, sed - and many others are being installed in the wrong
> place. My reasoning is that, in a traditional Unix system, it should
> be possible to place /usr in a separate filesystem that won't be
> available at the time these scripts are called. However, on modern
> hardware, it's hardly ever necessary to have a separate filesystem
> for /usr, so it could be simply a path problem in several init
> scripts of at least two packages (initscripts and eudev)
I agree but split /usr without initrd is not supported (upstream) since
like a decade, it more or less worked until now but Debian is finally
breaking it for good with the usrmerge fallout. See my reply in #827
https://bugs.devuan.org/cgi/bugreport.cgi?bug=827
>
> Best wishes,
> Dave
>
>
> -- System Information:
> Distributor ID: Devuan
> Description: Devuan GNU/Linux 6 (excalibur/ceres)
> Release: 6
> Codename: excalibur ceres
> Architecture: x86_64
>
> Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
Information forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 13:32:07 GMT) (full text, mbox, link).
Acknowledgement sent
to David Haworth <dh@thelancashireman.org>
:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 13:32:07 GMT) (full text, mbox, link).
Message #15 received at 828@bugs.devuan.org (full text, mbox, reply):
Hi Lorenzo,
On 2024-01-05 13:44:25 +0100, Lorenzo wrote:
> I agree but split /usr without initrd is not supported (upstream) since
> like a decade, it more or less worked until now but Debian is finally
> breaking it for good with the usrmerge fallout. See my reply in #827
> https://bugs.devuan.org/cgi/bugreport.cgi?bug=827
Don't get me wrong - I don't have a split system like that.
I was just wondering what a "correct" solution would look like.
Best wishes,
Dave
Information forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 15:00:02 GMT) (full text, mbox, link).
Acknowledgement sent
to David Haworth <dh@thelancashireman.org>
:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 15:00:08 GMT) (full text, mbox, link).
Message #20 received at 828@bugs.devuan.org (full text, mbox, reply):
Some more information:
/dev/loop0 /dev/loop1 etc. are missing. It might be related to the
eudev problem.
Dave
Information forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 16:40:12 GMT) (full text, mbox, link).
Acknowledgement sent
to David Haworth <dh@thelancashireman.org>
:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 16:40:12 GMT) (full text, mbox, link).
Message #25 received at 828@bugs.devuan.org (full text, mbox, reply):
Hi,
the cause of the missing loop devices was that the loop kernel
module wasn't loaded.
Workaround:
modprobe /lib/modules/6.1.0-1-amd64/kernel/drivers/block/loop.ko
Information forwarded
to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>
:
bug#828
; Package devuan-project
.
(Fri, 05 Jan 2024 17:08:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Lorenzo <plorenzo@disroot.org>
:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>
.
(Fri, 05 Jan 2024 17:08:03 GMT) (full text, mbox, link).
Message #30 received at 828@bugs.devuan.org (full text, mbox, reply):
On Fri, 5 Jan 2024 14:28:26 +0100
David Haworth <dh@thelancashireman.org> wrote:
> Hi Lorenzo,
>
> On 2024-01-05 13:44:25 +0100, Lorenzo wrote:
> > I agree but split /usr without initrd is not supported (upstream)
> > since like a decade, it more or less worked until now but Debian is
> > finally breaking it for good with the usrmerge fallout. See my
> > reply in #827 https://bugs.devuan.org/cgi/bugreport.cgi?bug=827
>
> Don't get me wrong - I don't have a split system like that.
> I was just wondering what a "correct" solution would look like.
I think the safest thing is to merge your system, by installing
the usrmerge package; it will move stuff for you and turn /bin
/sbin /lib into symlinks to their /usr/* conterparts.
(example /bin ---> /usr/bin)
This way you go to the layout that is officially supported
by Debian and all this trouble will disappear.
If for some reason, you don't want to do that, expect more
breakage in the incoming weeks. You can try to counter that
with symlinks or by extending the PATH var in scripts,
removing hardcoded paths and so but I'm not sure it will be
sustainable.
Note that while Debian decided to move binaries inside packages,
they decided to not break the amd64 ABI, so binaries can still
use /lib*/ld-linux-x86-64.so.2 as intepreter, and scripts will
keep using /bin/sh. I'm really not sure that will be possible
to create symlinks with 'ln' when /lib/ is empty.. prepare a
rescue system to repair the links, just in case.
Lorenzo
>
> Best wishes,
> Dave
Added indication that 828 affects firmware-realtek,linux-headers-6.6.8-amd64,kmod,sed,initramfs-tools-core,netcat-traditional
Request was from Mark Hindley <mark@hindley.org.uk>
to control@bugs.devuan.org
.
(Wed, 20 Mar 2024 11:56:02 GMT) (full text, mbox, link).
Message #35 received at 812-done@bugs.devuan.org (full text, mbox, reply):
Merged /usr is now enforced by base-files 13devuan4 and handled by debootstrap
1.0.134devuan2. Both of these versions are present in ceres and excalibur:
base-files | 13devuan4 | excalibur | source, all
base-files | 13devuan4 | unstable | source, all
debootstrap | 1.0.134devuan2 | excalibur | source, all
debootstrap | 1.0.134devuan2 | unstable | source, all
Golinux also posted an announcement[1] on the forum.
Therefore I am closing these reports as fixed.
Mark
[1] https://dev1galaxy.org/viewtopic.php?id=6435
Send a report that this bug log contains spam.