Unable to modify fstab file in Leap Micro after disk replacement in RAID1

bartk · April 18, 2025, 2:29pm

Hi everyone,

I’m currently using openSUSE Leap Micro 6.1 in a homelab environment on a physical Intel NUC with Btrfs as the root filesystem. My setup is as follows:

2× disks: /dev/sda and /dev/sdb
/dev/sd[a|b]2: EFI system partitions (FAT16)
/dev/sd[a|b]3: Btrfs root
EFI partitions are manually synchronized via rsync after kernel/GRUB updates
Btrfs is configured in RAID1 for metadata and data between sda3 and sdb3

I’m simulating a disk failure recovery in virtual environment:

I removed the primary disk (/dev/vda)
Replaced it with a fresh disk
Boot from live image
Cloned partition layout from /dev/vdb using sfdisk
Created new EFI FS and rsync-ed contents
Re-added /dev/vda3 to the Btrfs RAID with btrfs replace

All of that works great, but since EFI partition’s UUID has changed I need to update /etc/fstab accordingly, but I can’t edit that file due to read-only rootfs.

After mounting the restored Btrfs RAID1 system with:

mkdir -p /mnt/btrfs
mount -o degraded /dev/sdb3 /mnt/btrfs

…the system remains read-only. Trying to directly edit /mnt/btrfs/etc/fstab with vim fails

So I attempted a chroot into the mounted snapshot:

chroot /mnt/btrfs

But inside the chroot, every command referencing /dev/null fails:

bash: /dev/null: Read-only file system

Attempting to use sed inside the chroot to update the EFI UUID:

sed -i 's/4457-FEA0/DED9-DB0B/g' /etc/fstab
sed: couldn't open temporary file /etc/sedsThOpV: Read-only file system

Lastly, I tried launching transactional-update shell from within the chroot:

transactional-update shell

Which resulted in:

/sbin/transactional-update: line 1133: /dev/fd/63: No such file or directory
/sbin/transactional-update: line 221: /var/run/transactional-update.pid.4251: No such file or directory
/sbin/transactional-update: line 222: /dev/null: Read-only file system
tee: /var/log/transactional-update.log: Read-only file system
head: cannot open '/var/run/transactional-update.pid' for reading: No such file or directory
/sbin/transactional-update: line 230: /dev/null: Read-only file system
/sbin/transactional-update: line 201: /var/log/transactional-update.log: Read-only file system
Couldn't get lock, is another instance already running?

So the general question is how can I update /etc/fstab on an openSUSE Leap Micro installation from an external live system (e.g. openSUSE Tumbleweed Live), after replacing a disk and needing to fix the EFI partition UUID?

General output from lsblk command:

lsblk -o NAME,LABEL,PARTLABEL,UUID,PARTUUID,PARTTYPE,FSTYPE,MOUNTPOINTS
NAME   LABEL PARTLABEL UUID                                 PARTUUID                             PARTTYPE                             FSTYPE MOUNTPOINTS
vda                                                                                                                                          
├─vda1       p.legacy                                       ddac82a9-70a7-480b-b449-673ac863c308 21686148-6449-6e6f-744e-656564454649        
├─vda2 EFI   p.UEFI    4457-FEA0                            4b3db800-1f38-4c2e-a316-01eed205c0c0 c12a7328-f81f-11d2-ba4b-00a0c93ec93b vfat   /boot/efi
└─vda3 ROOT  p.lxroot  ebce2217-3184-4274-a920-76235395dc52 fc492be2-0a62-45d9-a8e6-62ecdde75673 0fc63daf-8483-4772-8e79-3d69d8477de4 btrfs  /usr/local
                                                                                                                                             /srv
                                                                                                                                             /boot/writable
                                                                                                                                             /opt
                                                                                                                                             /home
                                                                                                                                             /boot/grub2/i386-pc
                                                                                                                                             /boot/grub2/x86_64-efi
                                                                                                                                             /.snapshots
                                                                                                                                             /var
                                                                                                                                             /root
                                                                                                                                             /
vdb                                                                                                                                          
├─vdb1       p.legacy                                       ddac82a9-70a7-480b-b449-673ac863c308 21686148-6449-6e6f-744e-656564454649        
├─vdb2 EFI   p.UEFI    5555-066A                            4b3db800-1f38-4c2e-a316-01eed205c0c0 c12a7328-f81f-11d2-ba4b-00a0c93ec93b vfat   
└─vdb3 ROOT  p.lxroot  ebce2217-3184-4274-a920-76235395dc52 fc492be2-0a62-45d9-a8e6-62ecdde75673 0fc63daf-8483-4772-8e79-3d69d8477de4 btrfs

malcolmlewis · April 18, 2025, 2:54pm

@bartk Hi vda (vs mdnnn for s/w RAID) would indicate a virtual machine? I would use the partition reference eg /dev/vda2 rather than Partition UUID…

Else if it’s an Intel based NUC, should be able to configure disks in the BIOS as Intel RAID, rather than AHCI and run at a low level…

arvidjaar · April 18, 2025, 6:33pm

/etc is writable on MicroOS, it is located in overlayfs which is backed by directory in /var.

bartk · April 18, 2025, 8:47pm

Hi, thanks a lot for your reply! I appreciate the input

Yes, I’m indeed using a virtual machine for testing (hence the vda naming), but the setup mirrors a physical Intel NUC where I plan to deploy this.

Initially, I considered referencing devices directly in /etc/fstab using /dev/vdX (or /dev/sdX on bare metal), but since the installer configured it using UUIDs by default, I decided to stick with that convention for now.

As for the BIOS RAID1 — yes, the Intel NUC allows configuring it via Intel RST in UEFI. However, from the Linux side it behaves quite differently compared to Windows: even after enabling RAID1 in BIOS, Linux still sees both physical disks individually, assembles them via mdadm, and I can’t really see the practical benefit over just running software RAID (mdadm or Btrfs RAID1) on top of AHCI.

It feels like Intel’s BIOS-assisted RAID (imsm) is a kind of hybrid “fakeRAID” — helpful for Windows, but on Linux it just adds complexity.

Thanks again for chiming in!

EDIT:
On top of that, with Leap Micro, where the system is deployed via Ignition or Combustion, I have practically no control over how BIOS RAID is detected or assembled during installation. There’s no installer wizard or manual partitioning phase — everything is defined in advance through scripts, so it’s really hard to predict how BIOS RAID will behave long term, especially during boot, recovery, or transactional updates.

bartk · April 18, 2025, 8:48pm

Thanks for the clarification! You’re right — under normal conditions /etc is writable in MicroOS/Leap Micro thanks to the overlay setup.

However, in my case I’m booting into a Live openSUSE system (Tumbleweed) to simulate a disk failure recovery in a Btrfs RAID1. From there, I manually mount the recovered system’s root volume (mount -o degraded /dev/sdX3 /mnt) in order to restore the missing disk and update /etc/fstab.

At that point:

I cannot modify /mnt/etc/fstab directly (read-only file system),
entering chroot /mnt results in errors related to /dev/null and others being read-only,
launching transactional-update shell from chroot also fails due to missing paths and lack of overlay context.

So while /etc is writable during normal boot (thanks to transactional-update), it seems completely immutable when accessed externally from a live recovery environment.

Let me know if there’s a cleaner way to remount or modify it in such a recovery case — I’d be happy to try it out.

malcolmlewis · April 18, 2025, 9:01pm

@bartk Hi You might want to check the BIOS boot menu (here on DELL OptiPlex NUC’s) there is an additional item called “Device Configuration” When Intel RST is enabled, you go here to configure the disks, setup the RAID type etc.

I use also on my HP Z440 workstation sees them as md devices, but it treats it as a real RAID controller, AFAIK the Dell is the same.

RAID bus controller: Intel Corporation sSATA Controller [RAID Mode] (rev 05)

malcolmlewis · April 18, 2025, 9:08pm

@bartk Also have a read here regarding partitioning https://documentation.suse.com/sle-micro/5.1/html/SLE-Micro-all/cha-images-combustion.html#sec-script-partitioning the snippet may help for UUID changes…

malcolmlewis · April 18, 2025, 9:20pm

@bartk Quick test here on an OptiPlex XE3 boot from a Tumbleweed Live

linux@localhost:~/Desktop> lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0     7:0    0 595.9M  1 loop  /run/overlay/squashfs_container
loop1     7:1    0   2.8G  1 loop  /run/overlay/rootfsbase
sda       8:0    0 465.8G  0 disk  
|-md126   9:126  0 465.8G  0 raid1 
`-md127   9:127  0     0B  0 md    
sdb       8:16   0 465.8G  0 disk  
|-md126   9:126  0 465.8G  0 raid1 
`-md127   9:127  0     0B  0 md    
sdc       8:32   1  14.8G  0 disk  
|-sdc1    8:33   1 654.5M  0 part  /run/overlay/live
|-sdc2    8:34   1    20M  0 part  
`-sdc3    8:35   1  14.1G  0 part  /run/overlay/overlayfs
sr0      11:0    1  1024M  0 rom   
linux@localhost:~/Desktop> /sbin/lspci | grep RAID
00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode] (rev 10)

System:
  Kernel: 6.14.0-1-default arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
  Desktop: Xfce v: 4.20.1 tk: Gtk v: 3.24.48 wm: xfwm4 dm: LightDM
    Distro: openSUSE Tumbleweed 20250403
Machine:
  Type: Desktop System: Dell product: OptiPlex XE3 v: N/A
    serial: <superuser required> Chassis: type: 3 serial: <superuser required>
  Mobo: Dell model: 0CWR57 v: A02 serial: <superuser required> part-nu: 0863
    UEFI: Dell v: 1.35.0 date: 01/22/2025
CPU:
  Info: 6-core model: Intel Core i7-8700 bits: 64 type: MT MCP
    arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB
  Speed (MHz): avg: 900 min/max: 800/4600 cores: 1: 900 2: 900 3: 900 4: 900
    5: 900 6: 900 7: 900 8: 900 9: 900 10: 900 11: 900 12: 900 bogomips: 76799
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] vendor: Dell
    driver: i915 v: kernel arch: Gen-9.5 ports: active: DP-4 empty: DP-5, DP-6,
    HDMI-A-1, HDMI-A-2, HDMI-A-3 bus-ID: 00:02.0 chip-ID: 8086:3e92
  Device-2: NVIDIA GP107GL [Quadro P400] vendor: Dell driver: nouveau
    v: kernel arch: Pascal pcie: speed: 2.5 GT/s lanes: 16 ports: active: none
    empty: DP-1,DP-2,DP-3 bus-ID: 01:00.0 chip-ID: 10de:1cb3 temp: 40.0 C
  Display: x11 server: X.org v: 1.21.1.15 compositor: xfwm4 v: 4.20.0
    driver: X: loaded: modesetting,nouveau unloaded: vesa failed: nv
    alternate: fbdev,intel,nvidia dri: iris,nouveau gpu: i915 display-ID: :0.0
    screens: 1
  Screen-1: 0 s-res: 1600x900
  Monitor-1: DP-4 model: Dell P2018H res: 1600x900 hz: 60 dpi: 94
    diag: 494mm (19.4")
  API: OpenGL v: 4.6 vendor: intel mesa v: 25.0.2 glx-v: 1.4 es-v: 3.2
    direct-render: yes renderer: Mesa Intel UHD Graphics 630 (CFL GT2)
    device-ID: 8086:3e92
  Info: Tools: api: glxinfo de: xfce4-display-settings x11: xrandr
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel
    v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a348
  Device-2: NVIDIA GP107GL High Definition Audio vendor: Dell
    driver: snd_hda_intel v: kernel pcie: speed: 2.5 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 10de:0fb9
  API: ALSA v: k6.14.0-1-default status: kernel-api
Network:
  Device-1: Intel Ethernet I219-LM vendor: Dell driver: e1000e v: kernel
    port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15bb
  IF: em1 state: up speed: 1000 Mbps duplex: full mac: <filter>
RAID:
  Hardware-1: Intel SATA Controller [RAID mode] driver: ahci v: 3.0
    bus-ID: 00:17.0 chip-ID: 8086:2822
  Device-1: md126 type: mdraid level: mirror status: active size: 465.76 GiB
  Info: report: 2/2 UU blocks: 488383488 chunk-size: N/A
  Components: Online: 0: sdb 1: sda
  Recovering: 2.5% [>....................] time-remaining: 116.2min
    sectors: 12499264/488383488 speed: 68202K/sec
  Device-2: md127 type: mdraid level: N/A status: inactive size: N/A
  Info: report: N/A blocks: 6192 chunk-size: N/A
  Components: Online: N/A Spare: 0: sdb 1: sda
Drives:
  Local Storage: total: raw: 946.29 GiB usable: -472906800 used: 244.9 MiB
  ID-1: /dev/sda vendor: Western Digital model: WD5000LPSX-75A6WT0
    size: 465.76 GiB speed: 6.0 Gb/s serial: <filter>
  ID-2: /dev/sdb vendor: Western Digital model: WD5000LPSX-75A6WT0
    size: 465.76 GiB speed: 6.0 Gb/s serial: <filter>
  ID-3: /dev/sdc vendor: Patriot model: N/A size: 14.77 GiB type: USB
    rev: 2.1 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
  ID-1: / size: 13.78 GiB used: 244.9 MiB (1.7%) fs: overlay source: ERR-102
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 30.0 C pch: 36.0 C mobo: N/A gpu: nouveau
    temp: 40.0 C
  Fan Speeds (rpm): N/A gpu: nouveau fan: 1007
Info:
  Memory: total: 16 GiB note: est. available: 15.29 GiB used: 856.7 MiB (5.5%)
  Processes: 266 Power: uptime: 0h 3m wakeups: 0 Init: systemd v: 257
    default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm Compilers: N/A Shell: Bash
    v: 5.2.37 running-in: xfce4-terminal inxi: 3.3.37

As can be seen the inxi output RAID is auto recovering, I would expect you real NUC to do the same, replace the drive, boot and it should sort everything out for you.

arvidjaar · April 19, 2025, 4:54am

If you know it why do you attempt to modify read-only part? You need to replicate the same overlayfs setup otherwise you will be editing the wrong file anyway.

bartk · April 19, 2025, 10:48am

After simulating a disk replacement (Btrfs replace and balance worked fine), I booted from a Live ISO (openSUSE Leap) to fix the UUID of the EFI partition in /etc/fstab.

Here are the steps I followed:

mount -o degraded /dev/sdb3 /mnt/btrfs
for i in proc sys dev run; do mount --rbind /$i /mnt/btrfs/$i; done
chroot /mnt/btrfs/

I can access the system:

cat /etc/fstab

But any attempt to edit this file (e.g., with vim, sed, cp) results in read-only file system errors, even inside the chroot.

The system uses transactional updates and overlayfs, and I can see the last line in /etc/fstab:

UUID=ebce2217-3184-4274-a920-76235395dc52 / btrfs ro 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /.snapshots btrfs defaults,subvol=@/.snapshots 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /home btrfs defaults,subvol=@/home 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /opt btrfs defaults,subvol=@/opt 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /root btrfs defaults,subvol=@/root,x-initrd.mount 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /srv btrfs defaults,subvol=@/srv 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /var btrfs defaults,subvol=@/var,x-initrd.mount 0 0
UUID=4457-FEA0 /boot/efi vfat defaults 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /boot/writable btrfs defaults,subvol=@/boot/writable 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /usr/local btrfs defaults,subvol=@/usr/local 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /boot/grub2/i386-pc btrfs defaults,subvol=@/boot/grub2/i386-pc 0 0
UUID=ebce2217-3184-4274-a920-76235395dc52 /boot/grub2/x86_64-efi btrfs defaults,subvol=@/boot/grub2/x86_64-efi 0 0
overlay /etc overlay defaults,lowerdir=/sysroot/var/lib/overlay/4/etc:/sysroot/etc,upperdir=/sysroot/var/lib/overlay/5/etc,workdir=/sysroot/var/lib/overlay/5/work-etc,x-systemd.requires-mounts-for=/var,x-systemd.requires-mounts-for=/sysroot/var,x-initrd.mount 0 0

However, /sysroot does not exist in the mounted root from the Live system. So /etc appears as read-only.

I understand /etc is writable in Leap Micro under normal boot. But in recovery scenarios from a Live ISO — how am I supposed to edit /etc/fstab?

My questions:

Is there a correct way to reconstruct the overlay mount in Live/chroot environment so that /etc becomes writable?
Or is there an alternative, MicroOS-native method to edit such files offline (without booting the system normally)?
Is creating and mounting a new writable Btrfs snapshot the expected way to work around this?

Thanks in advance!
Let me know if more info is needed — I can provide full outputs from btrfs subvolume list, mount, etc.

bartk · April 19, 2025, 10:54am

Thanks for pointing that.

I noticed that the example you referenced:

awk -i inplace '$2 != "/home"' /etc/fstab
echo "$(blkid -o export ${partition} | grep ^UUID=) /home btrfs defaults 0 0" >> /etc/fstab

is listed under the Combustion scripting section, which (as I understand) is executed only once during the first boot.

Do you happen to know if there is a way to re-run Combustion scripts after system recovery or disk replacement?

Or are these kinds of fstab modifications meant to be performed only at provisioning time, and in post-recovery situations we need to work around the overlayfs and /etc issue some other way (e.g., via snapshots or other transactional-update mechanisms)?

Appreciate any clarification!

arvidjaar · April 19, 2025, 11:15am

Sigh … /sysroot is used in initrd to mount real root. Your writable /etc is in /var which should be mounted as /mnt/btrfs/var in your case. So, replace /sysroot with /mnt/btrfs.

bartk · April 19, 2025, 2:35pm

I was able to mount the degraded Btrfs filesystem from a Live ISO and chroot into it:

mount -o degraded /dev/sdb3 /mnt
for i in proc sys dev run; do mount --rbind /$i /mnt/$i; done
chroot /mnt

However, to see the overlay content (/var/lib/overlay/...) I had to manually from chroot env:

mount /var

Only after that I could access and successfully edit the fstab file in the latest snapshot to reflect the new EFI UUID, but I’m having trouble booting into the system — it stops at:

Booting from Hard Disk…

GRUB doesn’t even show up. I’m syncing EFI partitions (after disk replacement) using the following commands:

blkdiscard /dev/sda -v
sfdisk -d /dev/sdb | sfdisk /dev/sda
mkfs.fat -F16 /dev/sda2 -n EFI
mkdir -p /mnt/efi-sda
mkdir -p /mnt/efi-sdb
mount /dev/sda2 /mnt/efi-sda
mount /dev/sdb2 /mnt/efi-sdb
rsync -av --delete --itemize-changes /mnt/efi-sdb/ /mnt/efi-sda/
umount /mnt/efi-sda
umount /mnt/efi-sdb
rmdir /mnt/efi-sda
rmdir /mnt/efi-sdb

I tried reinstalling GRUB from a Live ISO using:

chroot /mnt
grub2-install ...

but this fails with read-only file system. Also, transactional-update shell doesn’t work from within chroot.

What I’m asking

What’s the correct procedure to reinstall GRUB from a Live ISO for Leap Micro, considering the transactional/overlay nature?
Could the device name change from vda to sda impact UEFI bootability (despite having correct files)?
Is there anything I’m missing regarding UEFI fallback behavior or efibootmgr entries?

Thanks in advance for your help.

arvidjaar · April 19, 2025, 2:40pm

Show

lsblk -f -o +partuuid
efibootmgr -v

bartk · April 19, 2025, 2:45pm

kubic-1:~ # lsblk -f -o +partuuid
NAME   FSTYPE   FSVER            LABEL                       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS                  PARTUUID
loop0  squashfs 4.0                                                                                     0   100% /run/overlay/squashfs_container
 
loop1  ext4     1.0                                          4288db55-9d0d-4441-b876-cefdfcbd2e08    1.1G    71% /run/overlay/rootfsbase      
sda                                                                                                                                           
├─sda1                                                                                                                                        ddac82a9-70a7-480b-b449-673ac863c308
├─sda2 vfat     FAT16            EFI                         B643-A6BE                              15.9M    20% /mnt/boot/efi                4b3db800-1f38-4c2e-a316-01eed205c0c0
└─sda3 btrfs                     ROOT                        ebce2217-3184-4274-a920-76235395dc52   36.7G     6% /mnt/boot/grub2/x86_64-efi   fc492be2-0a62-45d9-a8e6-62ecdde75673
                                                                                                                 /mnt/boot/grub2/i386-pc      
                                                                                                                 /mnt/usr/local               
                                                                                                                 /mnt/boot/writable           
                                                                                                                 /mnt/var                     
                                                                                                                 /mnt/srv                     
                                                                                                                 /mnt/root                    
                                                                                                                 /mnt/opt                     
                                                                                                                 /mnt/home                    
                                                                                                                 /mnt/.snapshots              
                                                                                                                 /mnt                         
sdb                                                                                                                                           
├─sdb1                                                                                                                                        ddac82a9-70a7-480b-b449-673ac863c308
├─sdb2 vfat     FAT16            EFI                         667E-C4E0                                                                        4b3db800-1f38-4c2e-a316-01eed205c0c0
└─sdb3 btrfs                     ROOT                        ebce2217-3184-4274-a920-76235395dc52                                             fc492be2-0a62-45d9-a8e6-62ecdde75673
sr0    iso9660  Joliet Extension openSUSE_Leap_15.6_KDE_Live 2025-04-01-13-41-31-00                     0   100% /run/overlay/live            
kubic-1:~ # efibootmgr -v
EFI variables are not supported on this system

arvidjaar · April 19, 2025, 2:47pm

Then why do you have

in the first place?

Svyatko · April 19, 2025, 3:21pm

arvidjaar:

Then why do you have

in the first place?

Virtual machine is using legacy boot but user tries to use UEFI boot?

And it is better to use FAT32 instead of FAT16 for ESP.

bartk · April 19, 2025, 4:07pm

Apologies — I realized I made a mistake in my earlier testing: my original KVM/QEMU VM was not booting in UEFI mode as I assumed. I’ve now corrected that and recreated the VM with UEFI firmware (OVMF), and efibootmgr -v now returns correct UEFI boot entries.

What I did (again)

I repeated the entire disk replacement process (this time replacing /dev/vda):

Rebuilt the degraded Btrfs RAID1 using btrfs replace
Synced the EFI partition

Then from Live image and chroot env I updated fstab to reflect the new UUID for /boot/efi, in both:

/var/lib/overlay/4/etc/fstab #lowerdir
/var/lib/overlay/5/etc/fstab #upperdir

After rebooting, systemd in initramfs still tries to mount /boot/efi using the old UUID:

systemd: Reached target Initrd Root Device.
dracut-initqueue: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks
dracut-initqueue: Warning: /lib/dracut/hooks/initqueue/fished/devexists ... /dev/disk/by-uuid/4457-FEA0
dracut-initqueue: Warning: dracut-initqueue: starting timeout scripts

Despite the updated UUID being correctly set in both overlay /etc/fstab locations.
My question is how can I make the updated /etc/fstab “active” for the next boot

Here is the overlay entry in /etc/fstab (not in /var/lib/...) file:

overlay /etc overlay defaults,lowerdir=/sysroot/var/lib/overlay/4/etc:/sysroot/etc,upperdir=/sysroot/var/lib/overlay/5/etc,workdir=/sysroot/var/lib/overlay/5/work-etc,x-systemd.requires-mounts-for=/var,x-systemd.requires-mounts-for=/sysroot/var,x-initrd.mount 0 0

FYI:

This is the default behaviour during clean installation of Leap Micro 6.1

arvidjaar · April 19, 2025, 4:31pm

Are you using GRUB or systemd-boot?

bartk · April 19, 2025, 6:17pm

I’m using GRUB:

kubic:~ # efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0001,0000
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
      dp: 04 07 14 00 c9 bd b8 7c eb f8 34 4f aa ea 3e e4 af 65 16 a1 / 04 06 14 00 21 aa 2c 46 14 76 03 45 83 6e 8a b6 f4 66 23 31 / 7f ff 04 00
Boot0001* UEFI Misc Device      PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0){auto_created_boot_option}
      dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 04 02 / 01 01 06 00 00 00 / 7f ff 04 00
    data: 4e ac 08 81 11 9f 59 4d 85 0e e2 1a 52 2c 59 b2
Boot0003* opensuse-secureboot   HD(2,GPT,4b3db800-1f38-4c2e-a316-01eed205c0c0,0x1800,0xa000)/File(\EFI\opensuse\shim.efi)
      dp: 04 01 2a 00 02 00 00 00 00 18 00 00 00 00 00 00 00 a0 00 00 00 00 00 00 00 b8 3d 4b 38 1f 2e 4c a3 16 01 ee d2 05 c0 c0 02 02 / 04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 6f 00 70 00 65 00 6e 00 73 00 75 00 73 00 65 00 5c 00 73 00 68 00 69 00 6d 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
kubic:~ # ls -l /boot/grub2/
total 16
drwxr-xr-x. 1 root root    22 Dec  4 22:15 fonts
-rw-------. 1 root root 11274 Apr 19 15:09 grub.cfg
-rw-r--r--. 1 root root  1024 Dec  4 22:15 grubenv
drwxr-xr-x. 1 root root  6792 Dec  4 22:15 i386-pc
drwxr-xr-x. 1 root root   396 Apr 19 15:05 locale
drwxr-xr-x. 1 root root    16 Dec  4 22:12 themes
drwxr-xr-x. 1 root root  6462 Apr 19 15:05 x86_64-efi