Hi all!
shIt happened!
I had 2 OSes on the same SSD disk.
All of a sudden Siduction warned me my root dev is full and has no free space.
I just opened Gparted and deleted the second OS, increased my root partition and created a new SWAP file.
Updated grub.
When booting I started to get "mdadm no arrays found..." error.
I noticed UUID the system could not find and found in fstab that the lost UUID is the one of the old SWAP file. I change the UUID to the new one in fstab. OK.
But this resolved the issue only partially. I still get mdadm error while booting.
I tried to update initramfs, but cannot because initramfs looks for the old UUID.
I'm guilty, my fault, but what shall I do to get rid of this error?
@alexsid
> But this resolved the issue only partially. I still get mdadm error while booting.
This indicates, that initrd has trouble finding the root device. An update-grub could
help.
> I tried to update initramfs, but cannot because initramfs looks for the old UUID.
Please provide the command together with the error messages.
I think, there is nothing special to provide.
When booting, I got many lines of the following message
mdadm no arrays found in config file... etc
Than the normal green messages go and the system boots in
sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
cryptsetup: ERROR: Couldn't resolve device
UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
in /etc/default/grub
i change resume uuid to the new one. The swap PARTITION is active (checked in gparted).
The system still looks for the old uuid. How to correct this?
I added new swap partition uuid to etc/default/grub file
resume=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c
and I get the following error trying to update grub
sudo update-grub
/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not found
@alexsid
> sudo update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
> cryptsetup: ERROR: Couldn't resolve device
> UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
What about:
$ cat /etc/initramfs-tools/conf.d/resume
cat /etc/initramfs-tools/conf.d/resume
This command returns no answer
Where else can update-initramfs get this information from?
$ sudo grep -r d0a9d5f0-05ea-4b68-b279-015c623e387f /etc/*
Quote from: Teriarch on Yesterday at 00:47:21Where else can update-initramfs get this information from?
$ sudo grep -r d0a9d5f0-05ea-4b68-b279-015c623e387f /etc/*
THANK YOU!
sudo grep -r d0a9d5f0-05ea-4b68-b279-015c623e387f /etc/*
Returned the followint lines:
/etc/default/grub.ucf-dist:GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f systemd.show_status=1"
/etc/fstab.save:UUID=23CC34C6703D21EC /wd/ntfs auto defaults,nofail,x-systemd.automount 0 2d0a9d5f0-05ea-4b68-b279-015c623e387f swap swap defaults 0 0
So, the old UUID comes from two backup files:
/etc/default/grub.ucf-dist
/etc/fstab.save
Can I remove both files safely or shall I insert the new UUID in them manually?
Or how to update them by force?
sudo update-grub
returns the following message with the new UUID (despite of the fact I've already added it to the /ets/default/grub)
/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not found
How to correct this?
(https://i.imgur.com/3eFwdrkt.png) (https://i.imgur.com/3eFwdrk.png) (https://i.imgur.com/rHv0Gbit.png) (https://i.imgur.com/rHv0Gbi.png)
Das erleichtert das lesen von Code, das solltet Ihr üben! Danke.
@alexsid
Let's try unklarer's suggestion:
/etc/default/grub.ucf-dist:GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=d0a9d5f0-05ea-4b68-b279-015c623e387fgrub.ufc-dist is the maintainer's backup of your config file during the installation of new grub.
Obviously you have a new one, so this one is not used, however, you could compare them just in case:
$ diff /etc/default/grub /etc/default/grub.ufc-distThe same goes for /etc/fstab and /etc/fstab.save.
/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not foundI am a little worried about the character '#' at the end of the 'not found' line. Can you check?
PS.:
And while we're at it: Your line
/etc/fstab.save:UUID=23CC34C6703D21EC /wd/ntfs auto defaults,nofail,x-systemd.automount 0 2d0a9d5f0-05ea-4b68-b279-015c623e387f swap swap defaults 0 0
doesn't make sense. There should be a line break between '0 2' and 'd0a0' and I am also missing
a UUID= after the missing line break.
@unklarer
Happy now?
Quote from: Teriarch@unklarer
Happy now?
Perfekt! :D
I deleted
/etc/default/grub.ucf-dist and /etc/fstab.save
so now
sudo grep -r d0a9d5f0-05ea-4b68-b279-015c623e387f /etc/*
returns nothing.
The file
/etc/default/grub
contains the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c systemd.show_status=1"
But sudo update-grub returns
/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not found
with the # at the end
I have no idea where that mark # emerged from
cat /etc/initramfs-tools/conf.d/resume
returns the right UUID
RESUME=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c
sudo update-initramfs -u
returns the same old UUID
update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
cryptsetup: ERROR: Couldn't resolve device
UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
I HAVE NO ENCRYPTED DRIVES, Volumes etc!!!
Where to look for the error?
Yes, I can reinstall the system to get rid of all the errors at once, but on that route I would not aquire new knowledge. But I need help. Cannot find anything useful in the Internet.
@alexsid
Just to be sure: What's the output of
$ ls -la /dev/disk/by-uuidWe have to find the source of the d0a9d5f0-05ea-4b68-b279-015c623e387f UUID.
And in order to rule out hidden characters ("\r", etc.) in /etc/default/grub:
$ cat /etc/default/grub if that doesn't reveal too much personal information.
Hi! Thank you for your help!
$ ls -la /dev/disk/by-uuidShows NO old UUID
cat /etc/default/grub
returned VERY INTERESTING result
Just look at the very first line! How did the new UUID get there? It goes BEFORE the commented line "# If you change..." How did it get there?
f367fdb7-62c0-4ecf-83de-c645d598287c# If you change this file or any /etc/default/grub.d/*.cfg file,
# run 'update-grub' afterwards to update /boot/grub/grub.cfg.
# For full documentation of the options in these files, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR='siduction'
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c systemd.show_status=1"
GRUB_CMDLINE_LINUX=""
# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE/GOP/UGA
# you can see them in real GRUB with the command `videoinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
GRUB_DISABLE_SUBMENU=y
So I removed the UUID from the first line, and could smoothly update grub. So, update-grub works now.
Still cannot update initramfs.
update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
cryptsetup: ERROR: Couldn't resolve device
UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
The old UUID presents inside the /proc/cmdline
file as a RESUME parameter. The problem is how to update this file? Shall I switch to the root environment or how? Shall I somehow restart systemd?
I HAVE JUST MADE A GREAT DISCOVERY To update the cmdline we must to REBOOT the comp! So
1. the mdadm error disappeared
2. initramfs updated smoothly!
3. Tons of time and tunings were saved!
THANK YOU SO MUCH!
PS One problem still persists: WHEN do we get the honor to use Siduction 2026? :-)
Now that you solved it, here is another method for debugging the initramfs creation:
sudo sh -x /usr/sbin/update-initramfs -c -k 7.1.4-1-siduction-amd64 2>&1 | grep -B 5 -A 2 d0a9d5f0This command should have revealed, where the information is coming from. Anyway, I am glad
the problem has finally found its solution!
PS.:
> One problem spersists: WHEN do we get the honor to use Siduction 2026? :-)
Great question, I wonder whether good old pyfll plays nice with brand new python3.14?
Quote from: Teriarch on Yesterday at 19:17:31> [...]
Great question, I wonder whether good old pyfll plays nice with brand new python3.14?
Well, pyfll seems to play along, my last successful build is from July, 5. But the Debian unstable repo is not in a good state. (Too many changes in to short a time? (Python, Qt, Plasma ...)). For some time now, the ISO doesn't build any longer, but as far as I can tell it's not the execution of pyfll by python.
There is a looooong list of problem/error information, but the main 'complaint' is:
2026-07-21 10:56:35,873 INFO b'E: Unable to satisfy dependencies. Reached two conflicting assignments:'
2026-07-21 10:56:35,873 INFO b' 1. libavcodec61:amd64=7:7.1.5-0+deb13u1 is selected for install'
2026-07-21 10:56:35,873 INFO b' 2. libavcodec61:amd64 Depends librav1e0.7 (>= 0.5.1)'
2026-07-21 10:56:35,873 INFO b' but none of the choices are installable:'
2026-07-21 10:56:35,873 INFO b' [no choices]'
Try to change libavcodec61 to libavcodec62 in base-media.
@towo: Thanks for that information. It seems worthy. But guess what, now it's the 'policycoreutils-dbus', which we discussed in another thread. (The dependency missing is 'policycoreutils-python-utils' (in the required version). One Siduction-Member (@Teriarch iirc) provided a (mock) package that is a recompilation of the 'old' package with the required version number. That works well for me. We shortly discussed, if that package could go in a repo (e.g. 'fixed'), but there is the worry, that this package will not be overwritten by a Debian-provided one - the official package.)
For testing purposes I have now explicitly ('-' at the end) deselected 'policycoreutils-dbus' in 'base-security'. Now the ISO is generated, but I cannot tell, what consequences come of the modification. [And I cannot test that today.]
Remove policycoreutils-dbus it's not really needed.
Try this one first:
<https://wormhole.app/Q5L3p1#8BpMI2pEh8fFcbHSYLhZqw>
It contains an additional line:
Provides: policycoreutils-python-utils (= 3.10.1)
Don't know if that solves the dependency problem.