Facing interesting issue in initramfs for switch_root.

[Pranav Lavhate]

Hello Linux Enthusiasts,

I am facing one weird issue.

I have applied Full Disk Encryption (FDE) for ext4 partition and am trying to mount it (All encrypting and mounting through initramfs). I am facing the below error for switch_root.
Logs:

-------------------------------------------------------------
---exec busybox switch_root /rootfs /sbin/init
switch_root: can't execute '/sbin/init': No such file or directory
[    6.389473][    T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[    6.404042][    T1] CPU: 2 PID: 1 Comm: busybox Tainted: G           O      5.15.144-debug-g8b08b62845e2 #1
[    6.422070][    T1] Call trace:
[    6.425293][    T1]  dump_backtrace+0x0/0x214
[    6.429773][    T1]  show_stack+0x18/0x24
[    6.433891][    T1]  dump_stack_lvl+0x64/0x7c
[    6.438366][    T1]  dump_stack+0x18/0x38
[    6.442485][    T1]  panic+0x150/0x380
[    6.446334][    T1]  do_exit+0x7d4/0x920
[    6.450361][    T1]  do_group_exit+0x9c/0xa0
[    6.454750][    T1]  __wake_up_parent+0x0/0x2c
[    6.459316][    T1]  invoke_syscall+0x40/0x100
[    6.463883][    T1]  el0_svc_common+0xb4/0xf0
[    6.468356][    T1]  do_el0_svc+0x24/0x90
[    6.472474][    T1]  el0_svc+0x20/0x50
[    6.476322][    T1]  el0t_64_sync_handler+0x84/0xe4
[    6.481333][    T1]  el0t_64_sync+0x180/0x184
[    6.485805][    T1] SMP: stopping secondary CPUs
[    6.490623][    T1] Dumping EMAC registers
[    6.495104][    T1] EMAC register dump complete: Dumped 657 registers
[    6.514992][    T1] Dumping ftrace buffer:
[    6.519212][    T1]    (ftrace buffer empty)

[    6.603304][    T1] Memory Limit: none
[    6.607156][    T1] Triggering late bite


----------------------------------------------------

However I tried to drop down to shell (using busybox /bin/sh) and tried to execute command, it worked smoothly.Able to log in to kernel.

I tried below things
1. write a.sh file from shell and gave command from file and execute ./a.sh
-> got error but not crash 
/ # busybox ./a.sh
BusyBox v1.35.0 () multi-call binary.

Usage: switch_root [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS]

Free initramfs and switch to another root fs:
chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,
execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.

        -c DEV  Reopen stdio to DEV after switch

2. Checked /rootfs/sbin/init is present:

#  busybox ls -la /rootfs/sbin/init
lrwxrwxrwx    1 0        0               22 Mar  9  2018 /rootfs/sbin/init -> ../lib/systemd/systemd

3. kept sync before mount
-> Not working/ same error

4. copy /rootfs/sbin/init to /bin and tried to switch_root to /bin/init
-> same error


Any suggestions are welcome.
Warm regards,
Pranav

[Anil Kumar Pugalia]

How did you copy to /bin? What are the permissions of the destination of the link? Is it accessible correctly with the link? Is it in the same partition?

Regards
Anil

Passion: https://sysplay.in (Playing with Systems)

Pranav Lavhate wrote on 13/08/24 12:51:

[Pranav Lavhate]

Hello Anil/ folks,

<Anil >How did you copy to /bin?
<Pranav> It is binding by the rootfs.

<Anil> What are the permissions of the destination of the link?
 <Pranav> It has the same permissions.
Please check the log below.

#  busybox ls -la /rootfs/sbin/init
lrwxrwxrwx    1 0        0               22 Mar  9  2018 /rootfs/sbin/init -> ../lib/systemd/systemd

 <Anil>Is it accessible correctly with the link? Is it in the same partition?
Yes.Its accessible with link and the same partition.

Note: The "exec busybox switch_root rootfs sbin/init" is working fine on shell prompt.
For trial purposes ,I copied it to one a.sh file and ran the script. It gave me an error. ( Later I explored and got to know for switch_root the PID should be 1. So it's giving syntax errors. Please correct me if my understanding is wrong here)

--
You received this message because you are subscribed to the Google Groups "SysPlay's Inside Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inside_linux...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inside_linux/7bdee4d7-05be-4261-8de2-8f5045e1066a%40sarika-pugs.com.

[ravikiran bvn]

Hello Pranav, 

I also had a similar with busy box 1.36.1.

I could not really understand the problem and solve it. 

As a workaround, I just directly used the mini root file system from alpine: https://alpinelinux.org/downloads/ 

Alpine mini root file system also uses a busy box inside, which is approx. 10 MB in size.

Hope this helps for you.

To view this discussion on the web visit https://groups.google.com/d/msgid/inside_linux/CAM%2BrkwgNEUQ_QD-Fk8%2B71qd%2BC%2BKkYaZZdHsAxbjU3G0ZoFN_%3DQ%40mail.gmail.com.

[Anil Kumar Pugalia]

Typically, this error indicates that the file is not accessible, during the boot time. Please note that the file structure you see after boot, may not be exactly visible during boot, due to multiple reasons. A simple check could be if you place the actual file directly at the location, instead of through links.

Thanks & Regards

Anil

Passion: https://sysplay.in (Playing with Systems)

ravikiran bvn wrote on 14/08/24 12:54:

To view this discussion on the web visit https://groups.google.com/d/msgid/inside_linux/CADmUoRQ7SGSBoz%3D%2B6D-ByHRZfupo_qCGpvkCsWzGCCXPYSxLmg%40mail.gmail.com.

[Pranav Lavhate]

Hello Anil/ folks.

Thank you so much for your invaluable insights! The mystery has been unraveled.🎉

Initially, I suspected 'switch_root' or 'initramfs' might be the culprits. I even sprinkled some logs in switch_root.c and chroot.c (check out  https://github.com/leahneukirchen/xtools/blob/master/xchroot ).

After some detective work, it turned out they were innocent.

The real twist in the tale was with the 'dd' command post-FDE encryption. I am using the "dd" command to copy the encrypted image. For NAND, the smaller image size was a breeze. But for ext4, the larger image size threw a wrench in the works.
For NAND, it worked fine since the image size was relatively small (~80MB). However, for ext4, the image size was larger (~300MB).

The missing piece? The "conv=fsync" option in the dd command. Once I enabled it, everything fell into place perfectly.

warm regards,
Pranav

To view this discussion on the web visit https://groups.google.com/d/msgid/inside_linux/fc0ed316-ad43-4766-b983-5049750c9769%40sarika-pugs.com.