EasyOS version 2.3.2, June 22, 2020

Message

BarryK · #781 Post by **BarryK** » Fri 01 Jun 2018, 01:17

Cu Chulinux wrote:Barry, here is a screenshot of the startup for Easy 0.9.3 showing failed mounting of q.sfs

Thanks for the that. The snapshot is reporting that the date format is wrong, so let's start with that.

It says that this is the wrong format:

2018-05-29 21:41-04:00

...which it is.

/etc/rc.d/rc.shutdown saves the shutdown date in a file, and it is this that has the wrong format.

My first thought is that this may be due to a non-English locale. What locale are you using?

Open a terminal and type this. I have done it and you can see what I get, which is the correct format:

# date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '
2018-06-01 09:01

If you get the wrong format, try this:

# LANG=C date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '

If you still don't get the correct format, just do this, and let me know the result:

# LANG=C busybox date -Iminutes

...that's a capital letter "I" by the way.

Cu Chulinux · #782 Post by **Cu Chulinux** » Fri 01 Jun 2018, 02:20

Ok, first off I have been getting that wrong date format in Easy since 0.6.8 (first I used). It also shows up with 0.9.1 that I reverted back to after 0.9.3 wouldn't boot. Never thought anything about it.

Results of the commands:

# date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '
2018-05-31 21:54-04:00
# LANG=C date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '
2018-05-31 21:54-04:00
# LANG=C busybox date -Iminutes
2018-06-01T01:55+0000
#

Note I am in North America Eastern time zone that is (with daylight savings) -4:00 hours behind GMT (or UTC or whatever they call it these days). The actual local time at the command entry was 21:54.

Currently my time zone locale is America/Toronto. I believe this is a fairly newly added locale as I recall using New York in the past. My hw clock is set to local time instead of UTC as I also have Win 10 installed.

I use EN_US language and US keyboard and afaik locale is English. I did click to set time from internet (North American pool).

Side note I tried booting 0.9.3 from USB on my work computer (nVidia card - Quadro 600) with no luck getting to X. It failed loading X with nouveau and nv and modesetting. I didn't try vesa. Was just a quick test to see if it would work.

tigs · #783 Post by **tigs** » Fri 01 Jun 2018, 04:03

I have some observation.

I have been trying to install it to windows 10 hard drive with inconsistent success. What I find is multi-boot on a windows 10 machine does not work if the primary hard drive is a PCIe based drive. Initially I thought it is the nVME problem. No, I have tried on a PCIe mSATA drive as well ( all lenovo laptop msata are PCIe interfaced). It did not work either. The boot menu does not show the sub-menu as it would on a SATA drive if installed on the same drive as windows 1o.

I have not tried to install in on a PCIe secondary drive yet.

BarryK · #784 Post by **BarryK** » Fri 01 Jun 2018, 08:45

Cu Chulinux wrote:Results of the commands:

# date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '
2018-05-31 21:54-04:00
# LANG=C date -Iminutes | cut -f 1 -d '+' | tr 'T' ' '
2018-05-31 21:54-04:00
# LANG=C busybox date -Iminutes
2018-06-01T01:55+0000
#

To get a complete picture, would you also mind just doing this:

# date -Iminutes

...just so that I can see exactly the difference that the full 'date' utility is outputting, compared with the busybox one.

Trying it myself:

# date -Iminutes
2018-06-01T16:33+08:00
# busybox date -Iminutes
2018-06-01T08:34+0000

...now isn't that interesting!!!

The actual local time here is 16:33, that is, 4:33pm, and hardware clock is set to local time, timezone is UTC+8:00 (Perth, Australia).

The busybox date applet is reporting wrong time!

The reason that you were getting an error, is the script rc.shutdown was only looking for the "+" and dropping off that "+08:00"

Right, I know how to fix it. Thanks for reporting it!

BarryK · #785 Post by **BarryK** » Fri 01 Jun 2018, 09:35

Cu Chulinux wrote:Barry, here is a screenshot of the startup for Easy 0.9.3 showing failed mounting of q.sfs

OK, so it has failed to mount q.sfs, and has dropped out to a shell.

This shell is in ram. Do you have keyboard inpout at this stage? On some PCs the keyboard does not work at this stage of bootup.

If you do have a working keyboard, can you type in these commands:

Code: Select all

# echo "$Q_DISTRO_VERSION"
# echo "$WKG_DEV"
# echo "$WKG_DIR"
# ls -1 /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}

The 'init' script tried to run this:

Code: Select all

mount -r -t squashfs -o noatime,loop /q_ro/q.sfs /q_ro/q_sfs

but failed, with "invalid argument" error.

It would seem that one of those variables, that are got out of file BOOT_SPECS in initrd.q, is wrong, and q.sfs is not found.

q.sfs is expected at /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs and the script then copies it to /q_ro, then the above 'mount' operation is performed.

Another possibility is that q.sfs is there, but is somehow corrupted.

One other thing to check: if you have Easy installed in a sub-directory, say "easy", then WKG_DIR must have a trailing slash, WKG_DIR='easy/'

Billtoo · #786 Post by **Billtoo** » Fri 01 Jun 2018, 09:42

I see an incorrect time error during each boot up of easy,have from the start.
The quicksetup setting gives the correct time, I boot easy from an SDHC card,also boot Ubuntu 18.04 from the hard drive.

EDIT: Seems I've confused time error with date format error.

BarryK · #787 Post by **BarryK** » Fri 01 Jun 2018, 10:10

On the subject of $BOOT_DIR and $WKG_DIR in file BOOT_SPECS, there have been earlier reports of the trailing "/" getting left off.

If you had, for example, WKG_DIR='easy/0.9.3' without a trailing slash, then booting would fail.

So, I thought why not check for that in the 'init' script, and automatically fix it. These two lines do it:

Code: Select all

#180601 users may forget to put a trailing slash...
[ "$BOOT_DIR" ] && [ "${BOOT_DIR##*/}" ] && BOOT_DIR="${BOOT_DIR}/"
[ "$WKG_DIR" ] && [ "${WKG_DIR##*/}" ] && WKG_DIR="${WKG_DIR}/"

But what if a user puts a leading slash, like WKG_DIR='/easy/0.9.3' -- I think that will still work, although it is wrong. Might as well check for that also:

Code: Select all

[ "$BOOT_DIR" ] && [ "${BOOT_DIR:0:1}" == "/" ] && BOOT_DIR="${BOOT_DIR:1:99}"
[ "$WKG_DIR" ] && [ "${WKG_DIR:0:1}" == "/" ] && WKG_DIR="${WKG_DIR:1:99}"

These corrections are now in the init script.

BarryK · #788 Post by **BarryK** » Fri 01 Jun 2018, 10:20

lp-dolittle wrote:Hi Barry,

just a question, as for your 'isolated bootup' project. If I correctly understood your explanation, while running your planned Easy OS from a flash drive which has 2 partitions you will enjoy 'complete security'.

Did you also figure out a way to protect this new Easy OS when the flash drive is plugged in after, for example, a Puppy which provides full root capabilities already is running in RAM, booted from a live-CD? I'm thinking of the risk that this new Easy OS - and the comprised data - still would be vulnerable to manipulation while being inactive.

Could your 'isolated bootup' system also work if the flash drive's second partition (the working partition) contains an encrypted filesystem?

kind regards

Yeah, that's a different situation, and we would have to go for an encrypted filesystem.

I am currently thinking about that.

The problem with that, is you would have to type in a password at bootup.

Cu Chulinux · #789 Post by **Cu Chulinux** » Fri 01 Jun 2018, 10:52

# date -Iminutes
2018-06-01T06:47-04:00

# busybox date -Iminutes
2018-06-01T10:48+0000

it is 6:47 AM local time here.

Now, about q.sfs not being found ...

BOOT_SPECS for 0.9.1 (that works)

BOOT_DISKID='81E73A43-584A-11E5-BEDB-A8317C82F9F1'
BOOT_PARTNUM=5
BOOT_FS='vfat'
BOOT_DIR=''
WKG_DISKID='81E73A43-584A-11E5-BEDB-A8317C82F9F1'
WKG_PARTNUM=6
WKG_FS='ext4'
WKG_DIR=''
Q_DISTRO_VERSION=0.9.1

BOOT_SPECS for 0.9.3 (that doesn't work)

BOOT_DISKID='81E73A43-584A-11E5-BEDB-A8317C82F9F1'
BOOT_PARTNUM=5
BOOT_FS='vfat'
BOOT_DIR=''
WKG_DISKID='81E73A43-584A-11E5-BEDB-A8317C82F9F1'
WKG_PARTNUM=6
WKG_FS='ext4'
WKG_DIR=''
Q_DISTRO_VERSION=0.9.3

Cu Chulinux · #790 Post by **Cu Chulinux** » Fri 01 Jun 2018, 23:28

OK, so it has failed to mount q.sfs, and has dropped out to a shell.

This shell is in ram. Do you have keyboard inpout at this stage? On some PCs the keyboard does not work at this stage of bootup.

...

Hi Barry, I missed this message earlier.

I do have keyboard so:

# echo "$Q_DISTRO_VERSION"
(result is blank)

# echo "$WKG_DEV"
(result is blank)

# echo "$WKG_DIR"
(result is blank)

# ls -1 /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}

ls: /mnt//repository/easy-: no such file or directory

It looks like the variables are not being correctly set. I then did:

# ls -l /mnt/sda6/repository/easy-0.9.3
configuration configuration-0.9.3 q.sfs rw-0.9.3.sfs

note there is no vmlinuz or initrd

Fortunately with Easy it is, well, easy to go back and forth between versions. Back in 0.9.1 for now.

Cu Chulinux · #791 Post by **Cu Chulinux** » Fri 01 Jun 2018, 23:34

Question, since Easy looks for q.sfs in the repository does that mean it doesn't need to be kept in the boot dir after first boot after upgrading? Only vmlinuz and initrd.q need to be in the (in my case) efi boot partition?

BarryK · #792 Post by **BarryK** » Sat 02 Jun 2018, 00:20

Cu Chulinux wrote:Question, since Easy looks for q.sfs in the repository does that mean it doesn't need to be kept in the boot dir after first boot after upgrading? Only vmlinuz and initrd.q need to be in the (in my case) efi boot partition?

From your feedback, I can't see why 0.9.3 is failing to boot. It is most odd.

Regarding q.sfs not having to be in the boot-partition after first bootup, that is the current situation.

However, maybe not in the future, for security reasons. It may always use q.sfs in the boot-partition.

Right now, I am focusing on tightening security, and that is one thing that I might change.

BarryK · #793 Post by **BarryK** » Sat 02 Jun 2018, 00:27

Cu Chulinux wrote: # ls -l /mnt/sda6/repository/easy-0.9.3
configuration configuration-0.9.3 q.sfs rw-0.9.3.sfs

note there is no vmlinuz or initrd

Ah, that is wrong. vmlinuz and initrd.q should have been copied there on the first boot. I will look into that.

Cu Chulinux · #794 Post by **Cu Chulinux** » Sat 02 Jun 2018, 02:48

I did some more investigating and the q.sfs in the 0.9.3 repository was only 113Mb.

So, I re-upgraded again to 0.9.3 and fixed the boot specs, then I manually copied the 3 files into the repository prior to rebooting. Now it starts up ok. So the problem was incomplete saving to the repository. I can't say why that happened though.

BTW when upgraded the icon theme was changed to your blue icon theme but everything else stayed as I had set up previously (JWM theme, mouse theme, and background)

Billtoo · #795 Post by **Billtoo** » Sat 02 Jun 2018, 13:55

While running from Manjaro linux on my Compaq Presario desktop pc (intel graphics)
I prepared a 32gb usb-3.0 flash drive with gparted.
Downloaded easy-0.9.3 and easydd and prepared them for use, then
installed easy to the flash drive with easydd, rebooted from the flash drive and setup
easy-0.9.3,installed pets etc.

It's working okay on this computer.

BarryK · #796 Post by **BarryK** » Sat 02 Jun 2018, 14:10

Cu Chulinux wrote:I did some more investigating and the q.sfs in the 0.9.3 repository was only 113Mb.

So, I re-upgraded again to 0.9.3 and fixed the boot specs, then I manually copied the 3 files into the repository prior to rebooting. Now it starts up ok. So the problem was incomplete saving to the repository. I can't say why that happened though.

BTW when upgraded the icon theme was changed to your blue icon theme but everything else stayed as I had set up previously (JWM theme, mouse theme, and background)

I found a couple of bugs in the rollback/forward code. The next release, 0.9.4, should be OK, and will probably have to restrict rollback to 0.9.4 or later, as if rollback earlier then will have the broken code.

rufwoof · #797 Post by **rufwoof** » Sun 03 Jun 2018, 14:21

Hi Barry

I found a couple of bugs in

There's another bug in the containers code Barry. Add a sfs to a container such as ff.sfs using the container manager, and its recorded in the container configuration file as EASY_LAYER_RO1=ff.sfs-*.sfs ... and doesn't get picked up/used.

rufwoof · #798 Post by **rufwoof** » Sun 03 Jun 2018, 20:27

Barry

??? Shouldn't the ec-run file in a containers .session folder include a --keep=1 parameter ???

Code: Select all

if [ "$EC_CAP_DROP" ];then #180427
 capsh --drop=${EC_CAP_DROP} -- -c "${EXE} ${ARGS}"
else
 ${EXE} ${ARGS}
fi

-->

Code: Select all

if [ "$EC_CAP_DROP" ];then #180427
 capsh --drop=${EC_CAP_DROP} --keep=1 -- -c "${EXE} ${ARGS}"
else
 ${EXE} ${ARGS}
fi

rufwoof · #799 Post by **rufwoof** » Mon 04 Jun 2018, 01:50

Hi Barry.

Taking a snapshot and adding qfix=bak kernel boot parameter doesn't work as expected for me (HDD frugal installation) - showed the first-boot type desktop instead of the expected last snapshot desktop. Rolling back to that snapshot via the menu and rebooting again had it back to the desired snapshot image as before.

rufwoof · #800 Post by **rufwoof** » Mon 04 Jun 2018, 11:17

It's good practice to cd into the chroot folder before chrooting as chroot doesn't actually change dir into the chroot and can otherwise leave a file descriptor link to outside of the chroot environment that might be exploited.

Edit /usr/local/easy_containers/ec-chroot (and others) to have a
cd ${CONTAINER}
before the unshare ... chroot action (i.e. above/before the
#--map-root-user needed if have -U, otherwise env will fail.
if...)

Still doubtful about running as root inside the container. Things like mknod or write access to /lib or /etc ... etc can be used to potentially break out of the container).

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

EasyOS version 2.3.2, June 22, 2020

Installing on hard drives

EasyOS Pyro 0.9.3 (May 26)

Re: isolated bootup

EasyOS Pyro 0.9.3 (May 26)