/boot has somehow become a symlink to /
x86_64 architecture; 3.6.3 was earlier upgraded to 3.7.0; original .iso was a hardened x86_64 c. 3.6.2. First noticed this problem because I couldn’t find /boot/syslinux/syslinux.cfg
root@localhost:~# cd /boot
root@localhost:/boot# ls
System.map-hardened extlinux.conf.old libcom32.c32 menu.c32
boot initramfs-hardened libutil.c32 vesamenu.c32
config-hardened ldlinux.c32 lost+found vmlinuz-hardened
extlinux.conf ldlinux.sys mboot.c32
root@localhost:/boot# cd boot
root@localhost:/# cd /boot/boot/
root@localhost:/# ls
bin dev home lost+found mnt root run srv sys usr
boot etc lib media proc rules.d sbin swap tmp var
root@localhost:/# cd /boot/boot/boot
root@localhost:/boot# ls
System.map-hardened extlinux.conf.old libcom32.c32 menu.c32
boot initramfs-hardened libutil.c32 vesamenu.c32
config-hardened ldlinux.c32 lost+found vmlinuz-hardened
extlinux.conf ldlinux.sys mboot.c32
On closer examination, /boot has become a symlink to / as shown:
root@localhost:~# cd ..
root@localhost:/# pwd
/
root@localhost:/# ls -l
total 113
drwxr-xr-x 2 root root 4096 Dec 21 13:52 bin
drwxr-xr-x 3 root root 1024 Dec 3 02:31 boot
drwxr-xr-x 17 root root 3640 Jan 20 11:30 dev
drwxr-xr-x 65 root root 4096 Jan 18 19:15 etc
drwxr-xr-x 3 root root 4096 Jan 17 15:26 home
drwxr-xr-x 9 root root 4096 Jan 19 13:05 lib
drwx------ 2 root root 16384 Nov 14 17:11 lost+found
drwxr-xr-x 7 root root 4096 Nov 16 23:15 media
drwxr-xr-x 3 root root 4096 Nov 22 10:57 mnt
dr-xr-xr-x 223 root readproc 0 Jan 20 11:30 proc
drwx------ 15 root root 4096 Dec 29 16:44 root
drwxr-xr-x 2 root root 4096 Jan 13 18:01 rules.d
drwxr-xr-x 15 root root 580 Jan 20 11:32 run
drwxr-xr-x 2 root root 12288 Jan 13 18:00 sbin
drwxr-xr-x 2 root root 4096 Nov 14 17:12 srv
drwxr-xr-x 2 root root 4096 Nov 14 17:17 swap
dr-xr-xr-x 13 root root 0 Jan 20 11:30 sys
drwxrwxrwt 5 root root 32768 Jan 20 11:37 tmp
drwxr-xr-x 11 root root 4096 Nov 15 09:55 usr
drwxr-xr-x 12 root root 4096 Dec 3 00:46 var
root@localhost:/# cd /boot
root@localhost:/boot# ls -l
total 20363
-rw-r--r-- 1 root root 4131160 Nov 27 10:59 System.map-hardened
lrwxrwxrwx 1 root root 1 Nov 14 17:16 boot -> /
-rw-r--r-- 1 root root 165139 Nov 27 10:59 config-hardened
-rw-r--r-- 1 root root 439 Dec 13 15:26 extlinux.conf
-rw-r--r-- 1 root root 439 Dec 1 10:33 extlinux.conf.old
-rw-r--r-- 1 root root 11574996 Nov 30 17:34 initramfs-hardened
-r--r--r-- 1 root root 116924 Dec 3 02:31 ldlinux.c32
-r--r--r-- 1 root root 69632 Dec 3 02:31 ldlinux.sys
-rw-r--r-- 1 root root 181996 Dec 3 02:31 libcom32.c32
-rw-r--r-- 1 root root 23616 Dec 3 02:31 libutil.c32
drwx------ 2 root root 12288 Nov 14 17:11 lost+found
-rw-r--r-- 1 root root 11712 Dec 3 02:31 mboot.c32
-rw-r--r-- 1 root root 26568 Dec 3 02:31 menu.c32
-rw-r--r-- 1 root root 27020 Dec 3 02:31 vesamenu.c32
-rw-r--r-- 1 root root 4502608 Nov 27 10:59 vmlinuz-hardened
root@localhost:/boot# cd /boot/boot
root@localhost:/# ls -l
total 113
drwxr-xr-x 2 root root 4096 Dec 21 13:52 bin
drwxr-xr-x 3 root root 1024 Dec 3 02:31 boot
drwxr-xr-x 17 root root 3640 Jan 20 11:30 dev
drwxr-xr-x 65 root root 4096 Jan 18 19:15 etc
drwxr-xr-x 3 root root 4096 Jan 17 15:26 home
drwxr-xr-x 9 root root 4096 Jan 19 13:05 lib
drwx------ 2 root root 16384 Nov 14 17:11 lost+found
drwxr-xr-x 7 root root 4096 Nov 16 23:15 media
drwxr-xr-x 3 root root 4096 Nov 22 10:57 mnt
dr-xr-xr-x 222 root readproc 0 Jan 20 11:30 proc
drwx------ 15 root root 4096 Dec 29 16:44 root
drwxr-xr-x 2 root root 4096 Jan 13 18:01 rules.d
drwxr-xr-x 15 root root 580 Jan 20 11:32 run
drwxr-xr-x 2 root root 12288 Jan 13 18:00 sbin
drwxr-xr-x 2 root root 4096 Nov 14 17:12 srv
drwxr-xr-x 2 root root 4096 Nov 14 17:17 swap
dr-xr-xr-x 13 root root 0 Jan 20 11:30 sys
drwxrwxrwt 5 root root 32768 Jan 20 11:37 tmp
drwxr-xr-x 11 root root 4096 Nov 15 09:55 usr
drwxr-xr-x 12 root root 4096 Dec 3 00:46 var
This is being flagged up as a possible vulnerability, but I couldn’t identify how it was created. System has otherwise appeared to have been booting and running unsuspectingly smoothly except for the following:
- Battery began to quickly empty (within minutes) shortly after purchase, so AC power is required.
- Launching a shell has been returning a prompt with an “ash: out of range” response for months, which led me to an attempt today to try to fix this and to notice that I couldn’t find syslinux.cfg (further to suggestion to fix grub, as at https://ubuntuforums.org/showthread.php?t=1751950)
Months ago, syslinux.cfg had been found and edited. Running a search for syslinux.cfg today yields no results; note response to ls /usr/bin/syslinux:
root@localhost:/boot# whereis syslinux.cfg
syslinux: /usr/bin/syslinux /usr/share/syslinux
root@localhost:/boot# ls /usr/bin/syslinux
/usr/bin/syslinux
root@localhost:/boot# ls /usr/share/syslinux
altmbr.bin dmi.c32 isohdpfx.bin lpxelinux.0 reboot.c32
altmbr_c.bin dmitest.c32 isohdpfx_c.bin ls.c32 rosh.c32
altmbr_f.bin dosutil isohdpfx_f.bin lua.c32 sanboot.c32
cat.c32 efi64 isohdppx.bin mboot.c32 sdi.c32
chain.c32 elf.c32 isohdppx_c.bin mbr.bin sysdump.c32
cmd.c32 ethersel.c32 isohdppx_f.bin mbr_c.bin syslinux.c32
cmenu.c32 gfxboot.c32 isolinux-debug.bin mbr_f.bin syslinux.com
com32 gptmbr.bin isolinux.bin memdisk syslinux.exe
config.c32 gptmbr_c.bin kbdmap.c32 meminfo.c32 syslinux64.exe
cptime.c32 gptmbr_f.bin kontron_wdt.c32 menu.c32 vesa.c32
cpu.c32 gpxecmd.c32 ldlinux.c32 pci.c32 vesainfo.c32
cpuid.c32 hdt.c32 lfs.c32 pcitest.c32 vesamenu.c32
cpuidtest.c32 hexdump.c32 libcom32.c32 pmload.c32 vpdtest.c32
debug.c32 host.c32 libgpl.c32 poweroff.c32 whichsys.c32
dhcp.c32 ifcpu.c32 liblua.c32 prdhcp.c32 zzjson.c32
diag ifcpu64.c32 libmenu.c32 pwd.c32
dir.c32 ifmemdsk.c32 libutil.c32 pxechn.c32
disk.c32 ifplop.c32 linux.c32 pxelinux.0
I considered posting this on the forum but was concerned due to the relative lack of response there (but I am very grateful for so much development activity!)
(from redmine: issue id 8407, created on 2018-01-20)