/etc/hosts file overwritten in persistent live USB
This page https://help.ubuntu.com/community/mkusb encourages to create persisten live bootable USB. So that's what I suggested to my class, when I had to suggest a way how they could enjoy Ubuntu Linux without disturbing the school's computer default OS. So now they can boot Ubuntu 18.04 from their USB pen drives.
When teaching them how to set up Apache web server, it was discovered that the changes made to /etc/hosts
file were not preserved between boots. The config files under /etc/apache2/sites-enabled
and the site files under /var/www
where preserved, though.
What could be going on here? Mkusb is using casper-rw partition in order to establish the persistence. Why would the persistence work on one file and not work on another? Or perhaps the /etc/hosts
file is rewritten by some default live USB instruction that should be removed?
18.04 persistent mkusb
migrated from serverfault.com Feb 8 at 23:26
This question came from our site for system and network administrators.
add a comment |
This page https://help.ubuntu.com/community/mkusb encourages to create persisten live bootable USB. So that's what I suggested to my class, when I had to suggest a way how they could enjoy Ubuntu Linux without disturbing the school's computer default OS. So now they can boot Ubuntu 18.04 from their USB pen drives.
When teaching them how to set up Apache web server, it was discovered that the changes made to /etc/hosts
file were not preserved between boots. The config files under /etc/apache2/sites-enabled
and the site files under /var/www
where preserved, though.
What could be going on here? Mkusb is using casper-rw partition in order to establish the persistence. Why would the persistence work on one file and not work on another? Or perhaps the /etc/hosts
file is rewritten by some default live USB instruction that should be removed?
18.04 persistent mkusb
migrated from serverfault.com Feb 8 at 23:26
This question came from our site for system and network administrators.
1
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
– sudodus
Feb 8 at 23:43
1
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
.
– sudodus
Feb 8 at 23:51
1
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09
add a comment |
This page https://help.ubuntu.com/community/mkusb encourages to create persisten live bootable USB. So that's what I suggested to my class, when I had to suggest a way how they could enjoy Ubuntu Linux without disturbing the school's computer default OS. So now they can boot Ubuntu 18.04 from their USB pen drives.
When teaching them how to set up Apache web server, it was discovered that the changes made to /etc/hosts
file were not preserved between boots. The config files under /etc/apache2/sites-enabled
and the site files under /var/www
where preserved, though.
What could be going on here? Mkusb is using casper-rw partition in order to establish the persistence. Why would the persistence work on one file and not work on another? Or perhaps the /etc/hosts
file is rewritten by some default live USB instruction that should be removed?
18.04 persistent mkusb
This page https://help.ubuntu.com/community/mkusb encourages to create persisten live bootable USB. So that's what I suggested to my class, when I had to suggest a way how they could enjoy Ubuntu Linux without disturbing the school's computer default OS. So now they can boot Ubuntu 18.04 from their USB pen drives.
When teaching them how to set up Apache web server, it was discovered that the changes made to /etc/hosts
file were not preserved between boots. The config files under /etc/apache2/sites-enabled
and the site files under /var/www
where preserved, though.
What could be going on here? Mkusb is using casper-rw partition in order to establish the persistence. Why would the persistence work on one file and not work on another? Or perhaps the /etc/hosts
file is rewritten by some default live USB instruction that should be removed?
18.04 persistent mkusb
18.04 persistent mkusb
edited Feb 8 at 23:38
Passiday
asked Feb 8 at 23:12
PassidayPassiday
1437
1437
migrated from serverfault.com Feb 8 at 23:26
This question came from our site for system and network administrators.
migrated from serverfault.com Feb 8 at 23:26
This question came from our site for system and network administrators.
1
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
– sudodus
Feb 8 at 23:43
1
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
.
– sudodus
Feb 8 at 23:51
1
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09
add a comment |
1
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
– sudodus
Feb 8 at 23:43
1
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
.
– sudodus
Feb 8 at 23:51
1
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09
1
1
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the
/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.– sudodus
Feb 8 at 23:43
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the
/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.– sudodus
Feb 8 at 23:43
1
1
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involve cron
.– sudodus
Feb 8 at 23:51
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involve cron
.– sudodus
Feb 8 at 23:51
1
1
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09
add a comment |
1 Answer
1
active
oldest
votes
General discussion about persistent live systems
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the /etc/hosts file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
Possible solutions
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it.
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
. But there should be a reason for/etc/hosts
to bounce back (unless it is a bug). Maybe things involving the network and/etc/hosts
happen early about in the boot process, before the overlay system is activated, and in that case, this workaround will not work.Yet another alternative is to try a persistent live system made from another linux distro in order to check if the
/etc/hosts
bounces back to default after reboot.
Test with Debian 9.6.0
mkusb can create persistent live drives from Ubuntu and Debian iso files. So it is natural for me to try a Debian persistent live system. I have the iso file
debian-live-9.6.0-amd64-cinnamon.iso
which is new (downloaded January 2019). I made and tested a persistent live system, and it preserves /etc/hosts
after reboot :-)
user@debian:~$ cat /etc/hosts
127.0.0.1 localhost debian
192.168.0.4 xw8400
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
user@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
user@debian:~$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
user@debian:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.4M 1.6G 1% /run
/dev/sdb4 2.0G 2.0G 0 100% /lib/live/mount/persistence/sdb4
/dev/loop0 1.9G 1.9G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs 7.8G 0 7.8G 0% /lib/live/mount/overlay
/dev/sdb5 8.4G 2.3G 5.8G 28% /lib/live/mount/persistence/sdb5
overlay 8.4G 2.3G 5.8G 28% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 4.0K 7.8G 1% /tmp
tmpfs 1.6G 20K 1.6G 1% /run/user/1000
/dev/sdb1 4.2G 23M 4.2G 1% /media/user/usbdata
user@debian:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
loop0 squashfs /lib/live/mount/rootfs/filesystem.squashfs loop0 1.8G root disk brw-rw----
sda sda 238.5G root disk brw-rw----
├─sda1 ext4 root 2093f8d6-7840-4256-8edc-4db97e865784 ├─sda1 232.5G root disk brw-rw----
└─sda2 swap swap 4b882c9f-4867-4c5c-8eb7-c84ef03f4786 └─sda2 6G root disk brw-rw----
sdb sdb 14.9G root disk brw-rw----
├─sdb1 ntfs usbdata 51B99954568550BA /media/user/usbdata ├─sdb1 4.2G root disk brw-rw----
├─sdb2 ├─sdb2 1M root disk brw-rw----
├─sdb3 vfat usbboot 3FAC-E416 ├─sdb3 244M root disk brw-rw----
├─sdb4 iso9660 d-live 9.6.0 ci amd64 2018-11-10-11-54-14-00 /lib/live/mount/persistence/sdb4 ├─sdb4 2G root disk brw-rw----
└─sdb5 ext4 persistence 9d044926-15cd-4e1b-911d-ceb8e7101cf3 /lib/live/mount/persistence/sdb5 └─sdb5 8.5G root disk brw-rw----
sr0 sr0 1024M root cdrom brw-rw----
I don't know if things will work as they should with Debian persistent live and your Apache web server,
- if
/etc/hosts
and the corresponding network settings work as intended, and - if other things in Debian, for example hardware drivers work with your computers,
but I think it is worth trying with Debian.
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image usingdd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.
– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
|
show 2 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116804%2fetc-hosts-file-overwritten-in-persistent-live-usb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
General discussion about persistent live systems
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the /etc/hosts file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
Possible solutions
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it.
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
. But there should be a reason for/etc/hosts
to bounce back (unless it is a bug). Maybe things involving the network and/etc/hosts
happen early about in the boot process, before the overlay system is activated, and in that case, this workaround will not work.Yet another alternative is to try a persistent live system made from another linux distro in order to check if the
/etc/hosts
bounces back to default after reboot.
Test with Debian 9.6.0
mkusb can create persistent live drives from Ubuntu and Debian iso files. So it is natural for me to try a Debian persistent live system. I have the iso file
debian-live-9.6.0-amd64-cinnamon.iso
which is new (downloaded January 2019). I made and tested a persistent live system, and it preserves /etc/hosts
after reboot :-)
user@debian:~$ cat /etc/hosts
127.0.0.1 localhost debian
192.168.0.4 xw8400
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
user@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
user@debian:~$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
user@debian:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.4M 1.6G 1% /run
/dev/sdb4 2.0G 2.0G 0 100% /lib/live/mount/persistence/sdb4
/dev/loop0 1.9G 1.9G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs 7.8G 0 7.8G 0% /lib/live/mount/overlay
/dev/sdb5 8.4G 2.3G 5.8G 28% /lib/live/mount/persistence/sdb5
overlay 8.4G 2.3G 5.8G 28% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 4.0K 7.8G 1% /tmp
tmpfs 1.6G 20K 1.6G 1% /run/user/1000
/dev/sdb1 4.2G 23M 4.2G 1% /media/user/usbdata
user@debian:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
loop0 squashfs /lib/live/mount/rootfs/filesystem.squashfs loop0 1.8G root disk brw-rw----
sda sda 238.5G root disk brw-rw----
├─sda1 ext4 root 2093f8d6-7840-4256-8edc-4db97e865784 ├─sda1 232.5G root disk brw-rw----
└─sda2 swap swap 4b882c9f-4867-4c5c-8eb7-c84ef03f4786 └─sda2 6G root disk brw-rw----
sdb sdb 14.9G root disk brw-rw----
├─sdb1 ntfs usbdata 51B99954568550BA /media/user/usbdata ├─sdb1 4.2G root disk brw-rw----
├─sdb2 ├─sdb2 1M root disk brw-rw----
├─sdb3 vfat usbboot 3FAC-E416 ├─sdb3 244M root disk brw-rw----
├─sdb4 iso9660 d-live 9.6.0 ci amd64 2018-11-10-11-54-14-00 /lib/live/mount/persistence/sdb4 ├─sdb4 2G root disk brw-rw----
└─sdb5 ext4 persistence 9d044926-15cd-4e1b-911d-ceb8e7101cf3 /lib/live/mount/persistence/sdb5 └─sdb5 8.5G root disk brw-rw----
sr0 sr0 1024M root cdrom brw-rw----
I don't know if things will work as they should with Debian persistent live and your Apache web server,
- if
/etc/hosts
and the corresponding network settings work as intended, and - if other things in Debian, for example hardware drivers work with your computers,
but I think it is worth trying with Debian.
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image usingdd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.
– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
|
show 2 more comments
General discussion about persistent live systems
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the /etc/hosts file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
Possible solutions
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it.
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
. But there should be a reason for/etc/hosts
to bounce back (unless it is a bug). Maybe things involving the network and/etc/hosts
happen early about in the boot process, before the overlay system is activated, and in that case, this workaround will not work.Yet another alternative is to try a persistent live system made from another linux distro in order to check if the
/etc/hosts
bounces back to default after reboot.
Test with Debian 9.6.0
mkusb can create persistent live drives from Ubuntu and Debian iso files. So it is natural for me to try a Debian persistent live system. I have the iso file
debian-live-9.6.0-amd64-cinnamon.iso
which is new (downloaded January 2019). I made and tested a persistent live system, and it preserves /etc/hosts
after reboot :-)
user@debian:~$ cat /etc/hosts
127.0.0.1 localhost debian
192.168.0.4 xw8400
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
user@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
user@debian:~$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
user@debian:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.4M 1.6G 1% /run
/dev/sdb4 2.0G 2.0G 0 100% /lib/live/mount/persistence/sdb4
/dev/loop0 1.9G 1.9G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs 7.8G 0 7.8G 0% /lib/live/mount/overlay
/dev/sdb5 8.4G 2.3G 5.8G 28% /lib/live/mount/persistence/sdb5
overlay 8.4G 2.3G 5.8G 28% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 4.0K 7.8G 1% /tmp
tmpfs 1.6G 20K 1.6G 1% /run/user/1000
/dev/sdb1 4.2G 23M 4.2G 1% /media/user/usbdata
user@debian:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
loop0 squashfs /lib/live/mount/rootfs/filesystem.squashfs loop0 1.8G root disk brw-rw----
sda sda 238.5G root disk brw-rw----
├─sda1 ext4 root 2093f8d6-7840-4256-8edc-4db97e865784 ├─sda1 232.5G root disk brw-rw----
└─sda2 swap swap 4b882c9f-4867-4c5c-8eb7-c84ef03f4786 └─sda2 6G root disk brw-rw----
sdb sdb 14.9G root disk brw-rw----
├─sdb1 ntfs usbdata 51B99954568550BA /media/user/usbdata ├─sdb1 4.2G root disk brw-rw----
├─sdb2 ├─sdb2 1M root disk brw-rw----
├─sdb3 vfat usbboot 3FAC-E416 ├─sdb3 244M root disk brw-rw----
├─sdb4 iso9660 d-live 9.6.0 ci amd64 2018-11-10-11-54-14-00 /lib/live/mount/persistence/sdb4 ├─sdb4 2G root disk brw-rw----
└─sdb5 ext4 persistence 9d044926-15cd-4e1b-911d-ceb8e7101cf3 /lib/live/mount/persistence/sdb5 └─sdb5 8.5G root disk brw-rw----
sr0 sr0 1024M root cdrom brw-rw----
I don't know if things will work as they should with Debian persistent live and your Apache web server,
- if
/etc/hosts
and the corresponding network settings work as intended, and - if other things in Debian, for example hardware drivers work with your computers,
but I think it is worth trying with Debian.
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image usingdd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.
– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
|
show 2 more comments
General discussion about persistent live systems
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the /etc/hosts file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
Possible solutions
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it.
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
. But there should be a reason for/etc/hosts
to bounce back (unless it is a bug). Maybe things involving the network and/etc/hosts
happen early about in the boot process, before the overlay system is activated, and in that case, this workaround will not work.Yet another alternative is to try a persistent live system made from another linux distro in order to check if the
/etc/hosts
bounces back to default after reboot.
Test with Debian 9.6.0
mkusb can create persistent live drives from Ubuntu and Debian iso files. So it is natural for me to try a Debian persistent live system. I have the iso file
debian-live-9.6.0-amd64-cinnamon.iso
which is new (downloaded January 2019). I made and tested a persistent live system, and it preserves /etc/hosts
after reboot :-)
user@debian:~$ cat /etc/hosts
127.0.0.1 localhost debian
192.168.0.4 xw8400
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
user@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
user@debian:~$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
user@debian:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.4M 1.6G 1% /run
/dev/sdb4 2.0G 2.0G 0 100% /lib/live/mount/persistence/sdb4
/dev/loop0 1.9G 1.9G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs 7.8G 0 7.8G 0% /lib/live/mount/overlay
/dev/sdb5 8.4G 2.3G 5.8G 28% /lib/live/mount/persistence/sdb5
overlay 8.4G 2.3G 5.8G 28% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 4.0K 7.8G 1% /tmp
tmpfs 1.6G 20K 1.6G 1% /run/user/1000
/dev/sdb1 4.2G 23M 4.2G 1% /media/user/usbdata
user@debian:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
loop0 squashfs /lib/live/mount/rootfs/filesystem.squashfs loop0 1.8G root disk brw-rw----
sda sda 238.5G root disk brw-rw----
├─sda1 ext4 root 2093f8d6-7840-4256-8edc-4db97e865784 ├─sda1 232.5G root disk brw-rw----
└─sda2 swap swap 4b882c9f-4867-4c5c-8eb7-c84ef03f4786 └─sda2 6G root disk brw-rw----
sdb sdb 14.9G root disk brw-rw----
├─sdb1 ntfs usbdata 51B99954568550BA /media/user/usbdata ├─sdb1 4.2G root disk brw-rw----
├─sdb2 ├─sdb2 1M root disk brw-rw----
├─sdb3 vfat usbboot 3FAC-E416 ├─sdb3 244M root disk brw-rw----
├─sdb4 iso9660 d-live 9.6.0 ci amd64 2018-11-10-11-54-14-00 /lib/live/mount/persistence/sdb4 ├─sdb4 2G root disk brw-rw----
└─sdb5 ext4 persistence 9d044926-15cd-4e1b-911d-ceb8e7101cf3 /lib/live/mount/persistence/sdb5 └─sdb5 8.5G root disk brw-rw----
sr0 sr0 1024M root cdrom brw-rw----
I don't know if things will work as they should with Debian persistent live and your Apache web server,
- if
/etc/hosts
and the corresponding network settings work as intended, and - if other things in Debian, for example hardware drivers work with your computers,
but I think it is worth trying with Debian.
General discussion about persistent live systems
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the /etc/hosts file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.
Possible solutions
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it.
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
. But there should be a reason for/etc/hosts
to bounce back (unless it is a bug). Maybe things involving the network and/etc/hosts
happen early about in the boot process, before the overlay system is activated, and in that case, this workaround will not work.Yet another alternative is to try a persistent live system made from another linux distro in order to check if the
/etc/hosts
bounces back to default after reboot.
Test with Debian 9.6.0
mkusb can create persistent live drives from Ubuntu and Debian iso files. So it is natural for me to try a Debian persistent live system. I have the iso file
debian-live-9.6.0-amd64-cinnamon.iso
which is new (downloaded January 2019). I made and tested a persistent live system, and it preserves /etc/hosts
after reboot :-)
user@debian:~$ cat /etc/hosts
127.0.0.1 localhost debian
192.168.0.4 xw8400
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
user@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
user@debian:~$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
user@debian:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.4M 1.6G 1% /run
/dev/sdb4 2.0G 2.0G 0 100% /lib/live/mount/persistence/sdb4
/dev/loop0 1.9G 1.9G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs 7.8G 0 7.8G 0% /lib/live/mount/overlay
/dev/sdb5 8.4G 2.3G 5.8G 28% /lib/live/mount/persistence/sdb5
overlay 8.4G 2.3G 5.8G 28% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 4.0K 7.8G 1% /tmp
tmpfs 1.6G 20K 1.6G 1% /run/user/1000
/dev/sdb1 4.2G 23M 4.2G 1% /media/user/usbdata
user@debian:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT NAME SIZE OWNER GROUP MODE
loop0 squashfs /lib/live/mount/rootfs/filesystem.squashfs loop0 1.8G root disk brw-rw----
sda sda 238.5G root disk brw-rw----
├─sda1 ext4 root 2093f8d6-7840-4256-8edc-4db97e865784 ├─sda1 232.5G root disk brw-rw----
└─sda2 swap swap 4b882c9f-4867-4c5c-8eb7-c84ef03f4786 └─sda2 6G root disk brw-rw----
sdb sdb 14.9G root disk brw-rw----
├─sdb1 ntfs usbdata 51B99954568550BA /media/user/usbdata ├─sdb1 4.2G root disk brw-rw----
├─sdb2 ├─sdb2 1M root disk brw-rw----
├─sdb3 vfat usbboot 3FAC-E416 ├─sdb3 244M root disk brw-rw----
├─sdb4 iso9660 d-live 9.6.0 ci amd64 2018-11-10-11-54-14-00 /lib/live/mount/persistence/sdb4 ├─sdb4 2G root disk brw-rw----
└─sdb5 ext4 persistence 9d044926-15cd-4e1b-911d-ceb8e7101cf3 /lib/live/mount/persistence/sdb5 └─sdb5 8.5G root disk brw-rw----
sr0 sr0 1024M root cdrom brw-rw----
I don't know if things will work as they should with Debian persistent live and your Apache web server,
- if
/etc/hosts
and the corresponding network settings work as intended, and - if other things in Debian, for example hardware drivers work with your computers,
but I think it is worth trying with Debian.
answered Feb 9 at 4:12
sudodussudodus
25k32977
25k32977
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image usingdd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.
– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
|
show 2 more comments
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image usingdd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.
– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
1
1
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
There's something called casper-snapshot, which creates a casper-sn file which may do the trick. It's part of the casper package, check the man pages for it.
– ubfan1
Feb 9 at 5:20
1
1
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
Installing Ubuntu on USB stick as on a normal hdd could be an option, but carrying it out ir much much painful as the simple mkusb operation. And there are many ways how one can screw up their computer while doing it. That's the main reason I chose the LiveUSB+overlay approach.
– Passiday
Feb 9 at 13:35
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image using
dd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.– sudodus
Feb 9 at 17:52
@Passiday, 1. Will you try with Debian 9.6.0 persistent live? 2. You can make one installed Ubuntu system, create a compressed image using
dd | xz
or similar, and let the students clone to their USB pendrives (clone with mkusb), which should make the student task as safe as making a persistent live drive.– sudodus
Feb 9 at 17:52
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
Well, I am hesitant to propose them a solution that would mean reinstalling and reconfiguring the apps they have already started using. So I am looking for a way how to deal with the specific problem at hand. Perhaps you are right about the simplicity of cloning the bootable USBs, once one is succesfully created and configured, maybe I'll give it a try.
– Passiday
Feb 9 at 22:19
1
1
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
@Passiday, I understand and accept that. Good luck trying along the two tracks that you intend to try :-)
– sudodus
Feb 9 at 23:21
|
show 2 more comments
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116804%2fetc-hosts-file-overwritten-in-persistent-live-usb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Some system settings are set up and some programs are started before the overlay system for persistence has started. This happens for the linux kernel and for the kernel's hardware device drivers. Maybe this is also what is happening to the
/etc/hosts
file. I have tampered with that file in installed systems, but not in persistent live systems, so I don't really know, if there is an easy solution to the problem.– sudodus
Feb 8 at 23:43
1
An obvious, but not so easy solution is to install Ubuntu (install like into an internal drive) into a USB drive. Such a system will behave like any installed system. See this link and links from it. -- Another alternative might be to [automatically] backup
/etc/hosts
to a 'safe place', and at boot restore it [also automatically]. This could be done with scripts and maybe involvecron
.– sudodus
Feb 8 at 23:51
1
If you don't want identical installed systems, it should be possible to set up a master installed system with the OEM method, clone it and then finish the installation in each computer making the systems unique with user names and passwords, host names etc.
– sudodus
Feb 9 at 0:09